> -----Original Message-----
> From: Jim Barrows
> Sent: Tuesday, September 07, 2004 1:44 PM
> To: Struts Users Mailing List
> Subject: RE: A couple of questions
>
>
>
>
> > -----Original Message-----
> > From: Marco Tedone [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, September 07, 2004 1:22 PM
> > To: Struts Users Mailing List
> > Subject: Re: A couple of questions
> >
> >
> > What do you mean? This is often our case. I mean, we often
> > have composite
> > value objects: one that contains another, which contains
> > another. Are there
> > any issues with such design?
>
> Depends :)
Okay, the previous post is why you shouldn't take phone calls and answering cow-orkers
complex question while answering questions on the list. *SIGH*
Take two.
Depends :) Which way you look at the problem. It's not any worse then what you're
already experiencing with doing it yourself. After all, the ActionForm is just a
convenient envelope to store your request parameters nothing more.
If you try and think of it as a VO, then you can end up with interesting design
choices.
Ignore the below
>
> I typically don't look at the model when designing my UI. UI
> gets designed, and then if I don't have a legacy DB, create
> the backend from there. Otherwise I just use the VO as a
> container until I hit the DAO, which handles putting the VO
> into the right table(s).
> Then there are the complex cases. Like the one below. How
> do you design a UI that will easily allow a user to
> manipulate Master/Detail data? Then how do you do that in
> the web world where everything is a String, and there is no
> such thing as collections of fields, much less objects.
> Hence the problem. HTTP is woefully inadequate for
> applications. ActionForm is a good attempt at bridging that.
>
> I like using ActionForm strictly for input, and for view only
> will use the VO directly. Some people use the ActionForm for
> input and output. So, we end up with two solutions. One,
> in which the ActionForm directly mirrors the VO. So you would
> have the VO as below, converted to all strings, and the array
> of order lines being an ActionForm as well. It should be
> fairly easy to figure out how to build the jsp from that. A
> whole lot of ActionForms. A whole lot of formatting that has
> to be done for display in the Action class. You have to code
> the JSP's with the path to the field (form.subObject.fieldName) etc.
>
> The second solution, is to do the UI differently. You
> directly display the VO as you have it, in JSP using the <fmt
> or <bean:write tags to write out the data etc. so it looks
> good. Then you provide an edit button to edit data in the
> master record. Basically, that button takes you to a page
> that uses an ActionForm specialized to the Master record.
> Saves the data either to the DB, and then back to the view
> page which pulls from the DB, or to a Session attribute which
> the page then reads from. Each detail line is done the same.
>
> If you only allow one (or a limited numberof) field(s) in the
> children to be edited, then you could use a single form with
> arrays of the fields, and an action to apply the edits to the
> data. You could also have a form for each child. It's one
> ActionForm class, however for each child you would have a
> different form, with hidden fields filled in, all going to
> the same action and maybe a bit of JS to submit the form for
> changes etc.
>
> The second way give you some more flexibility, and fewer ActionForms.
>
> This isn't really a problem with ActionForms exactly, imho,
> but rather the web in general. Even if you just map request
> params directly into a VO, you have the same issues you do
> with an ActionForm. The difference being what we've already
> discuessed.
>
> >
> > Example:
> >
> > public class OrderVO implements Serializable {
> >
> > /** Order lines */
> > private LinesVO[] orderLines; //Eclipse will do the rest
> >
> > //Other attributes....
> >
> > }
> >
> > public class LinesVO implements Serializable {
> >
> > /** Line Items */
> > private LineItemsVO[] lineItems;//Eclipse will do the rest
> >
> > //Other attributes...
> > }
> >
> > public class LineItemsVO implements Serializable {
> >
> > /** Item code */
> > private int id;//Eclipse will do the rest
> >
> > }
> >
> > And so on.
> >
> > >
> > ActionForms aren't perfect. However, what they buy you in terms of
> > everything else, usually make them well worth it. Where
> > they tend to be a
> > bit of a pain is in trying to model complex object models
> in one form.
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
