What about this model?

[Dan Cancro <DC...@corp.work.com>]

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

Re: What about this model?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

See comments intermixed below.

Dan Cancro wrote:

> 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.
>

If I understand what you are proposing, StateManager sounds a lot like what the
javax.servlet.jsp.PageContext does for a JSP page and the custom tags that run on it.
In particular, the ability to look up and set attributes in the four scopes supported
by the JSP page model (page, request, session, application) seems very similar to the
lookups by lifecycle that you are proposing.   JSP model doesn't support your
"ACTION", or "OPERATION" lifetimes directly (it's not really clear to me what the
lifetime implications of these are), and I'm not sure how "USER" differs from
"SESSION".

>
> 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.

Note that the nasty place where this has been true (the <form:form> tag) is no longer
true -- the tag looks up the corresponding bean class and scope from the config
information if you don't set it.

In practice, I find that about 90% of the time my apps create beans in the business
logic called by the Action, and not in the JSP page.  Therefore, it is rarely
necessary to specify an object class in JSP, although the facility is there if you
need to -- the standard <jsp:useBean/> tag.

>  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

Does this mean you can only have String properties, or are you thinking generalized
objects?  If you are thinking generalized objects, how can you create them (in the JSP
page) without knowing what the Java class or type is?

>
> 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.
>

Just as clarification, this is true for the current Struts tags as well.  If you want
to display information from a bean or bean property, you can use the <bean:write> tag
anywhere.  It doesn't need data typing -- conversion to string happens automatically.

>
> 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.

Why would an Action *ever* care about this?  Images are part of the "view", so it's up
to whatever page you forward to (by logical name) to deal with it.

>  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.
>

IMHO it is better to have the JSP pages make their own decision about what images
folder to use (in this particular example), based on the state of the model at that
point.  Having the action do it means you are typing presentation decisions into the
business logic.

But, in terms of mechanics, there is nothing to doing this that requires a
StateManager abstraction -- JSP pages and the custom tags that run on them already
have access to application scope things, and can do exactly the sort of "search" that
you describe.

>
> 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.
>

Does that mean I cannot have two forms on the page if they use the same field name?

>
> Thanks for reading this far. I appreciate your comments.
>

One very large difference between what you propose and the current Struts model seems
like a big issue to me -- in a JSP page, *every* single access to something managed by
the StateManager must be done through a custom tag (or a scriptlet).  In Struts, you
can create a bean with <jsp:useBean>, get and set its properties with
<jsp:getProperty> and <jsp:setProperty>, and access it transparently with the Struts
custom tags as well.

By itself, that would be something I wouldn't want to give up.  But, as development
tools start to become JSP-aware (and, in particular, JSP 1.1-aware), they will
generally offer nice support for configuring the standard tags visually -- and the
extra level of indirection imposed by the StateManager makes it much more difficult
for an IDE to help a page developer visually compose it.

There may be compelling value in adding the extra indirection layer of a StateManager
over what the standard servlet/JSP APIs provide, but I guess that I'm not really
seeing them at this point.

>
> Dan
>

Craig

>

Re: What about this model?

["Craig R. McClanahan" <Cr...@eng.sun.com>]

See comments intermixed below.

Dan Cancro wrote:

> 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.
>

If I understand what you are proposing, StateManager sounds a lot like what the
javax.servlet.jsp.PageContext does for a JSP page and the custom tags that run on it.
In particular, the ability to look up and set attributes in the four scopes supported
by the JSP page model (page, request, session, application) seems very similar to the
lookups by lifecycle that you are proposing.   JSP model doesn't support your
"ACTION", or "OPERATION" lifetimes directly (it's not really clear to me what the
lifetime implications of these are), and I'm not sure how "USER" differs from
"SESSION".

>
> 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.

Note that the nasty place where this has been true (the <form:form> tag) is no longer
true -- the tag looks up the corresponding bean class and scope from the config
information if you don't set it.

In practice, I find that about 90% of the time my apps create beans in the business
logic called by the Action, and not in the JSP page.  Therefore, it is rarely
necessary to specify an object class in JSP, although the facility is there if you
need to -- the standard <jsp:useBean/> tag.

>  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

Does this mean you can only have String properties, or are you thinking generalized
objects?  If you are thinking generalized objects, how can you create them (in the JSP
page) without knowing what the Java class or type is?

>
> 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.
>

Just as clarification, this is true for the current Struts tags as well.  If you want
to display information from a bean or bean property, you can use the <bean:write> tag
anywhere.  It doesn't need data typing -- conversion to string happens automatically.

>
> 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.

Why would an Action *ever* care about this?  Images are part of the "view", so it's up
to whatever page you forward to (by logical name) to deal with it.

>  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.
>

IMHO it is better to have the JSP pages make their own decision about what images
folder to use (in this particular example), based on the state of the model at that
point.  Having the action do it means you are typing presentation decisions into the
business logic.

But, in terms of mechanics, there is nothing to doing this that requires a
StateManager abstraction -- JSP pages and the custom tags that run on them already
have access to application scope things, and can do exactly the sort of "search" that
you describe.

>
> 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.
>

Does that mean I cannot have two forms on the page if they use the same field name?

>
> Thanks for reading this far. I appreciate your comments.
>

One very large difference between what you propose and the current Struts model seems
like a big issue to me -- in a JSP page, *every* single access to something managed by
the StateManager must be done through a custom tag (or a scriptlet).  In Struts, you
can create a bean with <jsp:useBean>, get and set its properties with
<jsp:getProperty> and <jsp:setProperty>, and access it transparently with the Struts
custom tags as well.

By itself, that would be something I wouldn't want to give up.  But, as development
tools start to become JSP-aware (and, in particular, JSP 1.1-aware), they will
generally offer nice support for configuring the standard tags visually -- and the
extra level of indirection imposed by the StateManager makes it much more difficult
for an IDE to help a page developer visually compose it.

There may be compelling value in adding the extra indirection layer of a StateManager
over what the standard servlet/JSP APIs provide, but I guess that I'm not really
seeing them at this point.

>
> Dan
>

Craig

>