WebSphere Studio is one of the key components in IBM's WebSphere Development Studio for iSeries tool suite (program 5722-WDS). WebSphere Studio has a variety of tools for building and maintaining Web site resources: Page Designer for Web pages and JSPs, Applet Designer for Java applets, WebArt Designer for static image files and the Animated Gif Designer for animated gifs. Studio also has a set of key wizards that can jump-start your Web development even if you're not an expert at SQL, Java, HTML, etc.: the SQL wizard, the database wizard and the Java bean wizard.
Studio file management features
Studio also has extensive file management features to manage all the resources for a Web project. Understanding how Studio's intelligent file management features work can dramatically improve your Web site development and maintenance.
File management challenges for Web development
- Organizing file resources for a project
- Controlling file maintenance activities on a project
- Exchanging project versions with other developers
- Managing URL links between files on a project and external resources
- Publishing project files to test and production servers across networks
- Controlling a project life cycle for development, testing, production, etc.
- Remapping file links when the project is published to a server location
- Importing resources from other Web sites
Studio's file management features include the following:
- Project file pane to organize all file resources for a project
- Archive file format to save and restore an entire project to foreign systems
- File Relations view
- Check in/check out management to control working on files
- Registration of custom tools to manage different file types (based on mime-type extensions)
- Publishing stages, views and publishing methods to move files to your Web site
- Project integrity report to check file relations
- Publishing report with customizable options to manage the publishing process
- Web site import support
Project file pane to organize all file resources for a project
The project pane shows all the files and folders in a project. All the files are located in a project folder, which by default is a sub directory of the main Studio projects folder. If needed, you can customize Studio's preferences easily to point to another location as the main folder to store your projects.
Creating a new project automatically generates several objects in your project: a theme folder with a Master.css style sheet and a servlet folder to hold the Java beans you may add to your project. You can add new folders and new files by type: HTML, JSP, image, etc. You have the option of creating new files from scratch OR copying in existing files from another location on the network.
Archive file format to save and restore projects
Studio has a new archive format in Version 3.5 that has an extension of .wsr. When you save your project to an archive file, all the resources that are defined in the project can be saved in the single archive file. The archive file even saves the publishing targets you specify for your servers in the publishing stages and the file location where the project was stored.
When restoring a project from an archive file, you have options for doing the following:
- Copying the archive into another project or the existing project or creating a new project from the archive file and restoring the files to it
- Copying the project files to the source location or changing the Destination to a custom location. (That happens when we restore an archive file from someone else's system.)
- Using the archived publishing targets or specifying new ones
File link concepts in Studio
Studio recognizes and manages many types of hypertext links in projects. Hypertext links define a logical address for a linked target file from a parent file so the target file can be dynamically accessed when needed. For example, MyPage.html can contain an embedded hypertext link to an image file that should automatically be loaded with the html page.
File links are specified as URL references using the appropriate file system access method.
A Windows file link might be: D:ebtnowWebservices1.htm
An HTTP file reference might be: http://MyServer/App1/MyPage.html
An FTP file reference might be: ftp://MyServer/App1/MyPage.html
Industry-standard links recognized by Studio include local file system, ftp, http, gopher, https, mailto, news, telnet, wais.
When Studio manages a file link, it means several things, including these:
- Studio can show the relationship between a source and target file for a link in the File Relations view.
- Studio can automatically rewrite the file link appropriately when your project is published to a target server.
Below are some of the link types:
Embedded links: These are links to other files that are rendered within the file that contains them. For example, a link to an image file in an HTML page is an embedded link because it is contained in the same HTTP request as the parent URL for the HTML page.
Parameter links: These are relationships specified by parameters in executable files. For example, you can define a file name as a parameter to a servlet or JSP so it can read the file or update it. Studio can manage defined parameter links to files.
Source links: These are links between source files and the files that are derived from them. For example, a Java file is a source file. When you compile it you create a .class file. If you publish your Java beans ( source and class files ) from VisualAge, Studio automatically creates logical connections between these files to keep them synchronized.
Custom links: You can create a custom link to define any other relationship between files not covered in the other link types. For example, you might want to link some Java source files with an external UML project in Rational Rose or TogetherJ that defined the project design.
File Relations view
The file relations view makes it easy for a project leader to understand and manage all the files and their relationships in a project. When viewing a project, all the files and folders are hierarchically organized in the project pane on the left. If you select, ALT-1, the File Relations view is shown to the right. For the currently selected file in the project pane it shows all the links to and from that file. Links where the file is a target are shown to the left. Links this file links to are shown as target links on the right.
You can navigate through your project in file relations view by selecting any file to the left or right of the current one with a plus sign. That file will become the currently selected file, and all of its related files will be shown on the left and right.
The legend on the right of the pane shows you all of the selected link types that are currently displayed in file relations view. You can choose to display only certain types to simplify your views. A nice feature is being able to directly edit child relationships (where the current file is the parent). You can change links using the right button menu | edit link option. You don't always have to open the file source and make the changes there. You can just check out the file, make the change in File Relations view and then check it back in.
Removing a file from File Relations view
Sometimes you have files stored in folders in a project for reference that are not to be published as part of the project. If they are not part of the published Web application, you may not want them showing up in File Relations view on target links from other files. You can edit a source file manually and remove the link or edit the properties for the target file in the project pane. If you edit the file's properties, uncheck the 'parse file' box to remove it from Studio's file relations view processing.
Check in/check out management to control working on files
Studio also supports team development using the file check in | check out control method. Typically a project could be stored on a file server with multiple team members having access to the project. When an individual needs to be worked on, the team member double clicks it in the project pane which checks out the file. The file now shows a red check mark in the project pane indicating that it was checked out for work by a developer.
When finished working on a file, the developer can check the file back in to the project. The red check mark is removed and all developers can see the new version of the file.
This check in | check out model for team development works very well with external version control systems that you may use.
The check out report shows quickly which files are checked out on a project and lets you select which ones to check in easily. The check out report is normally run before publishing a project to a Web site to ensure that all the latest file resources are available.
Registration of custom tools to manage different file types
Studio supplies default editors (Page Designer for html and JSP files etc.) for many different file types. You can change Studio's default editors or add new ones based on the MIME type (or extension name) of a file. Using the option from Studio's workbench, tools -- Tools Registration, you can see which tools are registered for different file types and change the default editor. That makes it easy to use tools of your choice for different file types. Many developers may prefer a different HTML editor than Studio's Page Designer because they are more familiar with it. Here they can specify the default editor for the file type.
Publishing stages, views and publishing methods to move files to your Web site
The publishing view (ALT-2) is accessed quickly so you easily manage your publishing stages, servers and methods graphically. The current stage is shown by default. You can change to a different stage by selecting the workbench option: Project | Publishing stage and selecting from the available stages.
Studio supports the concept of publishing a project in stages. Typically, a Web site might have several logical stages for publishing in its life cycle: development, testing and production. By default, Studio creates two stages: Test and Production. You can easily customize the publishing stages to add or remove stages.
A publishing server is a definition for a server that you want to publish to. A target publishing server for a Studio project can be any valid Web application server: WebSphere, VisualAge for Java WebSphere Test Environment, Tomcat, WebLogic, etc.
You can define one or more servers to a publishing stage. This allows you to publish some or all of your project files to multiple servers (if needed) at the same time. Each server definition has several attributes for you to define:
This is a logical name for the server
This is a valid address for the Web server
One of the selected publishing methods: file system, FTP, etc.
The publishing method determines HOW the files will be sent from your project to the Web server.
A Web application prefix
This identifies a logical prefix to access your Web application as part of a URL, for instance: http://MyServer/App1/index.html, where App1 is the app prefix in the URL.
This is a directory on the Web application server for your application's HTML files and related resources (images, JSPs, etc.). This is relative to what is referred to as the document root often on the Web application server.
This is a directory on the Web application server for your application's Java beans that are normally stored in the servlets directory of a project. This directory is usually defined as the part of the classpath for the application on the Web application server configuration.
Publishing methods either use the local file system (Windows or Unix) or FTP. For the iSeries, you can map a network drive to AS/400 IFS and use the Windows file system publishing method or the FTP method.
After defining the publishing stage and server, a project leader publishing a project normally does the following:
- Runs the Check out info report to ensure all needed files are checked in
- Runs the Project integrity report to ensure all required files are accessible in the project (see below)
- Optionally sets the publishing options to change publishing warnings, etc.
- Publishes the project
The Publishing report
The publishing report shows the results of publishing. Please READ this report. Many problems accessing your project in the Web application server are correctly identified here first! The publishing report includes much of the information shown on the project integrity report below as long the actual URLs you'll use to access the published files on your Web application server.
Testing your published application
Ensure your Web application server is started. From the publishing report, copy the URL for the starting point for your Web application (for example, http://MyServer/MyApp/index.html) and paste this into the address field on your selected Web browser. The main page of your application should be displayed after a few seconds.
If you missed a file that should have been published, a 404 File Not Found error will normally be displayed in the browser when your application runs. Go back and add the file to be published for the server.
Project integrity report to check file relations
Another major issue in managing Web projects is checking on the status of all the files in the project for the current publishing stage. Studio has a customizable project integrity report that makes that easy for your project leader. You can produce a project integrity report at any time that shows the integrity of the files and the link relationships in a publishing stage.
The report includes
- The name of the publishing stage
- Completion status of the integrity check
- Number of broken links, inaccessible outside links, missing files, publishable files with source links or parameter links. (MOST of these errors do need to be corrected for your project to work as intended when published.)
- Number of publishable and non-publishable orphan files
(This is warning information only. Orphan files are files that are NOT linked from another file in the project. Your actual site may have other files NOT in the project that DO link to these files OR this file MAY be a top-level file someone enters as a URL, e.g. http://www.my.com/ index.html.)
- Number of files with duplicate file names (in different folders). (This is a potential warning error only. This MAY be your intention.)
- Files with no publishing information in the stage (This is also a potential warning error only. SQL files, MIF files, etc. are NOT publishable. They are design time, not run time artifacts, so they should always show up in this section of the report. )
- Files that are inaccessible
(These OFTEN are real errors that need to be corrected. They indicate that the referenced external file links are not accessible from your project in this publishing stage. For instance you could be publishing to a test server, and it may not have network access to another server with your online shopping application. Links to that site would show up as inaccessible.)
Web site import support
A nice feature of Studio is its ability to import another Web site into a project. If your company has multiple Web applications deployed internally or externally on hosted servers, you can navigate to the application and import some or all of its existing resources into your current Studio project. That can be useful when you have to integrate with an existing application. You have options to control how much of the site is imported by level, following links, etc.
Studio File Management Summary
Although Studio has productive file management capabilities that are easy to use for a Web project and Web sites, there is a lot to learn if you are new to Web development. For the experienced developer, it is readily apparent how valuable Studio is to manage Web projects compared with alternate tools from other vendors.
More on WebSphere Development Suite for iSeries
About the authors: Jim Mason is president of Cape Cod Bay Systems, and he writes, consults, teaches, designs and develops AS/400 Web applications using Java, WebSphere, DB2, Lotus Domino and the WebSphere Development Tools for AS/400. Dave Slater is World Wide Market Manager of AS/400 Application Development at IBM Canada.
This was first published in July 2001