Craig,

The ActionForm class definition seems to imply that it was intended to 
contain only editable data (i.e., the reset and validate methods).  
Distinguishing between read and write functionality in the enterprise 
systems I have developed was always a major advantage, both in extensibility 
and code maintainability, as usually each type of functionality had 
different processing requirments.  It seems that if we mix read and write 
functionality into one ActionForm instance, we will have some "bulky" 
classes to maintain.  Any comments?  Thanks.

>From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: [EMAIL PROTECTED]
>Subject: Re: ActionForms for read-only data??
>Date: Mon, 11 Jun 2001 17:01:31 -0700 (PDT)
>
>
>
>On Mon, 11 Jun 2001 [EMAIL PROTECTED] wrote:
>
> > I have a Struts theory question on use of action forms versus java beans
> > for read-only data.
> >
> > We have extended workflow on our website such that the same form can 
>look a
> > bit different depending on where you are in the workflow.
> > For example, the quote request will have limit and retention fields in 
>the
> > business request section.  Once you get to quote, those fields are
> > read-only and there's an additional quote amount field.  When the client
> > requests binder, all those fields are read-only and there is a checkbox.
> > Once bound, everything is read-only.
> >
> > There is some disagreement on the team as to how to handle this case.  
>We
> > will obviously have four JSPs, one for each of these presentations.  The
> > question is the data mapping to beans.
> >
> > Half of the team feels that to use Struts in its purest sense, we need 
>to
> > have java beans that represent the read-only data, and action forms to
> > represent the editable data.  That would mean four action forms, one for
> > each JSP.
> >
> > The other half of the team wants to re-use the same action form for all
> > four cases, bean:define it in the session, and use bean:write to print 
>out
> > the data if read-only.  The major advantage is simplicity - we have one
> > bean that represents all of the data - there is no need to understand 
>what
> > part of the workflow we are in when translating the data from the data
> > model to the presentation layer beans.  It is also easier to understand 
>for
> > an HTML programmer or developer that the same bean is used regardless of
> > whether it is a bean:write or any of the html tags.
> >
> > We certainly don't want to end up in a position where we have broken the
> > framework and hurt our extensibility in future releases.  The first
> > scenario would seem to follow the framework more closely, but in this
> > special case, is it a problem to deviate and use the ActionForm for what 
>it
> > is - a bean?
> > We would appreciate any advice and experiences.
> > Thank you.
> >
>
>Ted covered a couple of the issues in his response -- I'd like to add a
>few more thoughts.  I don't think there are cut-and-dried answers to an
>issue like this, so it's a question of balancing the tradeoffs.
>
>If you are using the same JSP page itself for the different views of the
>same information, you probably already have conditional logic in it about
>whether to make a field editable or read only.  In such a case, I don't
>think it necessarily violates the Struts philosophy to use the same
>ActionForm bean.  In fact, the Struts example application includes a
>miniature example of this use case like this:
>
>   <logic:equal name="registrationForm" property="action"
>               scope="request" value="Create">
>     <html:text property="username" size="16" maxlength="16"/>
>   </logic:equal>
>   <logic:equal name="registrationForm" property="action"
>               scope="request" value="Edit">
>     <bean:write name="registrationForm" property="username"/>
>   </logic:equal>
>
>which makes the username field editable in create mode, but read only in
>edit mode.
>
>Note that you do not actually have to use <bean:define> to introduce the
>ActionForm bean if it's the same bean used in your <html:form> tag -- the
>standard Struts logic will introduce it for you.  It can be used exactly
>like any other bean, from within the nested body of the <html:form>.
>
> >
> > Lisa Stephens
> > GeneralCologne Re
> > Trumbull, CT
> > 203 328 5227
> >
> >
>
>Craig McClanahan
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Reply via email to