cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From brian moseley ...@maz.org>
Subject RE: Cocoon2 Design
Date Thu, 01 Jun 2000 15:06:47 GMT
On Thu, 1 Jun 2000, Jason Reid wrote:

> Step 4 has been the one that I have wrestled with for a
> long time... what is the cleanest mechanism for a web
> "application" to know where to send you next?

i saw an interesting technique once where part of the
application's configuration was a state machine. whenever
you changed state (committing data, for instance), the
application knew exactly where to send you.

i tend to write my web applications this way:

 - route request to a control class based on request uri
 - control class examines request to see if its a request
for a form (GET /employee/add) or if an action was taken on
a form (POST /employee/add)
 - if GET, control class delegates to a class that can draw
the screen and returns a response. end.
 - if POST, control class executes application logic
 - control class delegates to a class that can draw the next
logical screen and returns a response. end.

which screen is the next logical screen after processing the
POST request is usually dependent on which of the form's
buttons was pressed, which fields were filled out or not
filled out, what screen the user was on before GETting this
form, etc. application specific.

i usually just embed the knowledge of which screen to use
when inside each control class. not the most flexible
method, but it suffices until a brilliant designer comes up
with something better.


Mime
View raw message