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/02/13 21:31:52 UTC
Change Action, ActionForm to use ActionContext?
>I believe now that we have a decent grounding to begin using the
>ActionContext as the request-scoped parameter throughout Struts - I
>think it can be applied to ActionForm and Action to hide
>dependencies on the Servlet API (and in ActionForm, to finally
>deprecate ActionErrors!)
>
>Are there any reasons not to press ahead with changes like that?
I feel quite uncomfortable with committing significant changes to
core classes like Action and ActionForm without some more review, so
I'm going to be much more explicit about what I'm thinking. I could
provide patches, or an alternate source build for download, but I
think I can express the most important parts in email.
Here are the first two things I would do:
[1] in Action, deprecate:
public ActionForward
execute(ActionMapping,ActionForm,HttpServletRequest,HttpServletResponse)
in favor of
public void execute(ActionContext)
The base implementation in Action would delegate to the old signature
for as long as we saw fit to preserve it. It would take the
"ActionForward" returned by the old signature and call
context.setForwardConfig(ForwardConfig). Would it be worth returning
anything from here? This is now so close to the interface for
Command that I wonder if somehow it should be explicitly linked.
However, it's not a command, in that it's not expected to be used by
a commons chain. Is it worth relating them to each other?
[2] in ActionForm, deprecate:
public ActionErrors validate(ActionMapping, HttpServletRequest)
public void reset(ActionMapping, HttpServletRequest)
in favor of
public boolean validate(ActionContext)
public void reset(ActionContext)
In both of these cases, the implementations would simply delegate to
the deprecated methods. The new validate would return "true" if the
delegated validate returned null, or a size 0 ActionErrors,
otherwise"false"
This would allow us to finally deprecate ActionErrors, which would be nice.
As a consequence of doing this, we might be able to go through other
parts of Struts and replace methods which explicitly depend on
HttpServletRequest with ones which depend instead on ActionContext.
The main value of this, in my mind, is eliminating the need to
coordinate Attribute keys in requestScope and sessionScope in favor
of encapsulating that inside the ActionContext implementation. Of
course, it also helps eliminate dependencies on the Servlet API,
which should make testing easier and might also help people who are
interested in using Struts in Portlet, Web Services, or other
slightly different environments.
What would be the correct approach to Struts' own subclasses of
Action and ActionForm? I kind of assume we would need to not change
them for a while since people who may have subclassed them may be
depending on their implementations of the (proposedly) deprecated
signatures?
Is this even a good idea?
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: Change Action, ActionForm to use ActionContext?
Posted by Don Brown <mr...@twdata.org>.
I'm not in love with "Actionable" and just threw it out there to get it
started. I'd perfer not to use "Action" since it has a different
meaning already and we want a smooth transition which would entail
keeping Action around for some time. Unfortunately, I can't think of
anything else that fits in with our current naming scheme, yet clearly
designates something as an interface.
Don
Dakota Jack wrote:
> <snip>
> On Sun, 13 Feb 2005 14:05:11 -0800, Don Brown
>
>>I don't mind sticking ActionContext everywhere as it is better than
>>having the code rely directly on the servlet api, but since we are
>>talking about modifying Action, why not get rid of this "must extend
>>Action" stuff and make Action an interface? IMO, Struts core should
>>depend on this new interface, say Actionable, where Action would be an
>>implementation of this interface. Since the methods of Action like
>>saveMessages have been moved to ActionContext, we can safely get rid of
>>Action, a passing I won't soon be missing. :)
>>
>>Don
>
> </snip>
>
> I would definitely support all of this and look forward to all of it,
> except the name "Actionable". First, the interface is not a tag
> interface, is it? If the "able" is something you are really fond of,
> then I would suggest, in honor of Craig calling it "Doable". Second,
> and related, the pejorative nature of "Actionable" is unfortunate,
> don't you think?
>
> Main Entry: ac·tion·able
> Pronunciation: 'ak-sh(&-)n&-b&l
> Function: adjective
> : subject to or affording ground for an action or suit at law
> - ac·tion·ably /-blE/ adverb
>
> Could the interface be called "Action"? I imagine this has all been
> discussed before and will set off a firestorm of "Lordy Lordy"s. But,
> what the heck, one can keep trying to be helpful.
>
> Jack
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Dakota Jack <da...@gmail.com>.
<snip>
On Sun, 13 Feb 2005 14:05:11 -0800, Don Brown
> I don't mind sticking ActionContext everywhere as it is better than
> having the code rely directly on the servlet api, but since we are
> talking about modifying Action, why not get rid of this "must extend
> Action" stuff and make Action an interface? IMO, Struts core should
> depend on this new interface, say Actionable, where Action would be an
> implementation of this interface. Since the methods of Action like
> saveMessages have been moved to ActionContext, we can safely get rid of
> Action, a passing I won't soon be missing. :)
>
> Don
</snip>
I would definitely support all of this and look forward to all of it,
except the name "Actionable". First, the interface is not a tag
interface, is it? If the "able" is something you are really fond of,
then I would suggest, in honor of Craig calling it "Doable". Second,
and related, the pejorative nature of "Actionable" is unfortunate,
don't you think?
Main Entry: ac·tion·able
Pronunciation: 'ak-sh(&-)n&-b&l
Function: adjective
: subject to or affording ground for an action or suit at law
- ac·tion·ably /-blE/ adverb
Could the interface be called "Action"? I imagine this has all been
discussed before and will set off a firestorm of "Lordy Lordy"s. But,
what the heck, one can keep trying to be helpful.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
"Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
"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
Re: Change Action, ActionForm to use ActionContext?
Posted by Vic <vi...@friendvu.com>.
Don Brown wrote:
>
> a. A single class which combines the request logic and request
> "model", or as we call it, ActionForm.
I don't like that. Separate is simple to extend, and in my mind.
>
> b. Multiple action methods per class ala DispatchAction.
With onSaveExec(.. onDisplayListExec( ...
That sounds good.
.V
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Shey Rab Pawo <pa...@gmail.com>.
Thanks, you are right on SAIF, of course. The Filter commands, I
assume you would agree, are not really AOP either. Anyway, I was off
on that suggestion.
On Sun, 20 Feb 2005 10:39:03 -0800, Don Brown <mr...@twdata.org> wrote:
> Well, I suppose interceptors could be viewed as a simplified, specific
> implementation of AOP, but I would hardly equate the two. If I had to
> draw a venn diagram, I'd have AOP and commons-chain (CoR) as two big
> circles overlaping at a place called interceptors. With commons-chain,
> you could create a chain that has Filter commands with the last command
> being ExecuteAction. This way, you can have code to execute right
> before and right after the Action was executed, ala as an interceptor.
>
> Don
--
No one ever went blind looking at the bright side of life.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Don Brown <mr...@twdata.org>.
Well, I suppose interceptors could be viewed as a simplified, specific
implementation of AOP, but I would hardly equate the two. If I had to
draw a venn diagram, I'd have AOP and commons-chain (CoR) as two big
circles overlaping at a place called interceptors. With commons-chain,
you could create a chain that has Filter commands with the last command
being ExecuteAction. This way, you can have code to execute right
before and right after the Action was executed, ala as an interceptor.
Don
Shey Rab Pawo wrote:
> On Fri, 18 Feb 2005 21:02:44 -0500, Ted Husted <hu...@apache.org> wrote:
>
>>On Fri, 18 Feb 2005 09:04:32 -0800, Don Brown wrote:
>>
>>>There is a middle ground which I have been playing with on and off
>>>frequently called "interceptors". In WebWork2, you can define
>>>action interceptors that intercept certain actions, defined at a
>>>per-action level. With Struts Action Invocation Framework (SAIF)
>>>at struts.sf.net/saif , we ported interceptors to pre-chain Struts,
>>>but it would be interesting to integrate that work with Struts as
>>>it is now. It would be nice to define code that would be executed
>>>only before certain groups of actions.
>>
>>Why not add a Command to the request processing chain that acts as an interceptor.
>>
>>The Command looks for the group of Actions, does it's business when they come along, and ignores the rest.
>>
>>-Ted.
>>
>
>
> I may be mistaken on this, Don would be the expert of course on this,
> but I think that the idea of the interceptors on SAIF is to provide
> AOP support. Command/Chain would seem to work against the basic
> precepts of AOP, I think. I admint that I am not 100% confident of
> this statement.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Shey Rab Pawo <pa...@gmail.com>.
On Fri, 18 Feb 2005 21:02:44 -0500, Ted Husted <hu...@apache.org> wrote:
> On Fri, 18 Feb 2005 09:04:32 -0800, Don Brown wrote:
> > There is a middle ground which I have been playing with on and off
> > frequently called "interceptors". In WebWork2, you can define
> > action interceptors that intercept certain actions, defined at a
> > per-action level. With Struts Action Invocation Framework (SAIF)
> > at struts.sf.net/saif , we ported interceptors to pre-chain Struts,
> > but it would be interesting to integrate that work with Struts as
> > it is now. It would be nice to define code that would be executed
> > only before certain groups of actions.
>
> Why not add a Command to the request processing chain that acts as an interceptor.
>
> The Command looks for the group of Actions, does it's business when they come along, and ignores the rest.
>
> -Ted.
>
I may be mistaken on this, Don would be the expert of course on this,
but I think that the idea of the interceptors on SAIF is to provide
AOP support. Command/Chain would seem to work against the basic
precepts of AOP, I think. I admint that I am not 100% confident of
this statement.
--
No one ever went blind looking at the bright side of life.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Ted Husted <hu...@apache.org>.
On Fri, 18 Feb 2005 09:04:32 -0800, Don Brown wrote:
>�You are correct, but in my opinion, these user commands that are
>�placed in the Struts request processing chain should have relevance
>�to your entire application and therefore are appropriate in the
>�global level of the request processing chain. An action is about
>�how to process an individual request, so in my book, these are two
>�separate concerns that should be clearly separated.
+1
There should be a clear separation between
* the logic that is processing the request, and
* the the logic that is processing the transaction implied by the request.
Of course, some people are going to muddle the two no matter what we do, but we should try to encourage a design that separates concerns.
>�There is a middle ground which I have been playing with on and off
>�frequently called "interceptors". �In WebWork2, you can define
>�action interceptors that intercept certain actions, defined at a
>�per-action level. �With Struts Action Invocation Framework (SAIF)
>�at struts.sf.net/saif , we ported interceptors to pre-chain Struts,
>�but it would be interesting to integrate that work with Struts as
>�it is now. �It would be nice to define code that would be executed
>�only before certain groups of actions.
>
>�Don
>
>
>�On Wed, 16 Feb 2005 08:10:04 -0800, Shey Rab Pawo
>�<pa...@gmail.com>�wrote:
>>�On Sun, 13 Feb 2005 23:09:07 -0800, Don Brown <mr...@twdata.org>
>>�wrote:
>>
>>�See some thoughts and an implicit question within:
>>
>>>�You make some good points, so I'll add my 2c:
>>>�1. �The chain logic should be separate from the application
>>>�logic, which could, however, use common-chain. �I'm fine with
>>>�using a chain command to replace Action, as long as it can be
>>>�made clear the line between the two processes. �One defines how
>>>�all requests should be processed, and the other, how this
>>>�individual request should be handled.
>>>
>>
>>�My understanding may be faulty but my understanding of the
>>�original intent behind chains vis-a-vis actions was to extract
>>�the request processor, break it down, and make it a chain of
>>�commands, so that this would give the user the option of
>>�supplanting code in whatever detail was required, desired or
>>�needed in the process of realizing the preliminary steps in an
>>�action. �Essentially, then, the idea was to keep the action
>>�firmly ensconced in the role of a controller in the web MVC
>>�pattern but to allow the potential of allowing choices and
>>�improvements, or to make the early request processing (pre-model
>>�processing) pluggable. �Is this right? �If so, then I might have
>>�some suggestions, but, if not, then I probably do not understand
>>�what is happening and would appreciate a 35,000 foot explanation,
>>�if that seems appropriate at this point.
>>
>>�--
>>�The radiance of all the stars does not equal a sixteenth part of
>>�the moon's radiance, likewise, good deeds giving us merit, all
>>�these do not equal a sixteenth part of the merit of loving-
>>�kindness..
>>
>>�------------------------------------------------------------------
>>�--- 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Ted Husted <hu...@apache.org>.
On Fri, 18 Feb 2005 09:04:32 -0800, Don Brown wrote:
>�There is a middle ground which I have been playing with on and off
>�frequently called "interceptors". �In WebWork2, you can define
>�action interceptors that intercept certain actions, defined at a
>�per-action level. �With Struts Action Invocation Framework (SAIF)
>�at struts.sf.net/saif , we ported interceptors to pre-chain Struts,
>�but it would be interesting to integrate that work with Struts as
>�it is now. �It would be nice to define code that would be executed
>�only before certain groups of actions.
Why not add a Command to the request processing chain that acts as an interceptor.
The Command looks for the group of Actions, does it's business when they come along, and ignores the rest.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain Conditionals (was Change Action, ActionForm to use
ActionContext?)
Posted by Joe Germuska <Jo...@Germuska.com>.
><SNIP>
>> Anyway, from my personal experience, when one wants to apply control
>> logic that is common to various requests (as opposed to based in a
>> single Action), the chain based request processor has made that
>> simpler for me.
></SNIP>
>
>This is hard for me to follow. I am not sure what "control logic that
>is common to various request" would be, so I cannot see how the
>"composable request processor" (I like that way of talking about it)
>helps here.
Good, since that's its class name!
Here are the examples of custom commands I used in a project built
around the 1.2 version of struts-chain, sprinkled through the chain:
* set the request character encoding to UTF-8 (sure, I could have
used a filter for this, but I didn't!)
* see if there is a request parameter with a specific name to proxy
for a normal login process (only for testing use) and if found, put
that value in the context
* retrieve the user's ID from an HTTP Request Header set by 3rd party
auth. software and put it in the context (for normal production use)
* independent of where the user's ID came from (see two previous
commands), ensure that there is a "User" in the session and
initialize the session as appropriate
(insert standard struts form processing here)
* Alternative per-action authorization since role-based doesn't work
for this app
* set up an ActionContext object (similar to but different from what
is now in Struts)
(insert standard struts action processing here)
* do some standard post-processing with the ActionContext
* look up a bit of "page preparation" logic based on the tile used in
the ActionForward and, if found, execute the logic (used to pre-fill
forms from database and do other setup)
><SNIP>
>> As for reusable extensions to the request processing
>> cycle, I think we will find that building those is simpler too, once
>> people start absorbing this. Some of the earliest discussions
>> about needing a composable request processor came up in the context
>> of the struts-workflow project, which faced a challenge in wanting to
>> provide custom request processing and needing to figure out how to
>> work with users who may or may not have wanted to use Tiles, since
>> Tiles also required a subclass of RequestProcessor.
></SNIP>
>
>10-4! Is there going to be a mechanism for plugging extensions in at
>each stage in the final analysis? That would be ideal, to my mind.
Yes, I agree that this would be valuable. Ted made some suggestions
today about one way we might approach this. At first review, I was
ambivalent about the details, but I'll look at them again. As I
believe I've noted elsewhere, I like the model of Maven's "preGoal"
and "postGoal". As more people start actually using the code, i'm
sure we'll get even more suggestions about good ways to achieve this.
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: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Dakota Jack <da...@gmail.com>.
Thanks, Joe: see within:
<SNIP>
On Wed, 23 Feb 2005 08:25:07 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> I am talking about what happens before the action class is executed,
> including the possible decision not to execute the action because
> form validation was required and failed.
</SNIP>
Gotcha!
<SNIP>
> Actually, I just about never have discussions with other committers
> besides what's here on the dev list; however, perhaps we've been
> having these discussions together long enough that we gloss over some
> things.
</SNIP>
10-4! Makes sense!
<SNIP>
> Anyway, from my personal experience, when one wants to apply control
> logic that is common to various requests (as opposed to based in a
> single Action), the chain based request processor has made that
> simpler for me.
</SNIP>
This is hard for me to follow. I am not sure what "control logic that
is common to various request" would be, so I cannot see how the
"composable request processor" (I like that way of talking about it)
helps here.
<SNIP>
> As for reusable extensions to the request processing
> cycle, I think we will find that building those is simpler too, once
> people start absorbing this. Some of the earliest discussions
> about needing a composable request processor came up in the context
> of the struts-workflow project, which faced a challenge in wanting to
> provide custom request processing and needing to figure out how to
> work with users who may or may not have wanted to use Tiles, since
> Tiles also required a subclass of RequestProcessor.
</SNIP>
10-4! Is there going to be a mechanism for plugging extensions in at
each stage in the final analysis? That would be ideal, to my mind.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
RE: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Rajaneesh <ra...@slk-soft.com>.
Hi Joe,
Are we discussion about having a single controller and differen request
handler
for mapping the request in this context?
Sorry if my question was too dumb
Regards
Rajaneesh
-----Original Message-----
From: Joe Germuska [mailto:Joe@Germuska.com]
Sent: Wednesday, February 23, 2005 7:55 PM
To: Dakota Jack; Struts Developers List
Subject: Re: Chain Conditionals (was Change Action, ActionForm to use
ActionContext?)
At 9:32 PM -0800 2/22/05, Dakota Jack wrote:
>Thanks, Joe,
>
>See within:
>
><SNIP>
>> Jack, I'm not really following you. For me, I simply raised the
>> issue that there is a standard conditional case in processing a
>> request for Struts: if the form is valid, then do a few things; if it
>> is not, do a few other things (well, just one, "SelectInput") So I
>> guess this is talking about something which belongs in the "standard
>> plumbing chain."
>>
>> I don't see a clear way to apply the Strategy pattern to this
>> specific question, but maybe I'm just missing something.
>>
>> Joe
></SNIP>
...
>Are you talking about what happens prior to reaching the Action class
>or what happens before? I assume you are talking about what happens
>before, but perhaps I am mistaken?
I am talking about what happens before the action class is executed,
including the possible decision not to execute the action because
form validation was required and failed.
>I am trying to be helpful here, as I had great hopes that some sort of
>chain option for the request processor would make building plugins and
>making life simpler. As things are, if this is about the plumbing,
>things seem to be potentially more rather than less coupled. Sorry if
>this is not helpful, but you all obviously talk with each other often
>enough to leave a bit out of the conversation which I cannot get the
>uptake on.
Actually, I just about never have discussions with other committers
besides what's here on the dev list; however, perhaps we've been
having these discussions together long enough that we gloss over some
things.
Anyway, from my personal experience, when one wants to apply control
logic that is common to various requests (as opposed to based in a
single Action), the chain based request processor has made that
simpler for me. As for reusable extensions to the request processing
cycle, I think we will find that building those is simpler too, once
people start absorbing this. Some of the earliest discussions
about needing a composable request processor came up in the context
of the struts-workflow project, which faced a challenge in wanting to
provide custom request processing and needing to figure out how to
work with users who may or may not have wanted to use Tiles, since
Tiles also required a subclass of RequestProcessor.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain Conditionals (was Change Action, ActionForm to use
ActionContext?)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:32 PM -0800 2/22/05, Dakota Jack wrote:
>Thanks, Joe,
>
>See within:
>
><SNIP>
>> Jack, I'm not really following you. For me, I simply raised the
>> issue that there is a standard conditional case in processing a
>> request for Struts: if the form is valid, then do a few things; if it
>> is not, do a few other things (well, just one, "SelectInput") So I
>> guess this is talking about something which belongs in the "standard
>> plumbing chain."
>>
>> I don't see a clear way to apply the Strategy pattern to this
>> specific question, but maybe I'm just missing something.
>>
>> Joe
></SNIP>
...
>Are you talking about what happens prior to reaching the Action class
>or what happens before? I assume you are talking about what happens
>before, but perhaps I am mistaken?
I am talking about what happens before the action class is executed,
including the possible decision not to execute the action because
form validation was required and failed.
>I am trying to be helpful here, as I had great hopes that some sort of
>chain option for the request processor would make building plugins and
>making life simpler. As things are, if this is about the plumbing,
>things seem to be potentially more rather than less coupled. Sorry if
>this is not helpful, but you all obviously talk with each other often
>enough to leave a bit out of the conversation which I cannot get the
>uptake on.
Actually, I just about never have discussions with other committers
besides what's here on the dev list; however, perhaps we've been
having these discussions together long enough that we gloss over some
things.
Anyway, from my personal experience, when one wants to apply control
logic that is common to various requests (as opposed to based in a
single Action), the chain based request processor has made that
simpler for me. As for reusable extensions to the request processing
cycle, I think we will find that building those is simpler too, once
people start absorbing this. Some of the earliest discussions
about needing a composable request processor came up in the context
of the struts-workflow project, which faced a challenge in wanting to
provide custom request processing and needing to figure out how to
work with users who may or may not have wanted to use Tiles, since
Tiles also required a subclass of RequestProcessor.
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: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Dakota Jack <da...@gmail.com>.
Thanks, Joe,
See within:
<SNIP>
> Jack, I'm not really following you. For me, I simply raised the
> issue that there is a standard conditional case in processing a
> request for Struts: if the form is valid, then do a few things; if it
> is not, do a few other things (well, just one, "SelectInput") So I
> guess this is talking about something which belongs in the "standard
> plumbing chain."
>
> I don't see a clear way to apply the Strategy pattern to this
> specific question, but maybe I'm just missing something.
>
> Joe
</SNIP>
I cannot tell what part of the process you guys are discussing half
the time. Pretty much everything on the server side is "processing
the request", if that includes "building the response". By the
"standard plumbing" I mean the processes that normally happen prior to
the processing of a request reaching the Action class, or the stuff
that is taken care of by the framework.
Are you talking about what happens prior to reaching the Action class
or what happens before? I assume you are talking about what happens
before, but perhaps I am mistaken?
I am trying to be helpful here, as I had great hopes that some sort of
chain option for the request processor would make building plugins and
making life simpler. As things are, if this is about the plumbing,
things seem to be potentially more rather than less coupled. Sorry if
this is not helpful, but you all obviously talk with each other often
enough to leave a bit out of the conversation which I cannot get the
uptake on.
Jack
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Dakota Jack <da...@gmail.com>.
Whenever there are conditional choices between classes, as with those
implementing Comparator, shouldn't we favor polymophism as an OOP
solution rather than some procedural solution?
Last word unless requested otherwise on this: just trying to be
helpful. The five options below are all procedural except the first
one. Why use procedural logic in an OOP setting?
On Sun, 20 Feb 2005 10:26:14 -0800, Don Brown <mr...@twdata.org> wrote:
> Ah, we finally stumble onto the very slipperly slope that is conditional
> support for commons-chain. As we put more and more code into chain, we
> will inevitably have commands that only need to execute under certain
> conditions. There are three possibilities:
<SNIP CHOICE='1 OOP-POLYMORPHISM'>
Use polymorphism and the basic benefits of OOP with a Strategy pattern
</SNIP>
<SNIP CHOICE='2 PROCEDURAL-LOGIC IN COMMAND'>
<snip choice='procedural-logic-inside-command'>
1. Bury conditional logic inside the command itself. This is the
> approach many of the current chains take, but has the disadvantage of
> the flow being very unclear to the reader of the config file, requiring
> digging into the source code.
</SNIP>
<SNIP CHOICE='3 PROCEDURAL-LOGIC IN NEW COMMANDS>
> 2. Create an "if" command, which then would logically lead to a
> "switch" command and perhaps a "for" command. These commands would
> check certain conditions then execute configured commands based on the
> outcome.
</SNIP>
<SNIP CHOICE='4 PROCEDURAL-LOGIC IN XML'>
<snip choice='procedural-logic-in-xml'>
3. Modify the XML so that the branching code is described as XML
> elements. While this option produces the clearest code, it also brings
> all the problems of something like Jelly with it.
</SNIP>
<SNIP CHOICE='5 PROCEDURAL-LOGIC IN GUI>
I wonder what a merging of commons-chain and a scripting language like
> beanshell would look like...
</SNIP>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Dakota Jack <da...@gmail.com>.
The point of the following, of course, in case someone has not looked
at the code is:
commands\AbstractAuthorizeAction.java(37): public abstract class
AbstractAuthorizeAction implements Command {
commands\AbstractCreateAction.java(37): public abstract class
AbstractCreateAction implements Command {
commands\AbstractCreateActionForm.java(39): public abstract class
AbstractCreateActionForm implements Command {
commands\AbstractExceptionHandler.java(39): public abstract class
AbstractExceptionHandler implements Command {
commands\AbstractExecuteAction.java(37): public abstract class
AbstractExecuteAction implements Command {
commands\AbstractPerformForward.java(34): public abstract class
AbstractPerformForward implements Command {
commands\AbstractPerformInclude.java(34): public abstract class
AbstractPerformInclude implements Command {
commands\AbstractPopulateActionForm.java(37): public abstract class
AbstractPopulateActionForm implements Command {
commands\AbstractRequestNoCache.java(34): public abstract class
AbstractRequestNoCache implements Command {
commands\AbstractSelectAction.java(35): public abstract class
AbstractSelectAction implements Command {
commands\AbstractSelectForward.java(38): public abstract class
AbstractSelectForward implements Command {
commands\AbstractSelectInput.java(38): public abstract class
AbstractSelectInput implements Command {
commands\AbstractSelectLocale.java(37): public abstract class
AbstractSelectLocale implements Command {
commands\AbstractSelectModule.java(38): public abstract class
AbstractSelectModule implements Command {
commands\AbstractSetContentType.java(34): public abstract class
AbstractSetContentType implements Command {
commands\AbstractValidateActionForm.java(39): public abstract class
AbstractValidateActionForm implements Command {
contexts\ActionContextBase.java(48): public abstract class
ActionContextBase extends ContextWrapper implements ActionContext {
Jack
On Sun, 20 Feb 2005 13:37:33 -0800, Dakota Jack <da...@gmail.com> wrote:
> I find this discussion a bit confusing. Is this about the supplanting
> of implementation code of RequestProcessor with a chain? Is this
> about adding condition support in commons-chain to commons-chain or to
> Struts? I will assume the latter. Accordingly, I will assume that
> "chain" means "struts-chain".
>
> If I understand things correctly, there are other alternatives than
> Don suggests. My thing, of course, is that the "other alternatives"
> are preferrable. I would suggest, at a minimum, that there be a
> standard plumbing chain. If someone wants to change that and to use
> XML, I would strongly suggest that that plumbing XML be kept strictly
> separate from the application struts-config.xml file.
>
> Actually, I would prefer that the conditional options be in the
> implementation of an IoC RequestProcessor interface. I would also, of
> course, prefer that the Strategy Pattern:
>
> public class InterfaceDefaultImplementation implements Interface {
> private Helper helper;
>
> public void setHelper(Helper helper) {
> this.helper = helper;
> }
>
> public void doSomething() {
> //... do something
> int value = helper.doIt(args);
> //... do more
> }
> }
>
> be preferred over the Template Method Pattern:
>
> public abstract class AbstractInferface implements Interface {
> public void doSomething() {
> //... do something
> int value = doIt(args);
> //... do more
> }
>
> protected abstract int doIt(params);
>
> public class InterfaceDefaultImplementation extends AbstractInterface {
> protected int doIt(params) {
> //....
> }
> }
> }
>
> The advantages are:
>
> -- ONE: we can change the strategy at runtime do to the flexibility of
> composition over inheritance.
>
> -- TWO: the implementations are not linked and we can pick and mix
> different strategy implemenations in any combination.
>
> -- THREE: we can use the same strategy interface in multiple classes
> allowing for the sort of flexibility that you get from commands in
> chains.
>
> -- FOUR: we can test using mock objects.
>
> (This is all well-known, of course, and not original. I hope I am not
> out of bounds reminding anyone of these benefits.) I probably won't
> have much to say on this after this, since it does not seem to appeal
> to anyone in particular.
>
> <snip no='A'>
> On Sun, 20 Feb 2005 10:26:14 -0800, Don Brown <mr...@twdata.org> wrote:
> > Ah, we finally stumble onto the very slipperly slope that is conditional
> > support for commons-chain. As we put more and more code into chain, we
> > will inevitably have commands that only need to execute under certain
> > conditions. There are three possibilities:
> </snip>
>
> Great that this discussion comes at this point. Measure twice: cut once!
>
> <snip no='A1-'>
> > 1. Bury conditional logic inside the command itself. This is the
> > approach many of the current chains take, but has the disadvantage of
> > the flow being very unclear to the reader of the config file, requiring
> > digging into the source code.
> </snip>
>
> Since this is Struts plumbing, is this really a disadvantage? And,
> isn't this part of the plumbing merely implementation? Should this
> code dictate architecture.
>
> <snip no='A-2'>
> > 2. Create an "if" command, which then would logically lead to a
> > "switch" command and perhaps a "for" command. These commands would
> > check certain conditions then execute configured commands based on the
> > outcome.
> </snip>
>
> <snip no='A-3'>
> > 3. Modify the XML so that the branching code is described as XML
> > elements. While this option produces the clearest code, it also brings
> > all the problems of something like Jelly with it.
> </snip>
>
> For my part, using XML for implementation is baroque.
>
>
> > So far, chain has resisted conditional support for the very reason it
> > opens up a huge can of worms. However, as soon as you start putting
> > complex logic in commons-chain, you are going to run up against the
> > problem again and again, and I think solution 1 will really start to be
> > inadequate. Solution 2 feels like a hack, and solution 3 (executable
> > XML) has been shown a bad idea through Jelly.
> >
> > I wonder what a merging of commons-chain and a scripting language like
> > beanshell would look like...
> >
> > Don
> >
> > Joe Germuska wrote:
> > > At 10:00 AM -0800 2/18/05, Don Brown wrote:
> > >
> > >> I think the WebWork2/XWork implementation of interceptors is pretty
> > >> spot on. You define interceptors and interceptor stacks at the top of
> > >> your configuration file. Then, in the action mapping, we'd add an
> > >> attribute called say "interceptor" which would be the name of an
> > >> interceptor stack or interceptor. We could use "pre" and "post", but
> > >> post is really just an interceptor that only contains code on the
> > >> response.
> > >>
> > >> However, since we already have this commons-chain framework, perhaps
> > >> all we need is the "interceptor" attribute that would point to a chain
> > >> command. Chain supports the notions of Filters and is more robust in
> > >> that interceptor stacks or chains could have child chains, etc.
> > >
> > >
> > > This may be a reason for pushing in a direction I'd been mulling but
> > > hadn't implemented: break up "process-action" into parts. I don't like
> > > that everything after ValidateActionForm needs to have a hard-coded
> > > "check if form was valid" test; that shouldn't be built into the
> > > command, but rather should be part of the chain design. So maybe from a
> > > big picture,
> > >
> > > In short form, here's what it is now:
> > >
> > > servlet-standard (chain command):
> > > command: ExceptionCatcher
> > > lookup: process-action
> > > lookup: process-view
> > >
> > > into something like this:
> > > servlet-standard (chain command):
> > > command: ExceptionCatcher
> > > lookup: preprocess-action
> > > lookup: process-form
> > > conditional lookup: process-invalid-form
> > > conditional lookup: process-valid-form
> > > lookup: process-view
> > >
> > > where the current process-action would break down like this:
> > >
> > > "preprocess-action"
> > > lookup: servlet-standard-preprocess
> > > command: SelectLocale
> > > command: RequestNoCache
> > > command: SetContentType
> > > command: SelectAction
> > > command: AuthorizeAction
> > >
> > > "process-form"
> > > command: CreateActionForm
> > > command: PopulateActionForm
> > > command: ValidateActionForm
> > >
> > > "process-invalid-form"
> > > command: SelectInput
> > >
> > > "process-valid-form"
> > > command: ExecuteCommand
> > > command: SelectForward
> > > command: SelectInclude
> > > command: PerformInclude
> > > command: CreateAction
> > > command: ExecuteAction
> > >
> > > In that case, the "process-valid-form" could be wrapped in the
> > > interceptor (or do you also want to intercept the form part?)
> > >
> > > It seems like it would be pretty easy to write a variant of the Chain
> > > class which, when given an interceptor map, could use the name of each
> > > command it found to look for a registered interceptor, and use it to
> > > wrap the command. Except for your concern about avoiding putting things
> > > in the context, this seems like it might be a good candidate for
> > > inclusion in the core commons-chain library. Perhaps a base
> > > implementation could go there, and it could be elaborated for dependency
> > > injection.
> > >
> > > All of this sounds like a good candidate for Struts.SF.net for the
> > > foreseeable future...
> > >
> > > Joe
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> --
> "You can lead a horse to water but you cannot make it float on its back."
> "Heaven has changed. The Sky now goes all the way to our feet.
>
> ~Dakota Jack~
>
> "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."
>
--
"You can lead a horse to water but you cannot make it float on its back."
"Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
"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
Re: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Don Brown <mr...@twdata.org>.
Ted Husted wrote:
> On Tue, 22 Feb 2005 16:42:06 -0800, Don Brown wrote:
>
>> I think an expression language might be a nice fit. I have to
>> admit I'm a bit dissolusioned with Chain as it doesn't seem to
>> model moderately complex processes well. In theory, each Command
>> will be independent and dropped in at will, but in reality, it will
>> require certain objects in the context and do different things if
>> placed in a different order, but now its dependencies are hidden in
>> its code making it difficult to determine behavior looking at its
>> configuration.
>>
>> I'd like to see what our current chain would look like using an
>> expression language like JEXL.
>>
>> Don
>
>
> Me too, but, as mentioned elsewhere, I'd be in favor of stabilizing what we already got and getting a distribution ready to ship.
>
> If we can get this out into the user community, perhaps some fresh eyes will have some fresh ideas.
+1 Agreed.
Don
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> 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
Re: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Ted Husted <hu...@apache.org>.
On Tue, 22 Feb 2005 16:42:06 -0800, Don Brown wrote:
> I think an expression language might be a nice fit. I have to
> admit I'm a bit dissolusioned with Chain as it doesn't seem to
> model moderately complex processes well. In theory, each Command
> will be independent and dropped in at will, but in reality, it will
> require certain objects in the context and do different things if
> placed in a different order, but now its dependencies are hidden in
> its code making it difficult to determine behavior looking at its
> configuration.
>
> I'd like to see what our current chain would look like using an
> expression language like JEXL.
>
> Don
Me too, but, as mentioned elsewhere, I'd be in favor of stabilizing what we already got and getting a distribution ready to ship.
If we can get this out into the user community, perhaps some fresh eyes will have some fresh ideas.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain Conditionals (was Change Action, ActionForm to use
ActionContext?)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 4:42 PM -0800 2/22/05, Don Brown wrote:
>I think an expression language might be a nice fit. I have to admit
>I'm a bit dissolusioned with Chain as it doesn't seem to model
>moderately complex processes well. In theory, each Command will be
>independent and dropped in at will, but in reality, it will require
>certain objects in the context and do different things if placed in
>a different order, but now its dependencies are hidden in its code
>making it difficult to determine behavior looking at its
>configuration.
>
>I'd like to see what our current chain would look like using an
>expression language like JEXL.
well, most of our current chain isn't very conditional, but here's
how one thing (which isn't "current" yet, but which I'm fooling
around with) might work.
======= Using a custom subclass of LookupCommand ==========
<!-- Deal with invalid form. -->
<lookupIf
catalogName="struts"
name="process-invalid-form"
contextKey="formValid"
condition="false"
optional="true"/>
<!-- Normal operation (when form is valid). -->
<lookupIf
catalogName="struts"
name="process-action"
contextKey="formValid"
condition="true"
ifNull="true"
optional="true"/>
======= Using JEXL in a hypothetical "ConditionalExpressionCommand" ==========
<!-- Deal with invalid form. -->
<lookupIf
catalogName="struts"
name="process-invalid-form"
condition="${ not empty context.formValid and not context.formValid }"
optional="true"/>
<!-- Normal operation (when form is valid). -->
<lookupIf
catalogName="struts"
name="process-action"
condition="${ empty context.formValid or context.formValid }"
optional="true"/>
The other general way that I see expressions being handy would be to
do runtime lookups. Going back to my longtime itch around "page
preparation," I've thought perhaps about having a lookup command
which took its value from the context:
<lookup
catalogName="pagePrep"
name="${context.forwardConfig.path}"
optional="true" />
If instead we decided to support command/catalog properties on the
ForwardConfig object, this would be less relevant, although it might
allow you to avoid a bit of tedious configuration.
I don't think JEXL does regular expressions; anything much more
interesting than the above would probably require that -- like having
certain commands preprocess based on path prefixes... or (look out,
vessels may pop) Script commands.
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: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Don Brown <mr...@twdata.org>.
I think an expression language might be a nice fit. I have to admit I'm
a bit dissolusioned with Chain as it doesn't seem to model moderately
complex processes well. In theory, each Command will be independent and
dropped in at will, but in reality, it will require certain objects in
the context and do different things if placed in a different order, but
now its dependencies are hidden in its code making it difficult to
determine behavior looking at its configuration.
I'd like to see what our current chain would look like using an
expression language like JEXL.
Don
Joe Germuska wrote:
> At 10:26 AM -0800 2/20/05, Don Brown wrote:
>
>> Ah, we finally stumble onto the very slipperly slope that is
>> conditional support for commons-chain. As we put more and more code
>> into chain, we will inevitably have commands that only need to execute
>> under certain conditions. There are three possibilities:
>>
>> 1. Bury conditional logic inside the command itself. This is the
>> approach many of the current chains take, but has the disadvantage of
>> the flow being very unclear to the reader of the config file,
>> requiring digging into the source code.
>> 2. Create an "if" command, which then would logically lead to a
>> "switch" command and perhaps a "for" command. These commands would
>> check certain conditions then execute configured commands based on the
>> outcome.
>> 3. Modify the XML so that the branching code is described as XML
>> elements. While this option produces the clearest code, it also
>> brings all the problems of something like Jelly with it.
>>
>> So far, chain has resisted conditional support for the very reason it
>> opens up a huge can of worms. However, as soon as you start putting
>> complex logic in commons-chain, you are going to run up against the
>> problem again and again, and I think solution 1 will really start to
>> be inadequate. Solution 2 feels like a hack, and solution 3
>> (executable XML) has been shown a bad idea through Jelly.
>>
>> I wonder what a merging of commons-chain and a scripting language like
>> beanshell would look like...
>
>
> Well, I've mentioned a couple of times about using JEXL for expression
> evaluation; it's a small step down that path, but also one with natural
> boundaries which might prevent one from trying to do *too much* in the
> config, rather than in the commands themselves.
>
> In any case, I think (1) is not only inadequate, but wrong. I can see
> one command having some condition built into it, but I think once we
> have three commands which all have the same test ("if form is valid")
> then that's a sign that the logic is in the wrong place.
>
> (2) may be a bit of a hack, but it avoids the slippery slope of (3).
> I've written a simple ConditionalLookupTag to address the specific case
> at hand. I think it would be more elegant using an expression language,
> but I still don't feel ready to push my "gee, JEXL is cool" bug into a
> dependency for either Struts or commons-chain just yet. I still haven't
> decided yet even whether or not to commit this for Struts. I wanted to
> simply have a single "abort chain if form invalid" command, but then I
> realized that returning true from a subchain aborts the entire
> chain-of-chains, at least using the base LookupCommand.
>
>
> At 1:37 PM -0800 2/20/05, Dakota Jack wrote:
>
>> I find this discussion a bit confusing. Is this about the supplanting
>> of implementation code of RequestProcessor with a chain? Is this
>> about adding condition support in commons-chain to commons-chain or to
>> Struts? I will assume the latter. Accordingly, I will assume that
>> "chain" means "struts-chain".
>>
>> If I understand things correctly, there are other alternatives than
>> Don suggests. My thing, of course, is that the "other alternatives"
>> are preferrable. I would suggest, at a minimum, that there be a
>> standard plumbing chain. If someone wants to change that and to use
>> XML, I would strongly suggest that that plumbing XML be kept strictly
>> separate from the application struts-config.xml file.
>
>
> Jack, I'm not really following you. For me, I simply raised the issue
> that there is a standard conditional case in processing a request for
> Struts: if the form is valid, then do a few things; if it is not, do a
> few other things (well, just one, "SelectInput") So I guess this is
> talking about something which belongs in the "standard plumbing chain."
>
> I don't see a clear way to apply the Strategy pattern to this specific
> question, but maybe I'm just missing something.
>
> Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Chain Conditionals (was Change Action, ActionForm to use
ActionContext?)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:26 AM -0800 2/20/05, Don Brown wrote:
>Ah, we finally stumble onto the very slipperly slope that is
>conditional support for commons-chain. As we put more and more code
>into chain, we will inevitably have commands that only need to
>execute under certain conditions. There are three possibilities:
>
> 1. Bury conditional logic inside the command itself. This is the
>approach many of the current chains take, but has the disadvantage
>of the flow being very unclear to the reader of the config file,
>requiring digging into the source code.
> 2. Create an "if" command, which then would logically lead to a
>"switch" command and perhaps a "for" command. These commands would
>check certain conditions then execute configured commands based on
>the outcome.
> 3. Modify the XML so that the branching code is described as XML
>elements. While this option produces the clearest code, it also
>brings all the problems of something like Jelly with it.
>
>So far, chain has resisted conditional support for the very reason
>it opens up a huge can of worms. However, as soon as you start
>putting complex logic in commons-chain, you are going to run up
>against the problem again and again, and I think solution 1 will
>really start to be inadequate. Solution 2 feels like a hack, and
>solution 3 (executable XML) has been shown a bad idea through Jelly.
>
>I wonder what a merging of commons-chain and a scripting language
>like beanshell would look like...
Well, I've mentioned a couple of times about using JEXL for
expression evaluation; it's a small step down that path, but also one
with natural boundaries which might prevent one from trying to do
*too much* in the config, rather than in the commands themselves.
In any case, I think (1) is not only inadequate, but wrong. I can
see one command having some condition built into it, but I think once
we have three commands which all have the same test ("if form is
valid") then that's a sign that the logic is in the wrong place.
(2) may be a bit of a hack, but it avoids the slippery slope of (3).
I've written a simple ConditionalLookupTag to address the specific
case at hand. I think it would be more elegant using an expression
language, but I still don't feel ready to push my "gee, JEXL is cool"
bug into a dependency for either Struts or commons-chain just yet. I
still haven't decided yet even whether or not to commit this for
Struts. I wanted to simply have a single "abort chain if form
invalid" command, but then I realized that returning true from a
subchain aborts the entire chain-of-chains, at least using the base
LookupCommand.
At 1:37 PM -0800 2/20/05, Dakota Jack wrote:
>I find this discussion a bit confusing. Is this about the supplanting
>of implementation code of RequestProcessor with a chain? Is this
>about adding condition support in commons-chain to commons-chain or to
>Struts? I will assume the latter. Accordingly, I will assume that
>"chain" means "struts-chain".
>
>If I understand things correctly, there are other alternatives than
>Don suggests. My thing, of course, is that the "other alternatives"
>are preferrable. I would suggest, at a minimum, that there be a
>standard plumbing chain. If someone wants to change that and to use
>XML, I would strongly suggest that that plumbing XML be kept strictly
>separate from the application struts-config.xml file.
Jack, I'm not really following you. For me, I simply raised the
issue that there is a standard conditional case in processing a
request for Struts: if the form is valid, then do a few things; if it
is not, do a few other things (well, just one, "SelectInput") So I
guess this is talking about something which belongs in the "standard
plumbing chain."
I don't see a clear way to apply the Strategy pattern to this
specific question, but maybe I'm just missing something.
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: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Dakota Jack <da...@gmail.com>.
I find this discussion a bit confusing. Is this about the supplanting
of implementation code of RequestProcessor with a chain? Is this
about adding condition support in commons-chain to commons-chain or to
Struts? I will assume the latter. Accordingly, I will assume that
"chain" means "struts-chain".
If I understand things correctly, there are other alternatives than
Don suggests. My thing, of course, is that the "other alternatives"
are preferrable. I would suggest, at a minimum, that there be a
standard plumbing chain. If someone wants to change that and to use
XML, I would strongly suggest that that plumbing XML be kept strictly
separate from the application struts-config.xml file.
Actually, I would prefer that the conditional options be in the
implementation of an IoC RequestProcessor interface. I would also, of
course, prefer that the Strategy Pattern:
public class InterfaceDefaultImplementation implements Interface {
private Helper helper;
public void setHelper(Helper helper) {
this.helper = helper;
}
public void doSomething() {
//... do something
int value = helper.doIt(args);
//... do more
}
}
be preferred over the Template Method Pattern:
public abstract class AbstractInferface implements Interface {
public void doSomething() {
//... do something
int value = doIt(args);
//... do more
}
protected abstract int doIt(params);
public class InterfaceDefaultImplementation extends AbstractInterface {
protected int doIt(params) {
//....
}
}
}
The advantages are:
-- ONE: we can change the strategy at runtime do to the flexibility of
composition over inheritance.
-- TWO: the implementations are not linked and we can pick and mix
different strategy implemenations in any combination.
-- THREE: we can use the same strategy interface in multiple classes
allowing for the sort of flexibility that you get from commands in
chains.
-- FOUR: we can test using mock objects.
(This is all well-known, of course, and not original. I hope I am not
out of bounds reminding anyone of these benefits.) I probably won't
have much to say on this after this, since it does not seem to appeal
to anyone in particular.
<snip no='A'>
On Sun, 20 Feb 2005 10:26:14 -0800, Don Brown <mr...@twdata.org> wrote:
> Ah, we finally stumble onto the very slipperly slope that is conditional
> support for commons-chain. As we put more and more code into chain, we
> will inevitably have commands that only need to execute under certain
> conditions. There are three possibilities:
</snip>
Great that this discussion comes at this point. Measure twice: cut once!
<snip no='A1-'>
> 1. Bury conditional logic inside the command itself. This is the
> approach many of the current chains take, but has the disadvantage of
> the flow being very unclear to the reader of the config file, requiring
> digging into the source code.
</snip>
Since this is Struts plumbing, is this really a disadvantage? And,
isn't this part of the plumbing merely implementation? Should this
code dictate architecture.
<snip no='A-2'>
> 2. Create an "if" command, which then would logically lead to a
> "switch" command and perhaps a "for" command. These commands would
> check certain conditions then execute configured commands based on the
> outcome.
</snip>
<snip no='A-3'>
> 3. Modify the XML so that the branching code is described as XML
> elements. While this option produces the clearest code, it also brings
> all the problems of something like Jelly with it.
</snip>
For my part, using XML for implementation is baroque.
> So far, chain has resisted conditional support for the very reason it
> opens up a huge can of worms. However, as soon as you start putting
> complex logic in commons-chain, you are going to run up against the
> problem again and again, and I think solution 1 will really start to be
> inadequate. Solution 2 feels like a hack, and solution 3 (executable
> XML) has been shown a bad idea through Jelly.
>
> I wonder what a merging of commons-chain and a scripting language like
> beanshell would look like...
>
> Don
>
> Joe Germuska wrote:
> > At 10:00 AM -0800 2/18/05, Don Brown wrote:
> >
> >> I think the WebWork2/XWork implementation of interceptors is pretty
> >> spot on. You define interceptors and interceptor stacks at the top of
> >> your configuration file. Then, in the action mapping, we'd add an
> >> attribute called say "interceptor" which would be the name of an
> >> interceptor stack or interceptor. We could use "pre" and "post", but
> >> post is really just an interceptor that only contains code on the
> >> response.
> >>
> >> However, since we already have this commons-chain framework, perhaps
> >> all we need is the "interceptor" attribute that would point to a chain
> >> command. Chain supports the notions of Filters and is more robust in
> >> that interceptor stacks or chains could have child chains, etc.
> >
> >
> > This may be a reason for pushing in a direction I'd been mulling but
> > hadn't implemented: break up "process-action" into parts. I don't like
> > that everything after ValidateActionForm needs to have a hard-coded
> > "check if form was valid" test; that shouldn't be built into the
> > command, but rather should be part of the chain design. So maybe from a
> > big picture,
> >
> > In short form, here's what it is now:
> >
> > servlet-standard (chain command):
> > command: ExceptionCatcher
> > lookup: process-action
> > lookup: process-view
> >
> > into something like this:
> > servlet-standard (chain command):
> > command: ExceptionCatcher
> > lookup: preprocess-action
> > lookup: process-form
> > conditional lookup: process-invalid-form
> > conditional lookup: process-valid-form
> > lookup: process-view
> >
> > where the current process-action would break down like this:
> >
> > "preprocess-action"
> > lookup: servlet-standard-preprocess
> > command: SelectLocale
> > command: RequestNoCache
> > command: SetContentType
> > command: SelectAction
> > command: AuthorizeAction
> >
> > "process-form"
> > command: CreateActionForm
> > command: PopulateActionForm
> > command: ValidateActionForm
> >
> > "process-invalid-form"
> > command: SelectInput
> >
> > "process-valid-form"
> > command: ExecuteCommand
> > command: SelectForward
> > command: SelectInclude
> > command: PerformInclude
> > command: CreateAction
> > command: ExecuteAction
> >
> > In that case, the "process-valid-form" could be wrapped in the
> > interceptor (or do you also want to intercept the form part?)
> >
> > It seems like it would be pretty easy to write a variant of the Chain
> > class which, when given an interceptor map, could use the name of each
> > command it found to look for a registered interceptor, and use it to
> > wrap the command. Except for your concern about avoiding putting things
> > in the context, this seems like it might be a good candidate for
> > inclusion in the core commons-chain library. Perhaps a base
> > implementation could go there, and it could be elaborated for dependency
> > injection.
> >
> > All of this sounds like a good candidate for Struts.SF.net for the
> > foreseeable future...
> >
> > Joe
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
"You can lead a horse to water but you cannot make it float on its back."
"Heaven has changed. The Sky now goes all the way to our feet.
~Dakota Jack~
"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
Re: Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Ted Husted <hu...@apache.org>.
On Sun, 20 Feb 2005 10:26:14 -0800, Don Brown wrote:
> Ah, we finally stumble onto the very slipperly slope that is
> conditional support for commons-chain. As we put more and more
> code into chain, we will inevitably have commands that only need to
> execute under certain conditions. There are three possibilities:
>
> 1. Bury conditional logic inside the command itself. This is the
> approach many of the current chains take, but has the disadvantage
> of the flow being very unclear to the reader of the config file,
> requiring digging into the source code.
> 2. Create an "if" command, which then would logically lead to a
> "switch" command and perhaps a "for" command. These commands would
> check certain conditions then execute configured commands based on
> the outcome.
> 3. Modify the XML so that the branching code is described as XML
> elements. While this option produces the clearest code, it also
> brings all the problems of something like Jelly with it.
>
> So far, chain has resisted conditional support for the very reason
> it opens up a huge can of worms. However, as soon as you start
> putting complex logic in commons-chain, you are going to run up
> against the problem again and again, and I think solution 1 will
> really start to be inadequate. Solution 2 feels like a hack, and
> solution 3 (executable XML) has been shown a bad idea through Jelly.
>
> I wonder what a merging of commons-chain and a scripting language
> like beanshell would look like...
>
> Don
(4) Make Chains extensible so that the caller can select the appropriate branch
I wouldn't suggest getting into this for 1.3.0, but one way to move some of the conditional logic out of a chain might be to make the Chains more extensible, so that one size does not have to fit all.
For example, not every Struts application uses modules. But, there is a lot of special case logic in the Commands to support modules. It would be handy if we could start with a basic Chain that did not support modules, and then specify new Commands to add module support.
The key idea would be to give Commands in a Chain identifiers. So, instead of
<!-- Identify the ActionConfig for this request -->
<command className="org.apache.struts.chain.commands.servlet.SelectAction"/>
We'd have
<!-- Identify the ActionConfig for this request -->
<command NAME="SelectAction"
className="org.apache.struts.chain.commands.servlet.SelectAction"/>
We could then do something like
<chain name="process-action-with-modules" EXTENDS="process-action">
<command
name="SelectAction"
className="org.apache.struts.chain.commands.servlet.MODULES.SelectAction"/>
</chain>
to create a new Chain that replaces one Command with another and just copying the rest.
Of course, there would be other commands to replace, but the idea would be that only the modular applications would need to load the modular code.
Likewise, there could be distinct process-action chains for actions with validation and without validation.
<chain name="process-action-with-validation" extends="process-action">
<command name="ValidateActionForm" AFTER="PopulateActionForm" classname ="..." />
</chain>
In this case, the "ValidateActionForm" Command would be inserted into the Chain after the "ProcessActionForm" Command.
Of course, the conditional logic still occurs (TNSTAFL), but it moves out of the commands and into the controller/caller. The controller (aka request processor) decides whether to call "process-action" or "process-action-with-validate".
The difference being that the validation commands no longer need to check the state for themselves. Having been made part of the Chain, they can just go about their business.
Using a factory, the "decision" can be made in a OOP way, if we like, if the request-processing chain is made an attribute of the mapping. When the mapping is created, the constructor could assign the appropriate request processing chain. At runtime, the controller would just call whatever chain is linked to a given mapping.
This could lead to mappings specifying custom request-processing chains. If some mappings needed an extra processing step, the mapping could specify an alternate request processing chain to be called instead of the default set. Changes to the default processing chain could be specified as part of the mapping, rather than in the catalog. The request-processor catalog could be made part of the struts-config at some point, so that we'd have a one-stop shop again.
Of course, such ideas would only be practical if the Chain element supports extends, and I would suggest we ship what we have using Chain 1.0.0 first.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Chain Conditionals (was Change Action, ActionForm to use ActionContext?)
Posted by Don Brown <mr...@twdata.org>.
Ah, we finally stumble onto the very slipperly slope that is conditional
support for commons-chain. As we put more and more code into chain, we
will inevitably have commands that only need to execute under certain
conditions. There are three possibilities:
1. Bury conditional logic inside the command itself. This is the
approach many of the current chains take, but has the disadvantage of
the flow being very unclear to the reader of the config file, requiring
digging into the source code.
2. Create an "if" command, which then would logically lead to a
"switch" command and perhaps a "for" command. These commands would
check certain conditions then execute configured commands based on the
outcome.
3. Modify the XML so that the branching code is described as XML
elements. While this option produces the clearest code, it also brings
all the problems of something like Jelly with it.
So far, chain has resisted conditional support for the very reason it
opens up a huge can of worms. However, as soon as you start putting
complex logic in commons-chain, you are going to run up against the
problem again and again, and I think solution 1 will really start to be
inadequate. Solution 2 feels like a hack, and solution 3 (executable
XML) has been shown a bad idea through Jelly.
I wonder what a merging of commons-chain and a scripting language like
beanshell would look like...
Don
Joe Germuska wrote:
> At 10:00 AM -0800 2/18/05, Don Brown wrote:
>
>> I think the WebWork2/XWork implementation of interceptors is pretty
>> spot on. You define interceptors and interceptor stacks at the top of
>> your configuration file. Then, in the action mapping, we'd add an
>> attribute called say "interceptor" which would be the name of an
>> interceptor stack or interceptor. We could use "pre" and "post", but
>> post is really just an interceptor that only contains code on the
>> response.
>>
>> However, since we already have this commons-chain framework, perhaps
>> all we need is the "interceptor" attribute that would point to a chain
>> command. Chain supports the notions of Filters and is more robust in
>> that interceptor stacks or chains could have child chains, etc.
>
>
> This may be a reason for pushing in a direction I'd been mulling but
> hadn't implemented: break up "process-action" into parts. I don't like
> that everything after ValidateActionForm needs to have a hard-coded
> "check if form was valid" test; that shouldn't be built into the
> command, but rather should be part of the chain design. So maybe from a
> big picture,
>
> In short form, here's what it is now:
>
> servlet-standard (chain command):
> command: ExceptionCatcher
> lookup: process-action
> lookup: process-view
>
> into something like this:
> servlet-standard (chain command):
> command: ExceptionCatcher
> lookup: preprocess-action
> lookup: process-form
> conditional lookup: process-invalid-form
> conditional lookup: process-valid-form
> lookup: process-view
>
> where the current process-action would break down like this:
>
> "preprocess-action"
> lookup: servlet-standard-preprocess
> command: SelectLocale
> command: RequestNoCache
> command: SetContentType
> command: SelectAction
> command: AuthorizeAction
>
> "process-form"
> command: CreateActionForm
> command: PopulateActionForm
> command: ValidateActionForm
>
> "process-invalid-form"
> command: SelectInput
>
> "process-valid-form"
> command: ExecuteCommand
> command: SelectForward
> command: SelectInclude
> command: PerformInclude
> command: CreateAction
> command: ExecuteAction
>
> In that case, the "process-valid-form" could be wrapped in the
> interceptor (or do you also want to intercept the form part?)
>
> It seems like it would be pretty easy to write a variant of the Chain
> class which, when given an interceptor map, could use the name of each
> command it found to look for a registered interceptor, and use it to
> wrap the command. Except for your concern about avoiding putting things
> in the context, this seems like it might be a good candidate for
> inclusion in the core commons-chain library. Perhaps a base
> implementation could go there, and it could be elaborated for dependency
> injection.
>
> All of this sounds like a good candidate for Struts.SF.net for the
> foreseeable future...
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 10:00 AM -0800 2/18/05, Don Brown wrote:
>I think the WebWork2/XWork implementation of interceptors is pretty
>spot on. You define interceptors and interceptor stacks at the top of
>your configuration file. Then, in the action mapping, we'd add an
>attribute called say "interceptor" which would be the name of an
>interceptor stack or interceptor. We could use "pre" and "post", but
>post is really just an interceptor that only contains code on the
>response.
>
>However, since we already have this commons-chain framework, perhaps
>all we need is the "interceptor" attribute that would point to a chain
>command. Chain supports the notions of Filters and is more robust in
>that interceptor stacks or chains could have child chains, etc.
This may be a reason for pushing in a direction I'd been mulling but
hadn't implemented: break up "process-action" into parts. I don't
like that everything after ValidateActionForm needs to have a
hard-coded "check if form was valid" test; that shouldn't be built
into the command, but rather should be part of the chain design. So
maybe from a big picture,
In short form, here's what it is now:
servlet-standard (chain command):
command: ExceptionCatcher
lookup: process-action
lookup: process-view
into something like this:
servlet-standard (chain command):
command: ExceptionCatcher
lookup: preprocess-action
lookup: process-form
conditional lookup: process-invalid-form
conditional lookup: process-valid-form
lookup: process-view
where the current process-action would break down like this:
"preprocess-action"
lookup: servlet-standard-preprocess
command: SelectLocale
command: RequestNoCache
command: SetContentType
command: SelectAction
command: AuthorizeAction
"process-form"
command: CreateActionForm
command: PopulateActionForm
command: ValidateActionForm
"process-invalid-form"
command: SelectInput
"process-valid-form"
command: ExecuteCommand
command: SelectForward
command: SelectInclude
command: PerformInclude
command: CreateAction
command: ExecuteAction
In that case, the "process-valid-form" could be wrapped in the
interceptor (or do you also want to intercept the form part?)
It seems like it would be pretty easy to write a variant of the Chain
class which, when given an interceptor map, could use the name of
each command it found to look for a registered interceptor, and use
it to wrap the command. Except for your concern about avoiding
putting things in the context, this seems like it might be a good
candidate for inclusion in the core commons-chain library. Perhaps a
base implementation could go there, and it could be elaborated for
dependency injection.
All of this sounds like a good candidate for Struts.SF.net for the
foreseeable future...
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: Change Action, ActionForm to use ActionContext?
Posted by Don Brown <do...@gmail.com>.
I think the WebWork2/XWork implementation of interceptors is pretty
spot on. You define interceptors and interceptor stacks at the top of
your configuration file. Then, in the action mapping, we'd add an
attribute called say "interceptor" which would be the name of an
interceptor stack or interceptor. We could use "pre" and "post", but
post is really just an interceptor that only contains code on the
response.
However, since we already have this commons-chain framework, perhaps
all we need is the "interceptor" attribute that would point to a chain
command. Chain supports the notions of Filters and is more robust in
that interceptor stacks or chains could have child chains, etc.
If we did this, I would definately want to have better Spring
integration for commons-chain. These interceptors would probably need
several key business objects and I'd perfer to pass as little in the
context as possible.
Don
On Fri, 18 Feb 2005 11:35:20 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> At 9:04 AM -0800 2/18/05, Don Brown wrote:
> >You are correct, but in my opinion, these user commands that are
> >placed in the Struts request processing chain should have relevance to
> >your entire application and therefore are appropriate in the global
> >level of the request processing chain. An action is about how to
> >process an individual request, so in my book, these are two separate
> >concerns that should be clearly separated.
> >
> >There is a middle ground which I have been playing with on and off
> >frequently called "interceptors". In WebWork2, you can define action
> >interceptors that intercept certain actions, defined at a per-action
> >level. With Struts Action Invocation Framework (SAIF) at
> >struts.sf.net/saif , we ported interceptors to pre-chain Struts, but
> >it would be interesting to integrate that work with Struts as it is
> >now. It would be nice to define code that would be executed only
> >before certain groups of actions.
>
> Yeah... I'm just starting to look into some of this fancy JavaScript
> XMLHttpRequest stuff that Martin's always going off about ;-) and I
> thought it made sense to be able to define a chain whereby the posted
> XML gets converted into an object and placed into request scope in a
> routine fashion. I still don't even have a complete model in my head
> about what I would need to do to service requests like that, but this
> seems like a starting point.
>
> It also might be nice if some kind of interceptor could be designed
> to save people the trouble of copying the default chain-config.xml if
> they want to add things to the Request Processing chain. I have been
> thinking in terms of Maven preGoals and postGoals, but I'm not sure
> what the proper route to implementation would be.
>
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 9:04 AM -0800 2/18/05, Don Brown wrote:
>You are correct, but in my opinion, these user commands that are
>placed in the Struts request processing chain should have relevance to
>your entire application and therefore are appropriate in the global
>level of the request processing chain. An action is about how to
>process an individual request, so in my book, these are two separate
>concerns that should be clearly separated.
>
>There is a middle ground which I have been playing with on and off
>frequently called "interceptors". In WebWork2, you can define action
>interceptors that intercept certain actions, defined at a per-action
>level. With Struts Action Invocation Framework (SAIF) at
>struts.sf.net/saif , we ported interceptors to pre-chain Struts, but
>it would be interesting to integrate that work with Struts as it is
>now. It would be nice to define code that would be executed only
>before certain groups of actions.
Yeah... I'm just starting to look into some of this fancy JavaScript
XMLHttpRequest stuff that Martin's always going off about ;-) and I
thought it made sense to be able to define a chain whereby the posted
XML gets converted into an object and placed into request scope in a
routine fashion. I still don't even have a complete model in my head
about what I would need to do to service requests like that, but this
seems like a starting point.
It also might be nice if some kind of interceptor could be designed
to save people the trouble of copying the default chain-config.xml if
they want to add things to the Request Processing chain. I have been
thinking in terms of Maven preGoals and postGoals, but I'm not sure
what the proper route to implementation would be.
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: Change Action, ActionForm to use ActionContext?
Posted by Don Brown <do...@gmail.com>.
You are correct, but in my opinion, these user commands that are
placed in the Struts request processing chain should have relevance to
your entire application and therefore are appropriate in the global
level of the request processing chain. An action is about how to
process an individual request, so in my book, these are two separate
concerns that should be clearly separated.
There is a middle ground which I have been playing with on and off
frequently called "interceptors". In WebWork2, you can define action
interceptors that intercept certain actions, defined at a per-action
level. With Struts Action Invocation Framework (SAIF) at
struts.sf.net/saif , we ported interceptors to pre-chain Struts, but
it would be interesting to integrate that work with Struts as it is
now. It would be nice to define code that would be executed only
before certain groups of actions.
Don
On Wed, 16 Feb 2005 08:10:04 -0800, Shey Rab Pawo
<pa...@gmail.com> wrote:
> On Sun, 13 Feb 2005 23:09:07 -0800, Don Brown <mr...@twdata.org> wrote:
>
> See some thoughts and an implicit question within:
>
> > You make some good points, so I'll add my 2c:
> > 1. The chain logic should be separate from the application logic, which
> > could, however, use common-chain. I'm fine with using a chain command
> > to replace Action, as long as it can be made clear the line between the
> > two processes. One defines how all requests should be processed, and
> > the other, how this individual request should be handled.
>
> My understanding may be faulty but my understanding of the original
> intent behind chains vis-a-vis actions was to extract the request
> processor, break it down, and make it a chain of commands, so that
> this would give the user the option of supplanting code in whatever
> detail was required, desired or needed in the process of realizing the
> preliminary steps in an action. Essentially, then, the idea was to
> keep the action firmly ensconced in the role of a controller in the
> web MVC pattern but to allow the potential of allowing choices and
> improvements, or to make the early request processing (pre-model
> processing) pluggable. Is this right? If so, then I might have some
> suggestions, but, if not, then I probably do not understand what is
> happening and would appreciate a 35,000 foot explanation, if that
> seems appropriate at this point.
>
> --
> The radiance of all the stars does not equal a sixteenth part of the
> moon's radiance, likewise, good deeds giving us merit, all these do
> not equal a sixteenth part of the merit of loving-kindness..
>
> ---------------------------------------------------------------------
> 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
Re: Change Action, ActionForm to use ActionContext?
Posted by Shey Rab Pawo <pa...@gmail.com>.
On Sun, 13 Feb 2005 23:09:07 -0800, Don Brown <mr...@twdata.org> wrote:
See some thoughts and an implicit question within:
> You make some good points, so I'll add my 2c:
> 1. The chain logic should be separate from the application logic, which
> could, however, use common-chain. I'm fine with using a chain command
> to replace Action, as long as it can be made clear the line between the
> two processes. One defines how all requests should be processed, and
> the other, how this individual request should be handled.
My understanding may be faulty but my understanding of the original
intent behind chains vis-a-vis actions was to extract the request
processor, break it down, and make it a chain of commands, so that
this would give the user the option of supplanting code in whatever
detail was required, desired or needed in the process of realizing the
preliminary steps in an action. Essentially, then, the idea was to
keep the action firmly ensconced in the role of a controller in the
web MVC pattern but to allow the potential of allowing choices and
improvements, or to make the early request processing (pre-model
processing) pluggable. Is this right? If so, then I might have some
suggestions, but, if not, then I probably do not understand what is
happening and would appreciate a 35,000 foot explanation, if that
seems appropriate at this point.
--
The radiance of all the stars does not equal a sixteenth part of the
moon's radiance, likewise, good deeds giving us merit, all these do
not equal a sixteenth part of the merit of loving-kindness..
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Don Brown <mr...@twdata.org>.
You make some good points, so I'll add my 2c:
1. The chain logic should be separate from the application logic, which
could, however, use common-chain. I'm fine with using a chain command
to replace Action, as long as it can be made clear the line between the
two processes. One defines how all requests should be processed, and
the other, how this individual request should be handled.
2. Personally, I don't think an interface that has a single execute
method that gets the context for an Action type is a good solution (or
current Action's for that matter). To me, there are two different, yet
valid approaches to the Action concept:
a. A single class which combines the request logic and request
"model", or as we call it, ActionForm. Best implemented in WebWork2,
the action class has setters for the form data, but also an execute()
method containing the request's logic code. This pattern is great for
simplicity and keeping the action code servlet api independent, since
the framework handles calling setters so the class can deal with regular
Java types. The disadvantage of this pattern is, for a moderately
complex application, you have a ton of classes.
b. Multiple action methods per class ala DispatchAction. This pattern
is better in the current Struts world where the form is separate from
the action, so the action is rather small. DispatchAction (and its
children) allow you to group related actions into one logical unit,
cutting down the class count. In this pattern, the ActionContext and
ActionForm are passed into each execute-type method, letting the action
pull out what it needs. This disadvantage to this approach is your
action code is very tied to its environment (ActionContext in this
case), and you still need to define your forms somewhere else.
To me, having a single class with an execute(ActionContext) takes the
disadvages of both approaches without the benefits of each; the worst of
both worlds if you will. I believe the best solution is similar to JSF
where the action class is combined with the form, and yet the action
class can be any POJO that can contain any number of request processing
methods. Ideally, this action/form class would be able to span multiple
pages to define a logical process, possibly using Java continuations.
Don
Frank W. Zammetti wrote:
> Just as an interested third-party observer, I hope you don't mind two
> interjected points here...
>
> 1. A few years back I was involved in the development of a framework
> where I was working (this was just around the time Struts was hitting
> the scene). We in fact did what Joe is talking about: abstracted away
> the fact that the controller classes (synonymous with Actions) were
> working in a servlet environment. We did this exactly as you are
> talking about: a context class that was passed around instead of request
> and response and all that jazz. Doing this in Struts will be a major
> boon in terms of more easily unit testing code and reusing parts of a
> system in other environments, i.e., it should be easier to slap a Swing
> interface over what was formerly a web front-end with the application
> itself working as it did before. I believe this change will be worth
> whatever pain it may cause in the short run, without any question in my
> mind. I suspect anyone that understands the benefits of this change in
> the user community will agree whole-heartedly, so while the concern
> about changing core Struts classes is perfectly valid, I personally
> would put it aside in this instance believing that any difficulty it
> causes is worth it.
>
> 2. Joe mentions that an Action starts to look like a Chains Command at
> this point interface-wise, but that an Action isn't intended to be used
> as part of a chain. This raises a question in my mind: why not? I
> admit to not being completely up on chains and all the changes you guys
> are making in the new Struts branch, although recently I've tried to
> play some catch-up :) So, why couldn't an Action be seen as a link in
> the complete "request handling" chain that Struts implements? I would
> think it very powerful to just look at an Action as another Command in a
> chain, whatever that chain may be, because then you could have a chain
> containing multiple Actions (which I actually thought was already on the
> list of new capabilities?), and not have to worry about dealing with
> anything other than Commands. In other words, removing the whole
> concept of an Action in favor of nothing but Commands really simplifies
> things a little bit: one less concept to think about. The argument
> against this I would think is backwards compatibility, but it sounds
> like Joe's approach deals with that already, so going the extra step or
> two and making Actions true Chain Commands makes sense to me.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Just as an interested third-party observer, I hope you don't mind two
interjected points here...
1. A few years back I was involved in the development of a framework
where I was working (this was just around the time Struts was hitting
the scene). We in fact did what Joe is talking about: abstracted away
the fact that the controller classes (synonymous with Actions) were
working in a servlet environment. We did this exactly as you are
talking about: a context class that was passed around instead of request
and response and all that jazz. Doing this in Struts will be a major
boon in terms of more easily unit testing code and reusing parts of a
system in other environments, i.e., it should be easier to slap a Swing
interface over what was formerly a web front-end with the application
itself working as it did before. I believe this change will be worth
whatever pain it may cause in the short run, without any question in my
mind. I suspect anyone that understands the benefits of this change in
the user community will agree whole-heartedly, so while the concern
about changing core Struts classes is perfectly valid, I personally
would put it aside in this instance believing that any difficulty it
causes is worth it.
2. Joe mentions that an Action starts to look like a Chains Command at
this point interface-wise, but that an Action isn't intended to be used
as part of a chain. This raises a question in my mind: why not? I
admit to not being completely up on chains and all the changes you guys
are making in the new Struts branch, although recently I've tried to
play some catch-up :) So, why couldn't an Action be seen as a link in
the complete "request handling" chain that Struts implements? I would
think it very powerful to just look at an Action as another Command in a
chain, whatever that chain may be, because then you could have a chain
containing multiple Actions (which I actually thought was already on the
list of new capabilities?), and not have to worry about dealing with
anything other than Commands. In other words, removing the whole
concept of an Action in favor of nothing but Commands really simplifies
things a little bit: one less concept to think about. The argument
against this I would think is backwards compatibility, but it sounds
like Joe's approach deals with that already, so going the extra step or
two and making Actions true Chain Commands makes sense to me.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
Don Brown wrote:
> I don't mind sticking ActionContext everywhere as it is better than
> having the code rely directly on the servlet api, but since we are
> talking about modifying Action, why not get rid of this "must extend
> Action" stuff and make Action an interface? IMO, Struts core should
> depend on this new interface, say Actionable, where Action would be an
> implementation of this interface. Since the methods of Action like
> saveMessages have been moved to ActionContext, we can safely get rid of
> Action, a passing I won't soon be missing. :)
>
> Don
>
> Joe Germuska wrote:
>
>>> I believe now that we have a decent grounding to begin using the
>>> ActionContext as the request-scoped parameter throughout Struts - I
>>> think it can be applied to ActionForm and Action to hide dependencies
>>> on the Servlet API (and in ActionForm, to finally deprecate
>>> ActionErrors!)
>>>
>>> Are there any reasons not to press ahead with changes like that?
>>
>>
>>
>> I feel quite uncomfortable with committing significant changes to core
>> classes like Action and ActionForm without some more review, so I'm
>> going to be much more explicit about what I'm thinking. I could
>> provide patches, or an alternate source build for download, but I
>> think I can express the most important parts in email.
>>
>>
>> Here are the first two things I would do:
>>
>> [1] in Action, deprecate:
>> public ActionForward
>> execute(ActionMapping,ActionForm,HttpServletRequest,HttpServletResponse)
>> in favor of
>> public void execute(ActionContext)
>>
>> The base implementation in Action would delegate to the old signature
>> for as long as we saw fit to preserve it. It would take the
>> "ActionForward" returned by the old signature and call
>> context.setForwardConfig(ForwardConfig). Would it be worth returning
>> anything from here? This is now so close to the interface for Command
>> that I wonder if somehow it should be explicitly linked. However, it's
>> not a command, in that it's not expected to be used by a commons
>> chain. Is it worth relating them to each other?
>>
>> [2] in ActionForm, deprecate:
>> public ActionErrors validate(ActionMapping, HttpServletRequest)
>> public void reset(ActionMapping, HttpServletRequest)
>> in favor of
>> public boolean validate(ActionContext)
>> public void reset(ActionContext)
>>
>> In both of these cases, the implementations would simply delegate to
>> the deprecated methods. The new validate would return "true" if the
>> delegated validate returned null, or a size 0 ActionErrors,
>> otherwise"false"
>>
>> This would allow us to finally deprecate ActionErrors, which would be
>> nice.
>>
>> As a consequence of doing this, we might be able to go through other
>> parts of Struts and replace methods which explicitly depend on
>> HttpServletRequest with ones which depend instead on ActionContext.
>> The main value of this, in my mind, is eliminating the need to
>> coordinate Attribute keys in requestScope and sessionScope in favor of
>> encapsulating that inside the ActionContext implementation. Of
>> course, it also helps eliminate dependencies on the Servlet API, which
>> should make testing easier and might also help people who are
>> interested in using Struts in Portlet, Web Services, or other slightly
>> different environments.
>>
>> What would be the correct approach to Struts' own subclasses of Action
>> and ActionForm? I kind of assume we would need to not change them for
>> a while since people who may have subclassed them may be depending on
>> their implementations of the (proposedly) deprecated signatures?
>>
>> Is this even a good idea?
>>
>> Joe
>>
>
>
> ---------------------------------------------------------------------
> 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
[OT] XML, Scripting Languages (Re: Change Action, ActionForm to
use ActionContext?)
Posted by Joe Germuska <Jo...@Germuska.com>.
> > I'm convinced that XML is a lousy way to specify things like this.
>
>You might be right... People do try and cram way too much into XML IMHO,
>but I'm not completely convinced yet. I think I'd like to see a failed
>implementation of the idea before passing judgement. I share your concern
>to a lesser degree though for certain. :)
Some people consider Jelly a good example of a failed implementation,
although Maven continues to use it. (I believe a lot of their
dissatisfaction with it is driving Marmalade for Maven 2, although I
don't remember all the details.) If you go looking on the net,
you'll find diatribes against Jelly.
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: Change Action, ActionForm to use ActionContext?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Heh, just goes to show, an original idea is a rare commodity these days ;)
On Mon, February 14, 2005 11:40 am, Joe Germuska said:
> Sounds like Jelly, or Marmalade.
>
> http://jakarta.apache.org/commons/jelly/
> http://marmalade.codehaus.org/
I wasn't aware of those. I'd heard the name Jelly before, but never
Marmalade.
Why is it, by the way, that programming has to make you hungry?!? A lot
of us aren't in as good a shape as we used to be anyway, we don't need
various preserves reminding us all day :)
> I'm convinced that XML is a lousy way to specify things like this.
You might be right... People do try and cram way too much into XML IMHO,
but I'm not completely convinced yet. I think I'd like to see a failed
implementation of the idea before passing judgement. I share your concern
to a lesser degree though for certain. :)
> You've just described struts-bsf.
> http://struts.apache.org/bsf/
Your right, and that one I did know about. :) That project worries me a
bit though, for the reasons I mentioned earlier, hence the reason I
started coming up with my own expression language... I thought I might be
able to expose the flexibility I want without all the complexity and
potential problems of a true scripting language.
Struts-BSF is still a more than interesting project though, concerns aside :)
> I think scripting languages are likely to be more effective than XML
> for specifying any kind of complex logic.
The question that remains though is where you store the bits of script...
an XML config file would seem to be a reasonable answer to that question.
> Joe
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 11:27 AM -0500 2/14/05, Frank W. Zammetti wrote:
>On Mon, February 14, 2005 11:12 am, Vic said:
>> And 10 years from now... have a declerative langage... where all you do
>> is write in xml what you want to happen.)
>
>Although no one has any reason to believe that I actually was :) ... I've
>recently been toying with the idea of building exactly that. ... In essence,
>the ENTIRE control layer gets turned into ADL expressions in some XML
>configuration file, the only actual Java code you would have to still
>write are the business delegate classes.
Sounds like Jelly, or Marmalade.
http://jakarta.apache.org/commons/jelly/
http://marmalade.codehaus.org/
I'm convinced that XML is a lousy way to specify things like this.
>In fact, such an idea I believe could be added to Struts as it exists
>today... if you use something like BSF with Rhino, you should be able to
>make the expression language Javascript, and then you basically do away
>with Actions altogether in favor of executing pieces of Javascript pulled
>from a configuration file.
You've just described struts-bsf.
http://struts.apache.org/bsf/
I think scripting languages are likely to be more effective than XML
for specifying any kind of complex logic. (Although I asked one of
my developers to give struts-flow a go recently and she did not come
away very enthusiastic about its use of JavaScript for config/logic
expression.)
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: Change Action, ActionForm to use ActionContext?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Mon, February 14, 2005 11:12 am, Vic said:
> And 10 years from now... have a declerative langage... where all you do
> is write in xml what you want to happen.)
Although no one has any reason to believe that I actually was :) ... I've
recently been toying with the idea of building exactly that. The other
day I was in fact writing down the beginnings of an "Action Description
Language" that would allow you to build what would be akin to ActionForms
and Actions on-the-fly based on expressions in this language. In essence,
the ENTIRE control layer gets turned into ADL expressions in some XML
configuration file, the only actual Java code you would have to still
write are the business delegate classes. In a lot of ways it's just an
extension of what we have now by way of DynaActionForms, but brings the
idea to the Actions themselves and allows for a degree of logic too.
In fact, such an idea I believe could be added to Struts as it exists
today... if you use something like BSF with Rhino, you should be able to
make the expression language Javascript, and then you basically do away
with Actions altogether in favor of executing pieces of Javascript pulled
from a configuration file. Couple this with DynaActionForms, and you more
or less have a completely declarative model bolted on to Struts!
At least in theory :)
The benefit is that you kind of force people to have cleaner
separations... If creating Actions is declarative instead of programmatic,
they have little choice but to treat them as flow control mechanisms.
There wouldn't be any "eh, I'll just throw a little bit of logic here to
make life easier" syndrome :) Then again, especially going the Javascript
route, you could wind up with massively complex scripts and ungodly huge
configuration files, not to mention the performance impact of executing
script instead of bytecode. That's why I was going down the path of
creating my own expression language. I could eliminate or at least
minimize a lot of these negatives.
Eh, but this is clearly off-topic for this thread. I thought it was an
interesting thing to mention in light of your comment though Vic :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts-EL tags
Posted by Nicolas De Loof <ni...@capgemini.com>.
Struts-el allow you to get a "preview" of struts tags used on a servlet
2.4 container (that handle EL itself)
Using Struts-el will make the migration from servlet 2.3 to 2.4 easier
(just update taglib URI).
EL adds also power to tags and JSP can skip scriptlets. JSP code looks
more XML compliant (easier to read and maintain)
Nico.
Rajaneesh a écrit :
>Hi,
>
> Is there any site that gives me the advantages and disadvantages of going
>for Struts-EL taglibraries.
>
>Regards
>Rajaneesh
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
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
Struts-EL tags
Posted by Rajaneesh <ra...@slk-soft.com>.
Hi,
Is there any site that gives me the advantages and disadvantages of going
for Struts-EL taglibraries.
Regards
Rajaneesh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Shey Rab Pawo <pa...@gmail.com>.
On Fri, 18 Feb 2005 21:00:40 -0500, Ted Husted <hu...@apache.org> wrote:
>Used properly, the Command/Chain itself provides IoC. If you want to
use a different >implementation, swap in a different Command.
The Command/Chain, however, *is* the implementation of the
RequestProcessor in the ActionServlet so it cannot in principle
provide IoC to the ActionServlet in this respect. Command/Chain is
*cool*, I agree, but someone might not agree. That is why a
suggestion of using both IoC and CoR is made. I also think that it
would be good to provide some support for AOP. But, that is another
topic.
> But, all this should be extracurricular to Struts. All Struts needs to do is collect the input, pass it along to the appropriate business command, and select the next page to display. Where the business commands come from should remain an exercise for the developer.
However, if you are responding to my notes, which you apparently are,
the topic was the code supplanting the RequestProcessor, which is not
an exercise for the developer. This having two different discussions
of the chain, one to supplant the RequestProcessor and one for the
business logic leads to these misunderstandings.
>
> On Fri, 18 Feb 2005 16:09:21 -0800, Shey Rab Pawo wrote:
> > For what it is worth: -1
> >
> > To follow Martin Fowler's reasoning
> > (http://www.martinfowler.com/articles/injection.html), a
> > MovieLister wants to use a MovieFinder interface but needs to
> > create a MovieFinderImpl implementation of the MovieFinder
> > interface to do so. We want the MovieLister to be coupled only to
> > the interface and not to the implementation for all the reasons
> > that decoupling is supported in OOP patterns. Most importantly, we
> > want to be able to exchange implementations or to improve the
> > implemenation without changing the MovieLister class. IoC does
> > this. This seems to me to be very different than CoR and not
> > incompatible with CoR. I would like to see Action be IoC and for
> > RequestProcessor to be IoC and to have a default implemenation of
> > RequestProcessor that is CoR. This would be close to the ideal in
> > my mind. There are two types of plugins that are both very useful
> > and they do not seem to be in competition but consistent to me.
> > Does this make sense to anyone?
> >
> >
> > On Mon, 14 Feb 2005 10:12:40 -0600, Vic <vi...@friendvu.com> wrote:
> >
> >>
> >> Frank W. Zammetti wrote:
> >>
> >>> the more the idea of making an Action
> >>> a Command appeals to me.
> >>>
> >>>
> >> +1.
> >>
> >> In essence ... less Struts and more Chain.
> >> 2 chains, a user chain, and a request processing chain.
> >>
> >> (even one day go as far that the user-chain.xml replaces struts-
> >> config.xml. The chain xml can have infinite nubmer of elements
> >> now. And 10 years from now... have a declerative langage... where
> >> all you do is write in xml what you want to happen.)
> >>
> >>
> >> .V
> >>
> >> --
> >> Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
> >>
> >> ------------------------------------------------------------------
> >> --- 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
>
>
--
No one ever went blind looking at the bright side of life.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Ted Husted <hu...@apache.org>.
The page isn't there any more, but as I remember the example, the Action would be equate to the Listener and the business logic chain would equate to the Finder.
As it stands now, the Action could simply populate a Context with whatever attributes a Finder expects. It executes the "Finder" command and chooses the next page to display.
The Finder Command (or Chain) might use injection or some other technique to find a implementation of a Finder interface. But, in my experience, that's really not necessary. Used properly, the Command/Chain itself provides IoC. If you want to use a different implementation, swap in a different Command. No one outside the Finder Command need know what implementation it calls. The trick is to use finely grained Commands. Depending on how much flexibility you need, the only and only task for a Command might be to put into the Context an implementation of an interface.
But, all this should be extracurricular to Struts. All Struts needs to do is collect the input, pass it along to the appropriate business command, and select the next page to display. Where the business commands come from should remain an exercise for the developer.
I do think it would be cool for us to lead by example, and use CoR in MailReader and other example applications. But I don't think we need to build support for CoR into Struts for applications that use Struts. It's easy enough to plug-in already.
-Ted.
On Fri, 18 Feb 2005 16:09:21 -0800, Shey Rab Pawo wrote:
>�For what it is worth: -1
>
>�To follow Martin Fowler's reasoning
>�(http://www.martinfowler.com/articles/injection.html), a
>�MovieLister wants to use a MovieFinder interface but needs to
>�create a MovieFinderImpl implementation of the MovieFinder
>�interface to do so. We want the MovieLister to be coupled only to
>�the interface and not to the implementation for all the reasons
>�that decoupling is supported in OOP patterns. �Most importantly, we
>�want to be able to exchange implementations or to improve the
>�implemenation without changing the MovieLister class. �IoC does
>�this. �This seems to me to be very different than CoR and not
>�incompatible with CoR. �I would like to see Action be IoC and for
>�RequestProcessor to be IoC and to have a default implemenation of
>�RequestProcessor that is CoR. �This would be close to the ideal in
>�my mind. �There are two types of plugins that are both very useful
>�and they do not seem to be in competition but consistent to me.
>�Does this make sense to anyone?
>
>
>�On Mon, 14 Feb 2005 10:12:40 -0600, Vic <vi...@friendvu.com>�wrote:
>
>>
>>�Frank W. Zammetti wrote:
>>
>>>�the more the idea of making an Action
>>>�a Command appeals to me.
>>>
>>>
>>�+1.
>>
>>�In essence ... less Struts and more Chain.
>>�2 chains, a user chain, and a request processing chain.
>>
>>�(even one day go as far that the user-chain.xml replaces struts-
>>�config.xml. The chain xml can have infinite nubmer of elements
>>�now. And 10 years from now... have a declerative langage... where
>>�all you do is write in xml what you want to happen.)
>>
>>
>>�.V
>>
>>�--
>>�Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
>>
>>�------------------------------------------------------------------
>>�--- 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
Re: Change Action, ActionForm to use ActionContext?
Posted by Shey Rab Pawo <pa...@gmail.com>.
For what it is worth: -1
To follow Martin Fowler's reasoning
(http://www.martinfowler.com/articles/injection.html), a MovieLister
wants to use a MovieFinder interface but needs to create a
MovieFinderImpl implementation of the MovieFinder interface to do so.
We want the MovieLister to be coupled only to the interface and not to
the implementation for all the reasons that decoupling is supported in
OOP patterns. Most importantly, we want to be able to exchange
implementations or to improve the implemenation without changing the
MovieLister class. IoC does this. This seems to me to be very
different than CoR and not incompatible with CoR. I would like to see
Action be IoC and for RequestProcessor to be IoC and to have a default
implemenation of RequestProcessor that is CoR. This would be close to
the ideal in my mind. There are two types of plugins that are both
very useful and they do not seem to be in competition but consistent
to me. Does this make sense to anyone?
On Mon, 14 Feb 2005 10:12:40 -0600, Vic <vi...@friendvu.com> wrote:
>
>
> Frank W. Zammetti wrote:
>
> >the more the idea of making an Action
> >a Command appeals to me.
> >
> >
> +1.
>
> In essence ... less Struts and more Chain.
> 2 chains, a user chain, and a request processing chain.
>
> (even one day go as far that the user-chain.xml replaces
> struts-config.xml. The chain xml can have infinite nubmer of elements now.
> And 10 years from now... have a declerative langage... where all you do
> is write in xml what you want to happen.)
>
>
> .V
>
> --
> Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
--
No one ever went blind looking at the bright side of life.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Vic <vi...@friendvu.com>.
Frank W. Zammetti wrote:
>the more the idea of making an Action
>a Command appeals to me.
>
>
+1.
In essence ... less Struts and more Chain.
2 chains, a user chain, and a request processing chain.
(even one day go as far that the user-chain.xml replaces
struts-config.xml. The chain xml can have infinite nubmer of elements now.
And 10 years from now... have a declerative langage... where all you do
is write in xml what you want to happen.)
.V
--
Forums, Boards, Blogs and News in RiA <http://www.boardVU.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Mon, February 14, 2005 9:20 am, Joe Germuska said:
> Well, since you can already use an <action> element to cause the
> invocation of a command (or chain), I think it would be redundant to
> make "Action" a command for that purpose. However, if we go ahead
> and change the signature to Action, the net effect will be about the
> same, as the "ExecuteAction" command will certainly pass in the same
> chain (Action)Context which would be passed in to
> Action-implementing-Command. The only real difference would be
> whether or not the Action class would be given the ability to return
> "true" to indicate that the chain processing should go no further.
>
> So, as it stands now, the main benefit of privileging "Action" is
> that you can specify the processing class in struts-config.xml,
> instead of having to go to another file to set it up. That's a
> decent benefit, I'd say -- we don't want to make configuration a
> nightmare.
No argument at all, anything that makes configuration more difficult,
unless there is such a clear benefit as to justify the added difficulty,
is something to be avoided.
However, the more I think about it, the more the idea of making an Action
a Command appeals to me. Further, as I mentioned in another post,
conceptually I can see where you might consider the Action execution of
the overall request processing chain to itself be a subchain, even if most
of the time it's a chain with a single Command. To do this though, if I
understand what your saying, would require a developer to configure that
subchain in chains-config. That wouldn't be a good thing.
But, if we for a moment assume that the conceptual argument for an Action
being a Command in an "Action chain", which is itself just a subchain of
the overall request processing chain, is something we agree upon, we're
really at that point just talking about a matter of configuration. If
we're there, I would think the configuration issue could be dealt with,
perhaps something as simple as having Struts read in the action mapping,
which contains the chain configuration information, and pass just the
pertinent chain information to the Commons Chain configuration module
through what might be a new configuration path... For instance, what if an
Action has a new attribute "chain" that is just a comma-separated list of
Commands to execute. I would have to think there would be a way of taking
that list and configuring a chain based on it, no? Even if such
functionality didn't exist now, would adding it to Commons Chain be all
that onerous, especially if we agree about the benefit?
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Wolfgang Gehner <ne...@infonoia.com>.
Psychologically, I would not deprecate the good old execute(1,2,3,4)
yet. Else Struts 1.3 will make all the millions of existing Struts apps
look old (which is the same as "bad" in the era of Nip/Tuck). "If people
want to code the old way, let them" (quote of my lead developer), esp.
on something as established as Struts. Bad enough Shale makes people
mistakenly think that good old Struts is being abandoned. Deprecating
tested methods won't help much imo.
Doesn't mean that there couldn't be an additional (empty) hook
execute(ActionContext) implemented in Action (or in "CommandAction"
extends Action), for the users to extend it.
my 2 cts.
Reducing number of config files is a most worthy goal, so +1 on a way to
use a simple command without chain-config.xml
The real kicker for me in this goal would be autodiscovery of all
struts-config files in the war, like Eclipse discovers its plugins, on
startup (say, look for all xml's that use struts_1_3.dtd).
Wolfgang Gehner
Joe Germuska wrote:
> At 2:05 PM -0800 2/13/05, Don Brown wrote:
>
>> I don't mind sticking ActionContext everywhere as it is better than
>> having the code rely directly on the servlet api, but since we are
>> talking about modifying Action, why not get rid of this "must extend
>> Action" stuff and make Action an interface? IMO, Struts core should
>> depend on this new interface, say Actionable, where Action would be
>> an implementation of this interface. Since the methods of Action
>> like saveMessages have been moved to ActionContext, we can safely get
>> rid of Action, a passing I won't soon be missing. :)
>
>
> At 6:28 PM -0500 2/13/05, Frank W. Zammetti wrote:
>
>> 2. Joe mentions that an Action starts to look like a Chains Command
>> at this point interface-wise, but that an Action isn't intended to be
>> used as part of a chain. This raises a question in my mind: why
>> not? I admit to not being completely up on chains and all the
>> changes you guys are making in the new Struts branch, although
>> recently I've tried to play some catch-up :) So, why couldn't an
>> Action be seen as a link in the complete "request handling" chain
>> that Struts implements? I would think it very powerful to just look
>> at an Action as another Command in a chain
>
>
> Well, since you can already use an <action> element to cause the
> invocation of a command (or chain), I think it would be redundant to
> make "Action" a command for that purpose. However, if we go ahead and
> change the signature to Action, the net effect will be about the same,
> as the "ExecuteAction" command will certainly pass in the same chain
> (Action)Context which would be passed in to
> Action-implementing-Command. The only real difference would be
> whether or not the Action class would be given the ability to return
> "true" to indicate that the chain processing should go no further.
>
> So, as it stands now, the main benefit of privileging "Action" is that
> you can specify the processing class in struts-config.xml, instead of
> having to go to another file to set it up. That's a decent benefit,
> I'd say -- we don't want to make configuration a nightmare.
>
> Don sent a more substantial proposal between when I wrote most of this
> and when I sent it, so I'll save reactions to that until I have a
> chance to digest it. My initial reaction, though, is that with the
> CoR request processor, it's feasible to support multiple parallel
> models: most simply, in a universal-per-app environment where you
> simply put different commands in the chain, but also quite possibly in
> a multiple-approach-per-app design where the chain has a way to
> recognize which processing model to bring to bear.
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Joe Germuska <Jo...@Germuska.com>.
At 2:05 PM -0800 2/13/05, Don Brown wrote:
>I don't mind sticking ActionContext everywhere as it is better than
>having the code rely directly on the servlet api, but since we are
>talking about modifying Action, why not get rid of this "must extend
>Action" stuff and make Action an interface? IMO, Struts core should
>depend on this new interface, say Actionable, where Action would be
>an implementation of this interface. Since the methods of Action
>like saveMessages have been moved to ActionContext, we can safely
>get rid of Action, a passing I won't soon be missing. :)
At 6:28 PM -0500 2/13/05, Frank W. Zammetti wrote:
>2. Joe mentions that an Action starts to look like a Chains Command
>at this point interface-wise, but that an Action isn't intended to
>be used as part of a chain. This raises a question in my mind: why
>not? I admit to not being completely up on chains and all the
>changes you guys are making in the new Struts branch, although
>recently I've tried to play some catch-up :) So, why couldn't an
>Action be seen as a link in the complete "request handling" chain
>that Struts implements? I would think it very powerful to just look
>at an Action as another Command in a chain
Well, since you can already use an <action> element to cause the
invocation of a command (or chain), I think it would be redundant to
make "Action" a command for that purpose. However, if we go ahead
and change the signature to Action, the net effect will be about the
same, as the "ExecuteAction" command will certainly pass in the same
chain (Action)Context which would be passed in to
Action-implementing-Command. The only real difference would be
whether or not the Action class would be given the ability to return
"true" to indicate that the chain processing should go no further.
So, as it stands now, the main benefit of privileging "Action" is
that you can specify the processing class in struts-config.xml,
instead of having to go to another file to set it up. That's a
decent benefit, I'd say -- we don't want to make configuration a
nightmare.
Don sent a more substantial proposal between when I wrote most of
this and when I sent it, so I'll save reactions to that until I have
a chance to digest it. My initial reaction, though, is that with the
CoR request processor, it's feasible to support multiple parallel
models: most simply, in a universal-per-app environment where you
simply put different commands in the chain, but also quite possibly
in a multiple-approach-per-app design where the chain has a way to
recognize which processing model to bring to bear.
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: Change Action, ActionForm to use ActionContext?
Posted by Don Brown <mr...@twdata.org>.
I don't mind sticking ActionContext everywhere as it is better than
having the code rely directly on the servlet api, but since we are
talking about modifying Action, why not get rid of this "must extend
Action" stuff and make Action an interface? IMO, Struts core should
depend on this new interface, say Actionable, where Action would be an
implementation of this interface. Since the methods of Action like
saveMessages have been moved to ActionContext, we can safely get rid of
Action, a passing I won't soon be missing. :)
Don
Joe Germuska wrote:
>> I believe now that we have a decent grounding to begin using the
>> ActionContext as the request-scoped parameter throughout Struts - I
>> think it can be applied to ActionForm and Action to hide dependencies
>> on the Servlet API (and in ActionForm, to finally deprecate
>> ActionErrors!)
>>
>> Are there any reasons not to press ahead with changes like that?
>
>
> I feel quite uncomfortable with committing significant changes to core
> classes like Action and ActionForm without some more review, so I'm
> going to be much more explicit about what I'm thinking. I could provide
> patches, or an alternate source build for download, but I think I can
> express the most important parts in email.
>
>
> Here are the first two things I would do:
>
> [1] in Action, deprecate:
> public ActionForward
> execute(ActionMapping,ActionForm,HttpServletRequest,HttpServletResponse)
> in favor of
> public void execute(ActionContext)
>
> The base implementation in Action would delegate to the old signature
> for as long as we saw fit to preserve it. It would take the
> "ActionForward" returned by the old signature and call
> context.setForwardConfig(ForwardConfig). Would it be worth returning
> anything from here? This is now so close to the interface for Command
> that I wonder if somehow it should be explicitly linked. However, it's
> not a command, in that it's not expected to be used by a commons chain.
> Is it worth relating them to each other?
>
> [2] in ActionForm, deprecate:
> public ActionErrors validate(ActionMapping, HttpServletRequest)
> public void reset(ActionMapping, HttpServletRequest)
> in favor of
> public boolean validate(ActionContext)
> public void reset(ActionContext)
>
> In both of these cases, the implementations would simply delegate to the
> deprecated methods. The new validate would return "true" if the
> delegated validate returned null, or a size 0 ActionErrors,
> otherwise"false"
>
> This would allow us to finally deprecate ActionErrors, which would be nice.
>
> As a consequence of doing this, we might be able to go through other
> parts of Struts and replace methods which explicitly depend on
> HttpServletRequest with ones which depend instead on ActionContext. The
> main value of this, in my mind, is eliminating the need to coordinate
> Attribute keys in requestScope and sessionScope in favor of
> encapsulating that inside the ActionContext implementation. Of course,
> it also helps eliminate dependencies on the Servlet API, which should
> make testing easier and might also help people who are interested in
> using Struts in Portlet, Web Services, or other slightly different
> environments.
>
> What would be the correct approach to Struts' own subclasses of Action
> and ActionForm? I kind of assume we would need to not change them for a
> while since people who may have subclassed them may be depending on
> their implementations of the (proposedly) deprecated signatures?
>
> Is this even a good idea?
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Change Action, ActionForm to use ActionContext?
Posted by Ted Husted <hu...@apache.org>.
I don't know if we want to step away from extending Action just yet. But, I agree that could step toward using a new interface.
So, we define an "ActionCommand" interface, which is the Command interface but with an ActionContext instead of Context.
* Boolean execute(ActionCommand) throws Exception;
If the class implements ActionCommand, we call that execute signature. If not, we handle it the Classic way. This could be a class by class election, so people could try ActionCommands without ditching Actions.
Likewise, we could also support implementing ActionCommand on an ActionForm. The Action Class could then be omitted altogether, and the processor would call the ActionForm execute instead. Again, this is something people could decide to do on a case-by-case basis. Sometimes it's better to have an all-on-one, sometimes it's better to mix-and-match. We can do both.
:) In fact, we could *always* do both. It's not hard to write a standard Action that just calls an execute method on a custom ActionForm class. But now that we have an ActionContext, it's trivial. :)
Meanwhile, I would tend to be -1 on deprecating much in the 1.3 series. We should add experimental members for people to experiment with in the field, and then decide where to go in 1.4 and beyond. It might be a good idea to just stop now, stabilize what is already done, maybe do extends for good measure, sort out the website, and ship Core.
In terms of future direction, I would also be *very* concerned if we started to add the equivalent of a CoR Catalog to Struts Classic. It's an intriguing idea, but I don't think there is much value-add over using CoR on it's own and just having an Action or ActionCommand call into a user-defined Catalog.
It's vital that we encourage people to write the business logic separate from Struts, so it can be tested and used outside of Struts. If we put a Catalog on the Struts layer for application use, then then next thing you know, people are writing business logic against the StrutsContext instead of against their own Context :(
IMHO, we should encourage people to make separate and distinct calls to their own Commands, and then use the Action as an adapter between the Application's Commands and the presentation layer. (Envision overlapping circles.) If we make it too easy to bolt your own Chain into an ActionChain, then that's what a lot of people will do. Before you know it, we're back to how do I test the ActionChain outside of Struts?
When I work with teams in the field, the hardest sell is convincing people that we should develop "into" Struts rather than "with" Struts. There is a tendency to see Struts as a hammer and everything else as nails. We need to encourage people to see an application as a toolbelt, and Struts as a finishing tool. The "heavy lifting" should be done *outside* of Struts in something like CoR.
I'd be leery of anything that gives people the impression that they are writing an application "with" Struts, rather than writing it with CoR and then hooking it up to Struts.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org