Re: Extending struts classes

[Dmitri Plotnikov <dm...@fanniemae.com>]

I was interested in the same issue and did not find a good solution, so
I submitted a bug report:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1289

It does make sense for an ActionForm to have access to the context: not
just the session, but also request, response, servlet context and
servlet config.  ActionForms need to be able to access other beans held
in the context, participate in i18n and do other context-dependent
operations.

However, I understand that the whole issue of associating forms with the
context is a gnarly one. These forms are accessed by both actions and
JSPs.  JSPs access their context via PageContext, which conveniently
aggregates all relevant pieces of context: request, response, session,
servlet context and servlet config.  Actions, on the other hand do not
have anything of that sort, they get all these pieces separately.  As a
result of all this, it is unclear what the context-binding API on
ActionForm should be.

Maybe we need to create a whole new object: StrutsContext and make it
aggregate all levels of the context.

What do you think?

Dmitri Plotnikov
CTO
PLOTNIX, Inc

Kristopher.Brown@btinternet.com wrote:

> I want to add a function to all of my forms in which the
> form is capable of initialising its contents. e.g.
>
> public void initUsingSession(HttpSession session)
>
> I want to pass the session to this function so that I can
> populate values on the form depending on what is
> stored in the session.
>
> The trouble with this is that when would I call this
> function?  I looked in the FormTag class, and I noticed
> that if it couldn't find the form class then it just created
> a new instance of it.  This means I can't call that
> function.
>
> Any ideas?
>
> Cheers
> Kris

Re: Extending struts classes

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 11 Apr 2001, Dmitri Plotnikov wrote:

> I was interested in the same issue and did not find a good solution, so
> I submitted a bug report:
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1289
> 
> It does make sense for an ActionForm to have access to the context: not
> just the session, but also request, response, servlet context and
> servlet config.  ActionForms need to be able to access other beans held
> in the context, participate in i18n and do other context-dependent
> operations.
> 
> However, I understand that the whole issue of associating forms with the
> context is a gnarly one. These forms are accessed by both actions and
> JSPs.  JSPs access their context via PageContext, which conveniently
> aggregates all relevant pieces of context: request, response, session,
> servlet context and servlet config.  Actions, on the other hand do not
> have anything of that sort, they get all these pieces separately.  As a
> result of all this, it is unclear what the context-binding API on
> ActionForm should be.
> 

Yes, it is very gnarly.  One of the most important issues is that an
ActionForm instance can easily outlast a single request (if you are using
session scope), it is not reasonable to talk about a single request as
being relevant.  Also, if the application isn't using sessions, then there
is no relevant session either.

> Maybe we need to create a whole new object: StrutsContext and make it
> aggregate all levels of the context.
> 
> What do you think?
> 

The best strategy to deal with the orginally reported problem (wanting to
initialize form bean properties based on things stored in the user's
session) is to arrange your logic to *always* flow through an action that
creates and initializes the form bean, rather than going to the JSP page
directly.  That way, the form bean will always be there when the page
tries to access it, properly initialized.

The Struts example application illustrates this technique.  Consider the
registration.jsp page, where there are links to edit each
subscription.  The links are sent to the "/editSubscription" action, whose
job is to initialize the form bean for the selected subscription and
*then* forward to the appropriate JSP page (subscription.jsp).

> Dmitri Plotnikov
> CTO
> PLOTNIX, Inc
> 

Craig