Not really, or at least not in the context it was being used.
For a start, sure HTTP is a stateless protocol but almost all web
*applications* involve the maintenance of some form of
<semantic>state</semantic>. Isn't that what the session object is all about?
Moreover, there is invariably a persistence layer e.g. RDBMS behind all
this.
Maybe I used the wrong terminology by referring to a *state machine* - I
guess I better find out what the formal comp.sci meaning is. In my case the
interpretation was that there is a unit of business logic responsible for
workflow that understands :
1. a hierarchy of distinct *states* for an entity (<eg>a lease
application</eg>)
2. how the entity progresses through the hierarchy
3. what unit of logic/action achieves the promotion of the entity into each
state
4. through which UI form an action can be performed
In this way each action performed via the whole Model 2 architecture will:
1. result in a new state for the entity
2. the *state machine* then knows what the next state should be, the action
that achieves it and therefore the screen to do it in (and optionally who is
allowed to do it ;-)
Now, just like the other Model 2 stuff like the controller servlet, this
state machine can be implemented in Java, configured via an XML file and
available to the entire web application via the servletcontext.
If there is some major oversight in this approach (quite possible - this
stuff is relatively new to me) I'd really appreciate any input to resolve
it.
Regards
@
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
