> -----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 :)
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]
