Craig, can you explain point number one "Expose the data as JavaBeans *other
than* the form bean". Is it that you are not using the form bean?
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, June 14, 2001 1:19 PM
Subject: Re: ActionForms for read-only data??
>
>
> On Thu, 14 Jun 2001, hi there wrote:
>
> > 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.
> >
>
> There are probably multiple reasonable approaches to dealing with
> read-only data. Let's consider some of the ways you can do this:
>
> (1) Expose the data as JavaBeans *other than* the form bean:
>
> This is quite easy, since you can do things like <bean:write>
> to generate the output, <logic:xxxx> to test, and so on.
> However, you are mildly increasing the linkage between the
> model layer and the view layer -- now the developers have to
> agree on the bean name, and the properties to be used. The
> tradeoff is that you might be able to reuse beans (such as
> value objects in an EJB based app) that already exist.
>
> (2) Copy the read-only data into the form bean:
>
> This is particularly useful in several use cases:
> - You only want to access the data nested inside the <html:form>
> - You don't want to create the extra dependency on a bean name
> (since you can reference the form bean implicitly)
> - A particular property might be read-only in some uses of the
> form and read-write in others (see the "username" field of the
> RegistrationForm bean in the example application).
> However, adding new properties means going back and updating the
> form bean class every time, which can be tedious if it's not being
> automatically generated.
>
> In practice, I have used both techniques -- but in particular I find
> myself needing data outside the nested body of an <html:form>, in which
> case I really need to use technique (1) anyway.
>
> Part of my internal system documentation (for the various developers) is a
> clear description of the bean names (and scopes), and the properties that
> they expose, that the page developer can count on. This seems to deal
> with most of the manageability issues, but none of these apps have had a
> very long life yet since Struts has only been around a year :-).
>
> Craig McClanahan
>
>
> > >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
> >
> >
>
