Homepage | About EASA | Contact
Homepage | About EASA | Contact
Authoring of EASAPs can be broken down into six main steps.
First of all, EASAPs should be planned carefully. In creating an EASAP, you are given the opportunity to design the user interface specifically around problems users want to solve on a regular basis. This opportunity may be new for many authors, who are accustomed to conforming to the requirements of the various software applications they use. Below you will find some suggestions for planning your EASAPs:
In general, you should use good GUI design principles as you plan your EASAP, and the GUI of EASAPs page is dedicated to providing you further guidelines and suggestions.
Since EASAPs drive software applications in batch mode, the main task here is to create all the files required to run the underlying software applications in an automated fashion in batch mode. Your knowledge of running this software in batch mode will be vitally important. This knowledge often includes being proficient with the software application’s command, scripting or macro language. However, knowing a software application’s language for running in batch mode does not mean that you will be typing this language into files manually. In most cases, the files can be generated directly from the software application’s interactive interface or they can be created by modifying existing templates.
In most cases, it will be important for you to make batch files that are parametric in nature. Basically, this means that you should define and use variables as inputs instead of constants. Making files parametric will greatly simplify the task of coupling the software application to your EASAP. The parametric concept is especially useful when dealing with geometry, whereby you set up important dimensions as variables as opposed to keying in absolute values.
Before starting to create the EASAP, you should test running your batch files manually first. This means you need to type in the necessary commands at a command prompt to run the software applications in a step-by-step manner as will be done in the EASAP. It does not make sense to start working on the EASAP until you are able to run all of the required software applications from start to finish by hand.
The generation of an EASAP and its user interface basically involves two activities:
The following pages provide additional detailed information on performing these two activities:
When building an EASAP, an important decision that you will need to make is to choose the client used when a user opens the EASAP. Currently, there are the following two choices:
The main advantages for using the Web Browser client approach are as follows:
It is therefore recommended that EASAPs are developed for the Web Browser client. However, for security reasons, web browsers do not allow manipulation of local files and execution of code on the client computer. Since the EASA Client is an installed software application, it is not subject to same restrictions. Therefore, features such as data extraction from local files and execution of custom code actions are only available in the EASA Client. To see the differences between the clients while building your EASAP, you can change a setting on the Options tab in the EASAP Builder tool.
Tip: The recommended approach to choosing the client for an EASAP is to start with Web Browser and switch to EASA Client when the EASAP requires a feature not available in the Web Browser client.
Some Suggestions When you are ready to generate your EASAP, making use of the following suggestions may improve the generation process:
Before releasing an EASAP to the user community, it will be important to test it thoroughly. Testing of an EASAP will be a two step process:
EASA provides an area specifically for authors to perform their testing (see the page “Testing”), to which Users do not have access. For more details on testing EASAPs, see the Testing EASAPs page.
All EASAPs support the use of a Help file, and it is the responsibility of the author to document their EASAP in this Help file. While producing well-designed and easy-to-use EASAPs may minimize the work required to properly document your EASAPs, the need to have a Help file that provides useful information to users will remain. Additional detailed information on the content and creation of EASAP Help files is provided at the Producing EASAP Documentation page.
At this point, you will have properly planned, generated, tested and documented your EASAP, and you are now ready to publish your EASAP for use by others. This final step of publishing your EASAP is actually quite trivial, as it involves just a couple of button clicks (see Publish under the Authoring menu). However, you should be aware of some important issues regarding version control and the publishing of subsequent releases of an EASAP. For more details on this topic, see the Publishing EASAPs page.