struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tamas Szabo <szab...@gmail.com>
Subject Re: The framework I think I want...
Date Fri, 06 Jan 2006 11:58:46 GMT
On 1/6/06, Michael Jouravlev <jmikus@gmail.com> wrote:
>
> On 1/5/06, Tamas Szabo <szabtam@gmail.com> wrote:
> > >
> > > I'm actually quite happy with what Struts has to offer except for the
> > > deal with having to use ActionForms. I'd really like a Struts-like
> > > framework but allows me to use POJOs to capture my data and provides a
> > > nice way to redisplay that data back to the user if validation fails
> (ie
> > > a POJO that backs a form with a Data datatype will display back the
> > > String they entered).
> >
> >
> > You can bind request parameters to POJOs using Spring.
> > And you can use the SpringBindingActionForm to redisplay the data to the
> > user.
>
> From
> http://www.springframework.org/docs/api/org/springframework/web/struts/SpringBindingActionForm.html
> "Note this ActionForm is designed explicitly for use in request scope."
>
> Will not work for me.


Not out of the box. But you can extend it.
We extended it, and use the subclass one in session scope.

The other interesting thing is that you can't use <c:out ...> on properties
exposed via a SpringBindingActionForm. That's probably because
JSTL tags don't get properties using Commons Beanutils ...

But if we are at the subject of binding request params to business layer
objects...
Probably a lot of people bind req params directly without using ActionForms
just
to avoid writitng all the ActionForms. How do you assure
that only the allowed properties will be set in the object?

Ex. we have a bean with prop1, prop2.
Only prop1 is allowed to be changed, but no one can prevent someone sending
a request having a prop2 parameter in it. If you bind the request params to
objects directly
prop2 will be set to the value set by the "misbehaving" user.
I know a few solutions to this, but in all of them you will have to
explicitly specify all the
properties that are allowed to be set.
And if you do this then it's the same as declaring these properties as a
DynaActionForm
or to give it to a tool that generates an ActionForm ahving all these
properties.
So why is it better to bind  request params to business layer objects
directly without using
ActionForms?

Tamas

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message