The concept of workflows is central to developing a Platypus app. This section describes workflows in the context of the tutorial application, Timesheet.
The sample application is an employee timesheet. Those of you familiar with Enhydra will quickly recognise the timesheet app as a typical Enhydra servlet: It has an HTML front end and is backed by a PostgreSQL database. Like other Enhydra apps, the database may be changed.
The timesheet application can be (and is) used for employee time reporting. Employees can report their activities based on calendar days and run reports to generate their timesheets. Simple, really.
Later additions to this application will involve better reporting capabilities, the ability for supervisors to view others timesheets, etc. Since the application is an Open Source project, we'd like your help!
The timesheet app is shown here. Each bubble is a presentation object (including the dashed-line bubbles). A workflow is a string of presentation objects which, in their normal use, are invoked sequentially. (The dashed bubbles aren't displayed to the user. See Commit POs, below, for more details.)
The Welcome PO is the central PO of the app. It has links which lead to each workflow in the app. It is not really part of any workflow. Every page will have a link to the Welcome PO.
The app has five workflows:
The ReportPeriod workflow is the simplest example of a workflow.
By convention, a PO is named by the workflow it is a part of, and the role it plays in that workflow. Thus, the ReportPeriodQuery PO is gathers the parameters to the database query used in the ReportPeriod workflow. Likewise, the EditPersonForm PO displays a form which allows the fields of a Person record to be updated (or initialised).
We also have a convention regarding the naming of workflows, although we tend to be more relaxed about it. The prefix of a workflow describes the type of operation done by that workflow, and rest of the name describes what is being operated on. For example, the EditPerson workflow edits a Persons details in the database. Likewise, the AddOneItem workflow adds a new WorkItem record to the database.
We always use word-initial-capital (WIC) names for POs. The role within the workflow is given by one word (eg Query, Form), the workflow may be several words (eg ReportPeriod, EditPerson). Thus, the last capital begins the role, and everything before it is the workflow.
Some more information on workflow and PO naming conventions is here.
"Commit" POs add a new record to the database. We do not display this to the user, for the following reason ...
The pages served by Enhydra are dynamic, and are usually not cached. If the browser redraws the screen (for example, if the browser is resized), the browser resends the request to the server. The server will execute the PO again - and add another, identical, new record to the database if thats what the PO did the first time the page was served. (At least, this is the behaviour we observed, without joy, under Netscape.)
We have found that serving the Commit page with a client-side redirect to the next PO prevents this behaviour.
We don't use a Commit page for database updates, because they only update an existing record. Doing this twice is inefficent, but doesn't cause errors. We decided that occasionaly duplicating a database update was more efficient than always serving the separate Commit page.