On Samstag, Mai 31, 2003, at 06:09 Uhr, Ted Husted wrote:
florian wrote:
i think this has been discussed before.. but wouldnt it be possible
to simply
have the actionform methods delegate to the value objects accessors?
when the form is populated it looks for getter and setter methods, no?
Which
florian wrote:
i think this has been discussed before.. but wouldnt it be possible to
simply
have the actionform methods delegate to the value objects accessors?
when the form is populated it looks for getter and setter methods, no?
Which means it would be an excellent time for someone to summariz
Any and all of these are best practices. Practices are like patterns.
Which is "best" for your depends on your circumstances. It's not
something anyone else can decide for you.
Quite a bit depends on what you do on the business layer. An application
needs to cater to the business layer, and eac
On Donnerstag, Mai 29, 2003, at 06:28 Uhr, Jordan Reed wrote:
All,
I'm on a team that's trying to decided on a best practice for passing
on
populating our value objects that get passed to our business layer. We
currently have three techniques we've though up and I'm wonderful if
anyone
has a
ActionForms should carry a Strings only health advisory ;-)
Steve
> -Original Message-
> From: Jordan Reed [mailto:[EMAIL PROTECTED]
> Sent: May 30, 2003 11:04 AM
> To: Struts Users Mailing List
> Subject: Re: Populating Value Objects for the Business Tier
>
>
&
Plus you have security issues, it is simple to spoof the form
submission and set properties other than the ones that correspond to
form fields (that is, if there are any other properties on your value
object).
I copy properties using BeanUtils where possible, and for cases where
that doesn't w
I've been playing #3 (Just included the value objects in the form) and run
into one of those things that probably makes people break into tears.
I have int types in the value object... And since they cannot be null, when
the form is prepopulated or repopulated they appear as "0" instead of being
b
+ 0 Mike.
I show the methods 1-3 when I teach and in my 2nd Struts book.
Then I teach formBean has a DAO helper (is a/has a)
In action you just say:
formBean.populate(req.getParm);
And then in baseFormBean:
populate(Object o) {
myDao.populate(XX); // populate DAO from DB
_list = myDao.getData(); /
I would suggest option 1, with a slight variation.
I think it is best to keep action classes as lean as possible.
Rather than doing any heavy lifting in an action class it is better
to make calls to delegates and other helper classes. The modular
nature of the code enhances code reuse and mainta
2 & 3 generally end in tears. They sound nice, but when you get down to the
fiddly bits you will find it more problematic than you expect.
As you mention, the action form is very much a view object. For a start
everything in the actionForm will be strings, while your business object
probably will
I prefer the 3rd choise. As far as I known, it's the
recommended struts-way to go. One of the reasin is
that your bussiness logic is framework independent. In
case you need another kind of client instead of
browser or your boss like something other than
STRUTS,what should you do to your exisiting w
11 matches
Mail list logo
