14.3 Specifications

Now that we have the requirements, we can lay out the specifications. The specifications give a better understanding of what is necessary for the application. With a set of detailed specs, two programmers should be able to create almost identically functioning applications (although, admittedly, their internal implementations may differ markedly).

14.3.1 Users

The application should support two types of users: registered users and the general public. Since we are building a simple application, distinctions between the different user types will be clear-cut:

registered users

Registered users have script upload privileges. They can add new scripts or modify their own scripts that are already in the system.

general public

The general public has full access to scripts in the system, with the ability to download any of them. They cannot add, edit, or delete any scripts. They can send an email to any email address with a link to a specific script.

14.3.2 Scripts

Scripts are stored in a database. The application limits the size of each script; this script repository is intended for small scripts that implement one specific piece of functionality, not entire applications. Storing scripts in a database allows for easy access, change tracking, and download tracking.

Each stored script should have the following information:


The author of the script, in the form of last name, first name. The author's name is available to the application because the user uploading the script is already logged in.


The email address of the author of the script (an optional field that is verified as a valid-format email address). Again, the application has access to this information because the user must be logged in prior to uploading a new script.

date uploaded

The date of the first upload of the script. This is automatically generated in the Flash movie based on the current date.

last modification

The date of the last known modification to the script. This is automatically generated by the Flash movie upon updating the script.


Version number of the script. This is automatically generated by the application in the format of major.minor.micro (e.g., 1.0.0, 1.0.1, etc.). The author can override the default version number with a higher number.


A short description of how to use the script.


Chosen by the author from a predefined list of categories.


The body of the script. The author of the script must paste the text of the script into a text field. We are implementing it in this fashion because of some of the limitations of the Flash client in dealing with the file-upload process. There are workarounds, but we've decided to keep the first version of this application simple. Comments at the top of the script can include a URL pointing to a binary version of the file on the author's site, for example.

14.3.3 General

There are some other specifications that don't fall into the earlier categories. We can lump the rest of the specifications into a general category of site specifications:


The copyright notice, privacy notice, contact information, and other general information should be available to the end user. This could be hardcoded into the application, but as a rule these types of things are better suited to a database. An administrator can easily change the text of the general information from an administrative interface, rather than having to edit a .fla file and recompile a .swf file.


All users should have a way to contact the site administrator. Rather than publish an email address in the application, the application has a button that triggers a contact form so that the email can be sent through the application itself.

    Part III: Advanced Flash Remoting