On Tue, July 12, 2005 1:08 pm, Larry Meadors said:
> I still do not see why putting your VO on your action form is a bad thing.
>
> 1) It gives you a super-easy way to map strings (bean.propName)
I guess I'm not clear on this... are you talking about nesting the VO in
the ActionForm, or are you ta
Dave Newton wrote:
Brady Hegberg wrote:
EmployeeVO emp = new EmployeeVO( eForm );
Would that be considered tying the view to the business layer? It seems
like it would work nicely especially since you could use polymorphism if
you needed to generate VOs from other Forms (ie
AnotherEmployeeAc
On Tue, July 12, 2005 1:09 pm, Brady Hegberg said:
> So accepted best practice in this case is to have a method in your
> action that transfers the data from the form to the VO, then pass the VO
> off?
Not usually a separate method, just usually, a single line of code. But
yes, that's the general
Brady Hegberg wrote:
EmployeeVO emp = new EmployeeVO( eForm );
Would that be considered tying the view to the business layer? It seems
like it would work nicely especially since you could use polymorphism if
you needed to generate VOs from other Forms (ie
AnotherEmployeeActionForm).
Yep, t
CTED]
Sent: Tuesday, July 12, 2005 10:39 PM
To: Struts Users Mailing List
Subject: Re: Handling VOs
I still do not see why putting your VO on your action form is a bad thing.
1) It gives you a super-easy way to map strings (bean.propName)
2) It gives you an easy way to perform string->type conv
On 7/12/05, Brady Hegberg <[EMAIL PROTECTED]> wrote:
> So accepted best practice in this case is to have a method in your
> action that transfers the data from the form to the VO, then pass the VO
> off?
IMO, this is sort of a waste if you can do it in the form by adding
the VO to it, and handling
I still do not see why putting your VO on your action form is a bad thing.
1) It gives you a super-easy way to map strings (bean.propName)
2) It gives you an easy way to perform string->type conversions
3) It does not couple your VO to your form
4) While it does couple your form to your VO, who c
And Rick already pointed out reasons it can be a bad idea to pass a map
to a class that extracts the data because you end up with confusion
about fields and lose type checking.
So accepted best practice in this case is to have a method in your
action that transfers the data from the form to the VO
I would say no, it's no more acceptable (acceptable being a relative term
of course!).
An EmployeeVO, presuming that is an object passed form the control layer
to the model layer, still needs to know about something in the view layer,
the ActionForm. Hence, it's not really any better.
In reply t
Rick sent the example code below to an user earlier and I was just
wondering. Would it be acceptable to generate the EmployeeVO using a
constructor like:
EmployeeVO emp = new EmployeeVO( eForm );
Would that be considered tying the view to the business layer? It seems
like it would work nicely e
10 matches
Mail list logo
