About Rocket Science
Rocket Science is a project-based integrated development environment for building and publishing web sites. Using Rocket Science, you can create a single project which you can simultaneously publish to a World Wide Web server, an intranet server, a CD-ROM or an HTML help application. Mirroring and spanning features allow you to upload a web site to several different servers, or to spread a web site across different servers to avoid extra bandwidth charges. Rocket Science provides several different ways to view your project, and offers single-click editing and viewing of any source file in your project. Using our unique OmniPlug® interface technology, Rocket Science seamlessly integrates with other web development applications, so in addition to our internal tools such as the HyperText X/Press HTML Editor and X-Map Image Map Editor you can use external tools such as Adobe Photoshop®, HotDog Pro® and Macromedia Director® from within Rocket Science. Rocket Science also offers project management capabilities such as time tracking, project-wide search and replace operations, link checking and HTML validation, and when used with the HyperText X/Press HTML Editor can automatically load your source files and go to the line in question when it detects a problem in your project. Rocket Science's content generators can automatically produce customized HTML documents such as tree-style site maps, index and table-of-contents pages, and can automatically convert just about any graphics file to a web-ready format for inclusion in your project.

It's not an HTML editor
Although it contains the very cool HyperText X/Press HTML editor, Rocket Science itself is not an HTML editor. It is a project manager which is used to combine one or more web sites into a project. Rocket Science manages all of the files that make up the web site(s) within your project and provides automated publishing of the project to a server or directory by simply pressing a button. This type of tool, which is known as an "integrated development environment", is the same type of tool that C and C++ programmers use to develop PC-based applications, and it makes perfect sense to do the same for web sites (as you're about to find out). You will find that making your files come to you for editing instead of the other way 'round is a much more natural approach to developing your web sites, and it will also save you an incredible amount of time.

Unlike HTML editors, which focus on creating individual HTML files, Rocket Science is based on the concept of a project. All of the elements of your web site go into a project file which is managed by Rocket Science. You access your project via the Project Window, which is the main Rocket Science application window. The Project Window keeps track of the contents of your HTML files and displays them graphically, and you can edit or view any of the project elements (graphics files, HTML source, CGI-BIN scripts, audio clips, Java applets, etc.) by clicking them with the mouse. In addition, you can easily upload your project to your web server or publish it to a directory at any time by clicking the Upload to server or Publish to directory button. Since Rocket Science allows you to browse your web site on your PC, you do not need to connect to a server until you are ready to upload your project if you are publishing to a server.

The Rocket Science environment is very flexible in that you are not required to use the built-in tools and editors. We have designed it in such a way that it integrates seamlessly with most third-party applications, so you can use whatever external tools you are comfortable with. For example, if you want to use an HTML editor such as HotDog Pro® or HoTMetaL® instead of our own HyperText X/Press editor, just plug it in by telling Rocket Science where to find the application. The same is true for graphics editors, web browsers and just about any other application you can think of.

How Rocket Science works
The basic premise of working within Rocket Science is that you will create a web site on your PC which "mirrors" the site you wish to create on a web server or CD-ROM, and during the publication process Rocket Science will create a final copy of the web site. If you are publishing for the Internet, Rocket Science will upload your web site to a server using FTP. If you are publishing for CD-ROM or other PC-based applications, Rocket Science will publish your web site to a directory. During the publication process, Rocket Science keeps track of the modification times for each file in your project and publishes only those files which have changed since the last publication.

To build a web site with Rocket Science, you will first create a project. The Rocket Science project file will be located in a directory on your PC which is referred to as the Project Directory. A project consists of one or more publication targets. A target is associated with a particular web server or publication directory (or both) and consists of, among other things, the name of the home page (index.html, for example), the home directory on the server and the server's internet address. Each time you create a new HTML file, you will add it to the project by associating it with a target. Rocket Science will then begin to manage the file and any files which it references (graphics files, Java applets, etc.). Each time you make changes to the HTML file, Rocket Science will re-scan it, adding new references and deleting old ones as necessary.

The Rocket Science messages window
Under the Window pulldown menu in any Rocket Science window, you can access the Messages Window. When performing any complex operation (complex for Rocket Science, not for you!) such as adding an HTML file to a project, uploading a project to a server or creating thumbnail graphics, Rocket Science writes messages to a log file. The Messages Window is the viewer for the log file. If Rocket Science encounters a problem during processing, it will log as much information as it can about the problem and then activate the Messages Window so that you can troubleshoot it. For example, if while parsing one of your HTML files Rocket Science is unable to locate a graphics file that is referenced within the code, it will display the Messages Window and you will see the message "Warning: Unable to locate file "(filename here)". If you are using HyperText X/Press as your HTML editor, you can double-click on the error message to go to the line of code that caused the error. Project uploads, in particular, can be a source of problems because there are so many things that can go wrong; server log-ins can fail for various reasons, operations can time out due to internet traffic, file transfers can fail, you may not have access to a directory, etc. Whenever you encounter a problem during a project upload, you should check the Messages Window. By setting the View level to Level 3, you will be able to determine immediately what went wrong.

Getting your files to the server
One of the best things about Rocket Science is that it will automatically upload your project to a server and set file access permissions for you. You just press the upload button and watch it go, there's no FTP or Telnet to hassle with. In addition, Rocket Science keeps track of the date and time that each file is uploaded so that it only sends those files that you have made changes to, significantly reducing the amount of time you spend on-line. You can find a full discussion of this subject in the Project Window section of the manual, but here's an essential fact that you need to know up front:

There will be times when you have a file which is part of your project but Rocket Science will not know where to upload it because it is not referred to locally. For example, let's say that you have a ZIP'ed file that you are allowing users to download from your FTP site. The reference on your HTML page would look something like "<A HREF="ftp://www.mysite.com/myfile.zip">", but the actual file on the server would be something like "/pub/mysite/ftp/myfile.zip" and would not appear as such anywhere in the project. When reading the HTML source, Rocket Science can figure out that there's a file name "myfile.zip", but it has no way of knowing where it is on your hard drive (although it will try to find it in the project directory) or where to put it on the host since the HREF does not contain that information.

To deal with this situation, just add a new folder to your project in the Project Window, associate the FTP directory on the server with the folder and add the file to the folder. In the above example, you could create a folder named "FTP", associate it with the server directory "/pub/mysite/ftp", and add the file "myfile.zip" to the folder.

About the home page
Attention, Windows 3.x users: Most service providers require that you use a standard name for your web site's home page, and that name isn't always going to be Windows 3.x friendly. For example, the name "index.html" is quite common, but you can't use it on a Windows 3.x system, which needs an 8.3-style file name.

To get around this problem, Rocket Science allows you to specify both local and server versions of the home page file name. In the above example, when you create or modify your project in the Project dialog you would set the server file name to "index.html" and the local file name to "index.htm". "index.htm" is the file you create on your PC. When you upload your project to the server, the file "index.htm" is sent to the server, and is then copied to the file "index.html". Note that we said copied, not renamed. This is because all of your HTML documents that have links to the home page are going to be looking for "index.htm", not "index.html". If you specify "index.html" in the links, Rocket Science will not be able to find the file and you will not be able to test your web site on the PC. Got it?

This may bother you at first, but it has a very interesting and beneficial side effect: you never access the actual home page "index.html" from within your web site. This means that the only time the actual home page is "touched" is when someone connects to your web site and the HTTP server delivers it to their web browser. After that, whenever they access a link within your site that takes them "back to the home page", they get "index.htm", not "index.html". Which means... that when you get your next activity report for your web site, the number of home page "hits" is going to be the actual number of people who visited your web site, and your counter that says "you are the ###th person to visit this site" will actually be true for a change!

Of course, your visitor's web browser probably caches the home page anyway, in which case you can ignore that last paragraph.

Java support
Attention Windows 3.x users: Rocket Science provides excellent support for Java applets, but as with all other files you must adhere to the 8.3 file rule. Since Java applets are required to have a ".class" file name extension on the server, Rocket Science will automatically rename the applet from the 8.3 name to its Unix equivalent when uploading it to the server, but you will need to specify the 8.3 name in a consistent manner. For example, if you have an applet named "StockTicker.class", its 8.3 name would be "stocktic.cla" (truncate the base name to 8 characters and the extension to 3 characters). When adding the file to your project, you would specify the File name on server as "StockTicker.class". (Select the file in the Project Window, right-click the mouse and select Properties... from the speed menu to access this field).

Rocket Science and CGI-BIN
Rocket Science has excellent support for managing CGI-BIN scripts, but testing them on your PC is a problem. You can easily browse the non-CGI portions of your web site with your web browser, since all the browser is doing is loading files from the hard drive. Let's say, though, that you have a form in one of your HTML documents and you press the "Submit" button. Well, now we have a problem since the web browser expects to be connected to your HTTP server so that it can tell the server the name of the CGI script/executable to launch, and it will also be expecting data to come back to it over the HTTP link. In other words, we're not just loading files anymore.

Rocket Science recognizes files with the following file name extensions as CGI files:

• .PL - Perl scripts
• .TCL - Tcl scripts
• .SH - Shell scripts
• .C - C source
• .CPP - C++ source

<FORM METHOD="POST" ACTION="/cgi-bin/mysite/signup.pl">

Rocket Science will assume that the file "signup.pl" is a Perl script which can be found in your project directory. When you upload your project to the server, Rocket Science will copy the file to the CGI directory that you have defined for your project, "/pub/cgi-bin/mysite". Note that Rocket Science will not attempt to copy the file to the directory "/cgi-bin/mysite" that is specified in the FORM tag, since it is most likely an aliased path and thus the transfer would fail.

In addition to automatically uploading CGI files that it understands, Rocket Science creates a folder in the Project Window called CGI-BIN which is associated with the CGI directory on the server. Anything you put in this folder will be copied to the CGI directory on the server when you upload your project, even if Rocket Science doesn't recognize the file extension.

Okay, we said up front that we wouldn't explain anything about how to write CGI code, but here are some hints we've found useful in making your CGI development cycle a little bit shorter and a little less painful. These apply to DOS/Windows in general as well as to Rocket Science:

• Use Perl - There's a lot of really good source code out there, and if you understand CGI in the first place then you can certainly get your brain wrapped around Perl.

• Test it off-line first - Let's say that you have a Perl script called "mailform.pl" that takes the contents of a form, writes them to a mailing list file and generates an HTML page that thanks the user for their input.

  • Edit your script, then run it through the DOS-based Perl interpreter before uploading it to the server to check for syntax errors, as in "perl mailform.pl". Continue this edit/interpret cycle until there are no more syntax errors.
  • Temporarily assign values to the form variables from within the script. For example, if there's a 'name' field on the form, assign it the value 'J. Jones'. Now your script will have something to chew on when you run it through the interpreter so that you can see some valid output.
  • If you have pathed references in your script (i.e., "/cgi-bin/mycompany/maillist.txt"), temporarily change them to non-pathed local references (i.e., "maillist.txt"). Now you can do file I/O to the mailing list file on your PC.
  • Since the HTML page that is produced by a form script comes from stdout (i.e., it's printed to the screen) you can redirect it to a file, as in "perl mailform.pl > thankyou.htm". Now you can view the output page in your web browser and change the script code until you like the results.

• Let Rocket Science upload it - Once you're at the point where your script is basically working and you need to test it on the server, you will get into the inevitable edit it/upload it/browse it cycle. Let Rocket Science take care of the "upload it" part since it will copy your files to the host and change the access permissions in one shot. Put away those FTP and Telnet apps and save yourself some time!