struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Molitor" <>
Subject Re: [action2] Leveraging known constructs (was Public API first draft)
Date Fri, 05 May 2006 16:25:13 GMT
Happily XWork has no dependency on web development at all, I use it to
provide a command pattern for autonomous path finding robots for
instance. Anything less than complete abstraction at the action level
would be vetoed by most of the existing developers. (At least I hope
they would vote it down as a bad idea.)  While you may see such
interfaces as *Servlet which provide a convenient way to access the
ServletSession their use is generally frowned upon.

One of the driving factors that pushed me to WebWork, really XWork in
this case, is that it has no hard dependencies on the Servet API's.
There already exists code for invoking actions via SWING, XML, JMS,
etc. You can just as easily use your actions in a service layer as
well as in the web tier. (From various discussions I've come to the
conclusion that there are two schools of thought on this. The Carreira
model which says its quite fine to have your actions in the service
tier, and the Porter(Lightbody?) model which says have your actions
live above the service tier. However in both instances you still
wouldn't be bound to the Servlet API)

I would argue thought that since WebWork supports portlets already,
removing support in SAF2 shouldn't be taken lightly.


On 5/5/06, Paul Benedict <> wrote:
> I will return to the boards shortly, I hope :-) But I've been
> reading and need to address this:
> Please be mindful not to buttonhole Struts into a servlet-only API.
> One of the large efforts of the Tiles refactoring is to remove all
> references of the Servlet API, so that it could be used in a portlet
> environment (as well as anything else I suppose). Struts 2.0 should
> be flexible enough that you can run this in a portlet environment too.
> By far, we don't have to support portlet functionality in 2.0, but
> if we design without this in mind, we will not be able to retrofit
> any API easily in 2.x.
> Also also to make sure the public API is not dependent upon JSP.
> There were too many 1.0 utility methods that required access to the
> JspContext to get things out of the request or session.
> Make sure that problem isn't duplicated here, because the UI could
> be anything, not just JSP.
> Paul
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message