You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2005/01/11 18:44:56 UTC
New Struts 1.3.0-dev build available
For the daring, I've put up another round of my work in progress at
http://www.apache.org/~germuska/struts-1.3.0-dev/
I fixed some fairly boneheaded problems with the last version and got
it at least running through the mailreader example app, although then
I realized that I didn't have a taglibs jar and it was time for bed!
But I haven't changed anything in the "forward" processing, so I
think that it's in pretty good shape.
The main issue/question/hitch/dilemma now is to figure out how to
deal with the historical fact that values were stored in request or
session scope, but now are intended to be stored in the
ActionContext. As it is now, I have the ServletActionContext both
calling superclass methods (for storing the values in the
ChainContext) and putting things in the request or session scope.
This has possible synchronization problems in that the reads do not
test the request/session scope -- they assume that the context
already has the right value. Maybe it should skip the superclass
version and only move things in and out of the request and session
scopes.
I'm also wondering right now whether it would be more correct to
construct the ActionContext class in the ComposableRequestProcessor,
thereby committing to it's API for all commands, or whether to stick
with the looser approach currently in place. I haven't thought that
much about the distinctions between an ActionContext and a
ViewContext, or whether we really need to distinguish them or whether
a single one can serve both roles.
Another side note: there are a couple of base commands which have
dependencies on the Servlet API -- they are the ones that deal with
creating Actions and Forms, both of which also have dependencies on
the Servlet API. I'm wondering if we should push that into
abstractions to continue the pattern of having Servlet dependencies
in the "servlet" subpackage, or whether Struts' own API dependencies
make that not necessary or not worthwhile.
I think I'll have this stuff stable enough to commit within the week,
so now is a particularly good time to speak up about design choices
and the like...
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: New Struts 1.3.0-dev build available
Posted by Vic <vi...@friendvu.com>.
THANK YOU!
I think most of us are watching in awe, or at least I am.
.V
Joe Germuska wrote:
> For the daring, I've put up another round of my work in progress at
> http://www.apache.org/~germuska/struts-1.3.0-dev/
>
> I fixed some fairly boneheaded problems with the last version and got
> it at least running through the mailreader example app, although then
> I realized that I didn't have a taglibs jar and it was time for bed!
> But I haven't changed anything in the "forward" processing, so I think
> that it's in pretty good shape.
>
> The main issue/question/hitch/dilemma now is to figure out how to deal
> with the historical fact that values were stored in request or session
> scope, but now are intended to be stored in the ActionContext. As it
> is now, I have the ServletActionContext both calling superclass
> methods (for storing the values in the ChainContext) and putting
> things in the request or session scope. This has possible
> synchronization problems in that the reads do not test the
> request/session scope -- they assume that the context already has the
> right value. Maybe it should skip the superclass version and only
> move things in and out of the request and session scopes.
>
> I'm also wondering right now whether it would be more correct to
> construct the ActionContext class in the ComposableRequestProcessor,
> thereby committing to it's API for all commands, or whether to stick
> with the looser approach currently in place. I haven't thought that
> much about the distinctions between an ActionContext and a
> ViewContext, or whether we really need to distinguish them or whether
> a single one can serve both roles.
>
> Another side note: there are a couple of base commands which have
> dependencies on the Servlet API -- they are the ones that deal with
> creating Actions and Forms, both of which also have dependencies on
> the Servlet API. I'm wondering if we should push that into
> abstractions to continue the pattern of having Servlet dependencies in
> the "servlet" subpackage, or whether Struts' own API dependencies make
> that not necessary or not worthwhile.
>
> I think I'll have this stuff stable enough to commit within the week,
> so now is a particularly good time to speak up about design choices
> and the like...
>
> Joe
>
--
RiA-SoA w/JDNC <http://www.SandraSF.com> forums
- help develop a community
My blog <http://www.sandrasf.com/adminBlog>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: New Struts 1.3.0-dev build available
Posted by Levieux Cedric <ce...@europatrust.com>.
> The main issue/question/hitch/dilemma now is to figure out how to
> deal with the historical fact that values were stored in request or
> session scope, but now are intended to be stored in the
> ActionContext. As it is now, I have the ServletActionContext both
> calling superclass methods (for storing the values in the
> ChainContext) and putting things in the request or session scope.
> This has possible synchronization problems in that the reads do not
> test the request/session scope -- they assume that the context
> already has the right value. Maybe it should skip the superclass
> version and only move things in and out of the request and session
> scopes.
Can we deal with a new attribute in the form-bean declaration ? If yes, we
can add a scope attribute with request/scope(/application) scopes
possibilities and if it not defined we use the historical behavior : session
scope.
It can be easier to implement by this way remindable forms or not.
Just my two cents,
Cedric
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: New Struts 1.3.0-dev build available
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:51 AM -0800 1/12/05, Dakota Jack wrote:
>Hi, Joe,
>
>Awesome! Can you wax eloquent on what the use of the ActionContext is
>here? What "values" do you mean? I assume you mean values associated
>with the instantiation of various Struts classes? I don't know what
>you mean, obviously.
(First, the answer; later, the update on today's build.)
OK, what is the use of ActionContext? The main point is to
articulate the Struts API and insulate Struts classes from
dependencies on other APIs. There are many places in Struts where
the Servlet API is built-in, which makes Struts hard to adapt to use
in Portlets, let alone Web Services.
What I'm working on now is a ServletActionContext implementation of
the ActionContext interface. In places where Struts *needs*
ActionServlet, HttpServletRequest, HttpServletResponse, HttpSession,
etc., it can cast the ActionContext to ServletActionContext and get
them. But by making this explicit, we should be able to catch
ourselves and be much more careful about permitting those kinds of
dependencies. Getting the feel for this has also made me much more
tolerant than I had been of the split between the Abstract classes in
the o.a.struts.chain.commands package and their concrete children in
o.a.s.c.commands.servlet.
Also, by adapting the commands to expect to receive an ActionContext
class, I was able to simplify the command classes considerably. The
original implementations have lines and lines of bean property code
to allow you to configure from the chain-config.xml the locations of
the various things the command needs to get out of its context
(ActionConfig, ActionForm, Action, the result of form validation, the
result of form cancellation, etc...)
Even though bean properties are conceptually simple, I think the
lines and lines of code removed makes things much more
straightforward; furthermore, the emerging concept of a
ContextWrapper means that you could just write your own Wrapper if
you were going to have a context which occasionally stored these
things in non-standard locations.
Now, the update: the build posted this morning actually works all the
way through the mailreader app, and seems to handle everything in it.
The mailreader app is pretty simple, and I strongly suspect that some
of the changes I had to make to get it all running need to be done
more generally -- these are basically to do with where the
ServletActionContext implementation puts things.
I think I am leaning towards having it read and write values into the
request or session in a way more directly compatible with existing
Struts practices, as it's least likely to have surprises -- however,
this sacrifices the "Attribute-Property Transparency" which is
strongly recommended in the design of Context
(http://jakarta.apache.org/commons/chain/apidocs/org/apache/commons/chain/Context.html).
There's probably a way to test both the internal Context as well as
the request or session, but I'm not sure whether there's a
responsibility to copy values from the request into the internal
context if they are used as a fallback. I'm not even sure how to
articulate this to anyone who hasn't been thinking about the problem!
Is anyone following me?
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: New Struts 1.3.0-dev build available
Posted by Dakota Jack <da...@gmail.com>.
Hi, Joe,
Awesome! Can you wax eloquent on what the use of the ActionContext is
here? What "values" do you mean? I assume you mean values associated
with the instantiation of various Struts classes? I don't know what
you mean, obviously.
Jack
<snip>
On Tue, 11 Jan 2005 11:44:56 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> The main issue/question/hitch/dilemma now is to figure out how to
> deal with the historical fact that values were stored in request or
> session scope, but now are intended to be stored in the
> ActionContext.
</snip>
--
------------------------------
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
"You can't wake a person who is pretending to be asleep."
~Native Proverb~
"Each man is good in His sight. It is not necessary for eagles to be crows."
~Hunkesni (Sitting Bull), Hunkpapa Sioux~
-----------------------------------------------
"This message may contain confidential and/or privileged information.
If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation."
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org