You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Nicolas De Loof <ni...@capgemini.com> on 2006/04/11 14:42:15 UTC
Stripes-like RequestProcessor
Hello all,
First, please notice I'm glad with Struts and don't want to start a new
"Is struts dead ?" thread.
I've read Matt Raible's Java web framework sweet spot [1] and I noticed
two points :
- "modern" web framework use conventions to make new developer use the
framework quickly and write less code/conf
- direct use of model objects to get user inputs seems acceptable, even
if loosing the form-bean "firewall" function.
I've quickly looked at Stripes, and noticed the main technical
difference (expect use of java5 annotations) with Struts comes from the
Struts RequestProcessor lyfecycle :
- it requires Actions to extend "Action",
- form-beans must extends "ActionForm",
- populate formbean occurs before validation, so it's requiresd ot be
type-safe.
Creating an alternative RequestProcessor may drop those limitations. To
make Struts work similar to Stripes, it would require :
1. use model beans as form-beans
Struts now can use form-bean not beeing ActionForm using
"BeanValidatorForm" wrapper, but it still require type-safe form-bean
population. I've searched a way to override population and collect
conversion errors as a "first level validation", but did not find a way
to bypass javabean Introspection without fully rewriting processPopulate.
2. action not beeing singleton anymore.
I've overriden processActionCreate to get action beans from a Spring
context (and fall back to standard action creation)
3. invoke an "event" method.
I've write a small event caller Action that looks like a DispatchAction
but does not require the "actionBean" to extend Action.
Did someone make similar experiments ?
I'd be interested in any suggestion that enables use of model beans as
form-bean (using a BeanForm wrapper).
[1] http://raibledesigns.com/page/rd?anchor=java_web_frameworks_sweet_spots
Nico.
This message contains information that may be privileged or confidential and is the property of the Capgemini Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Stripes-like RequestProcessor
Posted by Craig McClanahan <cr...@apache.org>.
On 4/11/06, Nicolas De Loof <ni...@capgemini.com> wrote:
>
>
> Creating an alternative RequestProcessor may drop those limitations. To
> make Struts work similar to Stripes, it would require :
>
> 1. use model beans as form-beans
> Struts now can use form-bean not beeing ActionForm using
> "BeanValidatorForm" wrapper, but it still require type-safe form-bean
> population. I've searched a way to override population and collect
> conversion errors as a "first level validation", but did not find a way
> to bypass javabean Introspection without fully rewriting processPopulate.
>
> 2. action not beeing singleton anymore.
> I've overriden processActionCreate to get action beans from a Spring
> context (and fall back to standard action creation)
>
> 3. invoke an "event" method.
> I've write a small event caller Action that looks like a DispatchAction
> but does not require the "actionBean" to extend Action.
>
>
> Did someone make similar experiments ?
> I'd be interested in any suggestion that enables use of model beans as
> form-bean (using a BeanForm wrapper).
It should be noted that both the proposed changes to merge WebWork2 into the
Struts Action Framework, and JavaServer Faces (and therefore Shale), meet
this set of requirements.
>
> Nico.
Craig
Re: Stripes-like RequestProcessor
Posted by James Mitchell <jm...@apache.org>.
Struts has had the items you listed below (and many others) on our
todo list [1] for a long time, but we haven't been able to get there
as fast as we need to (or would have liked to) and are also just a
few of the reasons driving the decision to go with WW2 as the basis
for the Struts Action Framework (SAF) 2.0.
SAF 2.0 expects to address many of the shortcomings of prior versions
of Struts Action 1 and while we would love to say that we will do all
of this while still maintaining complete backward compatibility
through an extensive compatibility kit, this will all depend on what
the community wants/demands.
[1] - http://struts.apache.org/struts-doc-1.2.x/roadmap.html
--
James Mitchell
On Apr 11, 2006, at 8:42 AM, Nicolas De Loof wrote:
>
> Hello all,
>
> First, please notice I'm glad with Struts and don't want to start a
> new "Is struts dead ?" thread.
>
> I've read Matt Raible's Java web framework sweet spot [1] and I
> noticed two points :
>
> - "modern" web framework use conventions to make new developer use
> the framework quickly and write less code/conf
> - direct use of model objects to get user inputs seems acceptable,
> even if loosing the form-bean "firewall" function.
>
> I've quickly looked at Stripes, and noticed the main technical
> difference (expect use of java5 annotations) with Struts comes from
> the Struts RequestProcessor lyfecycle :
> - it requires Actions to extend "Action",
> - form-beans must extends "ActionForm",
> - populate formbean occurs before validation, so it's requiresd ot
> be type-safe.
>
> Creating an alternative RequestProcessor may drop those
> limitations. To make Struts work similar to Stripes, it would
> require :
>
> 1. use model beans as form-beans
> Struts now can use form-bean not beeing ActionForm using
> "BeanValidatorForm" wrapper, but it still require type-safe form-
> bean population. I've searched a way to override population and
> collect conversion errors as a "first level validation", but did
> not find a way to bypass javabean Introspection without fully
> rewriting processPopulate.
>
> 2. action not beeing singleton anymore.
> I've overriden processActionCreate to get action beans from a
> Spring context (and fall back to standard action creation)
>
> 3. invoke an "event" method.
> I've write a small event caller Action that looks like a
> DispatchAction but does not require the "actionBean" to extend Action.
>
>
> Did someone make similar experiments ?
> I'd be interested in any suggestion that enables use of model beans
> as form-bean (using a BeanForm wrapper).
>
>
> [1] http://raibledesigns.com/page/rd?
> anchor=java_web_frameworks_sweet_spots
>
> Nico.
>
>
>
> This message contains information that may be privileged or
> confidential and is the property of the Capgemini Group. It is
> intended only for the person to whom it is addressed. If you are
> not the intended recipient, you are not authorized to read, print,
> retain, copy, disseminate, distribute, or use this message or any
> part thereof. If you receive this message in error, please notify
> the sender immediately and delete all copies of this message.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org