I want to add one thing to Raghu's advice:
You only need String-only DTOs at the form layer for INPUT variables only.
Anything you retrieved
from the business layer can be stuck in the request as it is for display
purposes, or attached
right to the form. You may want something like this in your array:
Pretend you have a class with 50 attributes. You obviously don't want "double
the objects" and you
won't, because you only model the portion that belongs to your input. You could
do this:
public class LineItemInputDTO {
LineItem item; // use this to display read only data
String inputAttr1;
String inputAttr2;
}
So you could create this object, as I said, in the "load" method -- and then
once you're happy
with the validation in the "savE" method, you convert those input attributes
back into the actual
model.
Paul
--- Raghu Kanchustambham <[EMAIL PROTECTED]> wrote:
> Have a strDate which is of type string. The setStrDate() needs to be coded
> in such a way that it sets the date attribute also which is of type Date.
>
> The getDate() which returns Date object can be used in the "business"
> layers. For example, my Hibernate mappings map to getDate and not to
> getStrDate... but my setStrDate is used at the struts form layer.
>
> While I do see the point of not mixing your business objects with DTO's, for
> most *small* applications I see it as a overhead (mostly from maintenance
> point of view) to separate them. You would end up doubling the number of
> your business objects. Atleast on the small application I started off with
> struts, I have just one or two attributes for a class with around say 10
> attributes which require this workaround. So I did rather "contaminate" my
> class with a few strXXX attributes rather than create a separate class
> (called DTOs and business objects), ofcourse contrary to the common wisdom !
> :-) I have been using this on my current *small* application and it doesnt
> seem to give any problems.
>
> The other way to not "contaminate" your business classes would be to define
> these attributes in the dyna form, do the validation on these additional
> attributes and on submit (if the validation passes) populate the business
> object (in your action class).
>
> You can choose your poison! :-) or wait for later releases of struts to take
> care of this more elegantly! :-)
>
>
> Regards,
> Raghu
>
>
>
> On 12/16/05, Rick R <[EMAIL PROTECTED]> wrote:
> >
> > Cutting right to the chase...
> >
> > I'm curious on how others handle the age-old struts problem of: "How do
> > you
> > handle nested objects in an ActionForm that have non String properties
> > that
> > might be editable by a user on a JSP?"
> >
> > To provide a watered down example...
> >
> > Imagine you go to the DB to get a List of Company objects. Each company
> > object in the List has nested in it a List of Division objects. Each
> > Division has a "date" field in it (say a startDate). You then need to
> > display a form that displays the companies and divisions and could allow
> > the
> > user to edit the date (in a free-form text field) and submit the form.
> >
> > Things work fine if you didn't have to worry about form validation - in
> > which case, you could just have one property in your ActionForm: List
> > companies; //set/get and you are done (using the List of Company value
> > objects). You'd display the data on the form and submit and things are
> > nice.
> >
> > However, nested sort of deep is that "date" field. If the user enters in
> > the
> > date wrong we want to return to the page and display what they entered so
> > they can fix it. This can't be done if you just want to use the nested
> > value
> > object(POJO) approach.
> >
> > This above scenario is Strut's biggest weakness. (It's compounded with
> > BeanUtils crazy notion of also not keeping wrapper clases like Integer
> > truly
> > "null" when a String is null - instead it decides to make the Integer 0).
> >
> > Besides wondering how others deal with this annoying problem (other than
> > moving to another framework like JSF), I was wondering if maybe DyanForms
> > could be a solution? Can you nest them ? If so then that might be the
> > answer. Typically I haven't been too fond of DyanForms in the past (for a
> > couple of reasons), but if it could solve this issue it would definitely
> > be
> > worth their use.
> >
> > --
> > Rick Reumann
> >
> >
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
