struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Jouravlev" <jmi...@gmail.com>
Subject Re: Thoughts on 1.3.x
Date Thu, 29 Jun 2006 00:49:00 GMT
Paul, not related to your issues (and I do not have answer/opinion on
them), but more related to the message header: see more 1.3
issues/features/questions here:
http://wiki.apache.org/struts/SAF1RoughSpots

I don't know what is the best place to discuss all this stuff, here or
in Wiki. I am ok with either.

About sessions and pluggable implementations. I was thinking about
borrowing FlashScope idea from Tapestry/Stripes. But you have
generalized it, making it just pluggable storage. This is definetely
something to think about!

Stuff like FlashScope will help primarily implementing
Redirect-After-Post (sure, what else can I think of) with greater
ease.

Also, ASP.NET has SQL database scope. Basically just MS SQL database
configured for temp entries with automatic removal of
orphaned/obsoleted entries. This is also something to consider.

On 6/28/06, Paul Benedict <paul4christ79@yahoo.com> wrote:
> I have two concerns on the 1.3.x line. What do you think?
>
> 1) Spring 2.0 has fabulous support for dependency injection for Struts. In particular,
the great Autowiring(Tiles)RequestProcessor will automatically inject dependencies into the
actions as they are created. This supports the "legacy" RequestProcessor and I have no personal
plans to depart from its use. So my question today is: does the RP in 1.3 function just as
it did in 1.2? If not, I may not want to upgrade to 1.3.x until it does.
>
> 2) I learned the tough way that it is [a] impossible to write a stateless application
in Struts and [b] use Struts' locality features at the same time. This is because Struts only
stores the locale in the session, and there is no way (currently) to move that into a cookie,
or into request scope. I found scattered code among RequestProcessor, RequestUtils and TaglibUtils
which look only into the session for the current locale.
>
> I propose (and I will write this) that we allow pluggable implementations into how to
store the locale. It will be defaulted into the session, with other pluggable implementations
provided. However (sorry fans of CoR) this implementation must be wrapped into a bean so that
other libraries, like Tiles and Taglibs, can retrieve the locale and set it without knowing
the pluggable strategy. So the solution itself cannot be limited to the RP chain, even though
that is where it is initiated.
>
> Paul
>
>
>
> ---------------------------------
> Want to be your own boss? Learn how on  Yahoo! Small Business.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message