On 12/15/05, Paul Benedict <[EMAIL PROTECTED]> wrote:
>
> Action Forms are DTO objects. They are not your model/domain/business
> objects. Struts is the only
> framework (historical design) that forces you to use String objects in the
> Form/DTO, but that's
> not a bad thing. It's a container to accept user input, which is all from
> the Internet transmitted
> as strings. You can of course have non-string values in the form, but
> those should NEVER accept
> input -- and it's because the input needs a place to reside as Strings
> before the validator can
> validate them. Otherwise you would blow up with bad input when the
> conversion fails.


Ok, yes you aren' t telling me anything new or addressing the problem that
still needs to be solved. Sure you can state the reason of why ActionForms
should only have String properties... been there explored that... that's not
my question. I'm concerned with having to deal with that limitation then how
DO you deal with the 'model/domain/business' objects that do need to get
populated?  Sure in a simple form it's easy, but real life is a different
story. Many times you get back objects that are nested in Collections and
those properties in those domain objects have to be translated somehow to a
front end representation that can update them when the form submits. Various
approaches exist to this. What is your preferred approach?

Now this will change with Struts 2.x; there is an automatic type converter
> and you can submit into
> model/domain/business objects.



I'll have to look into this. Is  this feature documented anywhere other than
in the 2.0 src?

--
Rick

Reply via email to