RE: Where would you start?

["Nathan M. Andelin" <nandel@xxxxxxxxxxxxxxxxxxx>]

> the convolutions we go through to get data out
> of and back into the accounting software system
> are ridiculous.

Domino may be fine for document handling and workflow, but why move data in
and out of the accounting system in the first place?  Other than
illustrating the faults of the current system, how would diagramming the
workflow help?  It sounds like users just need to view and update data.  Why
not use a browser?

Web services APIs may be useful if you have no interest in controlling the
client user interface, otherwise it just adds overhead, and it sounds like
you should control the user interface.  Downloading JavaScript to generate
HTML doesn't make sense to me, because it's more difficult to develop and
debug.  Why not just output HTML directly to the browser?

Regarding your question about separating business logic from presentation, I
typically divide a web application into at least three (3) modules.  A
"Controller" receives requests from the browser and calls "Action Handlers"
which in turn call  "DB I/O Procedures".  The Controller is responsible for
saving and restoring session data, dispatching requests, and handling global
exceptions.  The action handler is responsible for formatting a response to
the browser.  The DB I/O Procedure is responsible for database I/O, data
validation, and business logic.

Following are links to shells of modules.  Asside from the Controller, no
actual presentation APIs, or database operations are performed, but it may
illustrate the separation, which puts similar code in similar modules:

Controller:
http://www.relational-data.com/ascent/aos360ct.txt

Action Handler:
http://www.relational-data.com/ascent/aos360a1.txt

Database I/O Module:
http://www.relational-data.com/ascent/aos360d1.txt


Nathan M. Andelin