All,
I'm just getting started with struts, but wanted to get your opinion of a
model I was going to use before I came across struts and learned about Model
2. Let me know what you think about this model. It's just like the struts
Model 2 model, but has an additional component I'm calling StateManager,
whose only job is to handle the problem of statelessness on the web.
This is how it works:
A request comes in to the controller servlet. The controller servlet
creates a StateManager instance and passes control to the appropriate Action
class, say LogonAction. LogonAction gets the relevant state information
from the StateManager, performs some action with the Model classes (EJBs),
then passes the updated state information back to the StateManager. The
controller servlet forwards control to the appropriate JSP. The JSP
retrieves the updated state information from the StateManager, and the
response goes back to the browser.
The nice part about this is that the Action classes and JSPs don't have to
concern themselves with the actual data storage vessels at all, namely
entity Beans, session beans, cookies, URL parameters, html form fields,
session database records, etc. Instead, the smart Action classes exchange
information with the StateManager by specifying a key and a lifetime, such
as USER.FIRSTNAME and SESSION. The dumb JSP pages just ask for information
by item name such as "USER.FIRSTNAME". Lifetime values could be one of
these: ACTION, REQUEST, OPERATION, SESSION, USER, or APPLICATION. Each of
these lifetimes would have a corresponding storage vessel, but only the
StateManager needs to know what it is.
A typical scenario would associate lifetimes and storage vessels something
like this:
Lifetime: Storage Vessel:
ACTION Hashtable maintained by the StateManager
REQUEST ServletRequest object
OPERATION Hidden form fields
SESSION HttpSession object
USER Cookie
APPLICATION Properties file
The dumb JSPs don't need to have the bean class names and package names
hardcoded in them. Instead, they only contain JSP tags that specify by item
name the item they are bound to, such as "USER.FIRSTNAME". They do not need
to be contained inside a form tag if their information doesn't need to be
POSTed, or if they are not logically associated with any other item on the
page.
The Action classes do not need to concern themselves with unrelated things.
For example, the LogonAction does not need to know the path to the images
folder. If a JSP needs to know this path, it just asks the StateManager for
"IMAGES_FOLDER", and the StateManager looks for that in each of the lifetime
storage locations until it finds it stored in the APPLICATION storage
location. It searches the locations one by one from shortest to longest
lifetime in the order I listed above. If the LogonAction wants its JSP page
to use a specific images folder, it just puts a special value for this in
the ACTION lifetime, so the StateManager will find and use it before it
finds the standard one contained in the APPLICATION lifetime storage
location.
You don't need to have ActionForm classes (and all of their getters and
setters) to preserve information from request to response. Rather, the
StateManager will provide a JSP with a "USER.FIRSTNAME" value by getting it
directly from the request object, which it knows to be the storage location
for the REQUEST and OPERATION lifetimes.
Thanks for reading this far. I appreciate your comments.
Dan
Alt MVC Model.gif
Alt MVC Model.gif
