The process of developing an app using Platypus portrayed in the tutorial is rather idealised. It assumes that each stage of the process is completed before the next is begun, and that each stage is completed without error.
In practice, we follow a different process. We work through the app workflow by workflow rather than stage by stage, and we do make some errors :-). We find that having complete HTML and the developers' configuration files are the most crucial parts of the process.
The following sections describe our experience in more detail. We start from the moment NewApp has been run: we should have a directory structure, Makefiles and HTML files (not marked up).
We generally proceed though the app workflow by workflow. Within a workflow, we start with the first PO, develop it for a while, then move onto the next PO in the workflow.
At the very beginning, we start with the Welcome page. (This may be several POs, making up a frameset page.) The Welcome page usually has little dynamic content, and is an easy kill.
Once we have selected a workflow, we check whether it needs any Commit POs. If it does, we add these to the system. Some hints on adding a PO are here.
Once we have selected a PO to work on:
make -s build_1
.
make
-s build_2
. make -s build_2
.
billabong
. This is
currently the best way to discover if your config files are correctly
setup. Billabong will throw exceptions and die if there are problems.
From experience, the FIELDPATH, DATAFROM and ACCESS fields in the IDS
are the most frequent culprits.
make -s build_3
. This will compile
Java in all three layers (and in the util/ directory). Depending on how you
configure your server, you may need to run make -s jar
.
Once we've started on a PO, the question is: How far do we take the PO before we move onto the next PO?
We assume that testing will find some bugs, and cause some changes in the conf files or html. It may also cause changes which only affect the Java, but these are easily dealt with because they don't cause regeneration of the conf files or skeleton Java.
The main issues are:
I found that I used Squirt in an iterative process. As I went through BOs that required some query, I created the necessary SQL and QUERY section required and then re-ran Squirt. The stub code was then inserted into the correct BDO-BO file and the necessary linking call (and any data checking, conversions, etc) put into the PO-BO file.
The overall result is that we tend to proceed workflow by workflow. In a workflow, we take each PO as far as doing a sanity check on the presentation skeleton code. Once we've checked the developers configuration for the workflow, we rerun Billabong and take the workflow to completion.
There are two aspects to merging the new code into the hand-edited code when one of the generated files has to be regenerated. First, the new code must be copied into the hand-edited code. Second, the newly copied code should be hand-edited.
Let me repeat that second point: Newly copied code should be hand-edited. This is easy to forget, and causes problems.
Note: Only one pass of the directories should be run in each
invocation of make. After changes to the HTML files, invoke make with
build_1
. Then do the appropriate edits to the conf files before
invoke make with build_2
. Finally, do the appropriate edits to
the conf files before invoking make again.
Changes to the HTML will cause the conf file to be regenerated. The Makefiles will try to merge the changes into the hand-edited conf files. Consider three cases:
Changes to the conf file will cause the presentation layer skeleton to be regenerated, but will not automatically cause Billabong to be rerun.
Any new code created in the presentation layer skeleton must be copied into the hand-edited code, and any necessary hand-edits applied.
If the conf file changes affect the business layer, Billabong and possibly Squirt may need to be re-run. Squirt will only need to be re-run if a QUERY section has changed.
If you have to run Billabong and haven't done any hand edits in the business area, it's safe to direct the output to the business area and use the OVERWRITE parameter when invoking the billabong script.
If hand changes have been done in the business area, then life becomes more difficult. You must direct the output of Billabong to another directory and cut'n'paste the necessary changes into the affected BO files. If an IDS is changed, it can affect a number of BO files. For and IDS with DATAFROM set to DATABASE, the PO-BO may be affected, as will as possibly a BDO-BO - look at the table related to the ACCESS for the IDS to determine which one.