You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Ted Husted <te...@gmail.com> on 2006/02/20 16:19:39 UTC
Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
On 2/19/06, Michael Jouravlev <jm...@gmail.com> wrote:
> On 2/19/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> > Anyone can quote chapter and verse from the GoF book. Can you instead
> > explain *why* what's in Struts isn't CoR? And, perhaps more
> > importantly, explain why, even if it isn't an exact match for the
> > pattern, it matters one bit?
>
> By the way, is Struts CoR actually a CoR? This is not a trick
> question, I am just asking.
I think one of the reasons the current processing chain is so complex
is because it just refactors the old set of method calls into a set of
commands. This is a good starting point, but there is more we could
do. The next step might be to anaylze the different scenarious the
current guantlet is trying to cover and compose those into different
chains. Which chain is called would depend on the nature of the
request.
For example, there no reason to call a processing chain that includes
handling uploads if the request isn't doing uploads. Or code that
handles modules if modules are not being used.
One idea might be to build the processing chain dynamically on a per
request basis.
Though, and even better approach might be to follow WebWork's lead and
arrange for each Action to have it's own processing chain. There could
be a default chain for the application, which an individual action
would be use, replace, or extend.
In our ASPX applications, we build the web processing chain
dynamically on each request. There is a "pre-opt" chain and a
"post-opt" chain, and an Action Command (which could also be a
chain). When the request comes in, we create a new chain, and add the
pre-opt chain, the Action chain, and post-opt chain to the new dynamic
chain, and then execute that.
Of course, a benefit here is that it is easy to test the Action chain
in isolation, along with the individual commands. The pre-opt and
post-opt chains can also be tested in isolation.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by Ted Husted <te...@gmail.com>.
On 2/20/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I mean, we look up chains in a catalog, not
> commands, right? (except technically you *are* looking up a command, I
> think conceptually for Struts developers that isn't an accurate
> description though).
In our C# implementation, we give Commands (and therefore Chains) a
name, so we can lookup the Command (or Chain) by name. In this way,
the caller doesn't need to know anything about the implementation.
So, to fire a Command from an ASPX codebehind, we do something like
IViewHelper helper = GetHelperFor(App.MEETING_LIST); // string constant
helper.Execute();
if (helper.IsNominal) { ... }
Where the helper encapsulates the Context and Command, along with
error handling and such.
In my own work, I've found the ability to interchange Commands with
Chains to be invaluable. I couldn't imagine living without the
subsituation principle now.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
1.3 sample download size
Posted by Wolfgang Gehner <ne...@infonoia.com>.
I've considered creating a lighter sample.
However, this is a real app, with a real database (PostgreSQL), so there
is some setup involved, whether the download has Eclipse or not. For a
whole suite, it's actually quite light (compared to big blue downloads,
anyway :-).
There also is some Struts 1.3 sample code (without DB) in the download
for this article: http://www.infonoia.com/en/content.jsp?d=inf.05.09
(40MB to get started).
Wolfgang
Michael Jouravlev wrote:
>On 2/20/06, Wolfgang Gehner <ne...@infonoia.com> wrote:
>
>
>>Here is a non-committer speaking (me): The CoR stuff is great as it is.
>>We have used it in production since mid last year. I have written an
>>article a year ago to tell people how great it is, and how we use
>>Commands instead of Actions (read up if you like
>>http://www.infonoia.com/en/content.jsp?d=inf.05.06).
>>
>>
>
>Wolfgang, can you create a sample download without JRE, Tomcat and Eclipse?
>
>Thanks.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
Re: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by Michael Jouravlev <jm...@gmail.com>.
On 2/20/06, Wolfgang Gehner <ne...@infonoia.com> wrote:
> Here is a non-committer speaking (me): The CoR stuff is great as it is.
> We have used it in production since mid last year. I have written an
> article a year ago to tell people how great it is, and how we use
> Commands instead of Actions (read up if you like
> http://www.infonoia.com/en/content.jsp?d=inf.05.06).
Wolfgang, can you create a sample download without JRE, Tomcat and Eclipse?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Might I suggest, and not to toot my own horn or anything, but if you are
going to launch a chain manually from an Action and not use what 1.3
provides, you might want to look at the chain implementation in Java Web
Parts:
http://javawebparts.sourceforge.net/javadocs/javawebparts/misc/chain/package-summary.html
...and related...
http://www.metalstorm.ee/bands/view_albums.php?band_id=queensryche
I believe it provides some capabilities Commons Chain doesn't, and is
otherwise different in some ways that you may (or may not!) like.
I'm not saying replace Commons Chain in 1.3 with this by the way,
Commons Chain is perfectly fine IMO, but if anyone is essentially going
to go off and do chains on their own, as I have done using Struts 1.2.6
for example, this alternate implementation might be worth a look.
Frank
Wolfgang Gehner wrote:
> Here is a non-committer speaking (me): The CoR stuff is great as it is.
> We have used it in production since mid last year. I have written an
> article a year ago to tell people how great it is, and how we use
> Commands instead of Actions (read up if you like
> http://www.infonoia.com/en/content.jsp?d=inf.05.06).
>
> Struts has a long history of betas being used in production (I remember
> very large sites using 1.1b3 (or was it b2) in production, without me
> telling them to).
>
> I also believe that "Action" is a bit "flat" of a name for the greatness
> of 1.3. I could have done with "Struts CoR".
>
> But at this point, JUST GET IT OUT THE DOOR, PLEASE.
>
> FYI, we don't use actions any more, we use commands (in a chain, with
> chain-config files). But the framework lets us do both, even in one
> request. So Paul, if you believe that your chain must start in an
> action, go ahead, you can do it today.
>
> In your (base?) action, just do
> Catalog catalog = (Catalog)
> req.getSession().getServletContent().getAttribute("catalog");
> Command command = catalog.getCommand("myChain");
> boolean stop = command.execute(new ContextBase());
> //or command.execute((Context) context);
> Then do with the response what you want. We like passing the
> ServletActionContext through; we even fill the Struts Chain with our own
> augmented one that extends ServletActionContext :-)
> Very clean and simple code is the result.
>
> And the 1.3 release code it is great as it is!
>
> Wolfgang Gehner
> www.infonoia.com
>
>
>
>
>
> Paul Benedict wrote:
>
>>>> Of course, some people are already using what
>>>> we already have in production, so we need to be careful.
>>>>
>>
>> Ted, I am really surprised to hear this. Whose fault is it
>> to be using alpha/beta quality code in production? Certainly not
>> your fault, or any commiter's fault, except the fault of the
>> developer who thought that bleedging edge technology would
>> stop bleeding before it was released.
>>
>> A couple days back, Dakota Jack replied to something similar
>> because you've expressed this sentiment before. He said that
>> it's better to do things correctly than to have hasty releases.
>> I 10,000% agree with him.
>>
>> You shouldn't feel compelled to prevent breaking people's
>> production code with alpha/beta level software. Really, it
>> isn't your responsiblity to support non-production releases.
>> That's a bad gamble on their part and that has nothing to do
>> with you.
>>
>> So I hear at least one Committer (maybe three?) are using
>> Struts 1.3 in production, but they must own THEIR decision
>> and deal with the consequences with using unreleased software.
>> They should get no more deference than any other Struts user,
>> and I hope you don't have them in mind when you're thinking
>> about not breaking non-released code.
>>
>> Please, let's do things "the right way" by refactoring
>> unreleased software (even it breaks the early adopters) as necessary,
>> and not breaking released software. That sounds
>> like a winning strategy to me.
>>
>> Paul
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.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: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by Ted Husted <te...@gmail.com>.
On 2/20/06, Wolfgang Gehner <ne...@infonoia.com> wrote:
> Struts has a long history of betas being used in production (I remember
> very large sites using 1.1b3 (or was it b2) in production, without me
> telling them to).
Yes, that's true. I was using a Struts 1.0 beta in production for a
large site months before we shipped the Struts 1.0 final release. The
whole reason why I was involved in Struts was to use it on that site,
and I wasn't going to let the "beta" moniker stop me!
The "me first" tradition goes back to the Apache HTTPD team. The acid
test for an Apache HTTPD release has always been whether it can handle
the Apache.org site. There's an old Apache HTTPD guideline (not a
rule, but a suggestion) that a +1 vote isn't really binding *UNLESS*
you are using the beta in production!
The ASF strategy for success has always been that we eat our own dog
food, and I doubt that will ever change. After all, if the Committers
are not using a build in production, how can we expect anyone else to
trust it? We have always been our own first users.
It's true that we decide to put a build into production, it would be
better to use a tagged build than one of the nightlies. But, the
Struts 1.3 code has been cooking for about 18 months now, and some of
us didn't want to wait that long. And neither should we. Now that
we've streamlined the releases and release process, perhaps we can tag
the builds more often.
-- HTH, Ted.
** http://www.husted.com/ted/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by Wolfgang Gehner <ne...@infonoia.com>.
Here is a non-committer speaking (me): The CoR stuff is great as it is.
We have used it in production since mid last year. I have written an
article a year ago to tell people how great it is, and how we use
Commands instead of Actions (read up if you like
http://www.infonoia.com/en/content.jsp?d=inf.05.06).
Struts has a long history of betas being used in production (I remember
very large sites using 1.1b3 (or was it b2) in production, without me
telling them to).
I also believe that "Action" is a bit "flat" of a name for the greatness
of 1.3. I could have done with "Struts CoR".
But at this point, JUST GET IT OUT THE DOOR, PLEASE.
FYI, we don't use actions any more, we use commands (in a chain, with
chain-config files). But the framework lets us do both, even in one
request. So Paul, if you believe that your chain must start in an
action, go ahead, you can do it today.
In your (base?) action, just do
Catalog catalog = (Catalog)
req.getSession().getServletContent().getAttribute("catalog");
Command command = catalog.getCommand("myChain");
boolean stop = command.execute(new ContextBase());
//or command.execute((Context) context);
Then do with the response what you want. We like passing the
ServletActionContext through; we even fill the Struts Chain with our own
augmented one that extends ServletActionContext :-)
Very clean and simple code is the result.
And the 1.3 release code it is great as it is!
Wolfgang Gehner
www.infonoia.com
Paul Benedict wrote:
>>>Of course, some people are already using what
>>>we already have in production, so we need to be careful.
>>>
>>>
>
>Ted, I am really surprised to hear this. Whose fault is it
>to be using alpha/beta quality code in production? Certainly not
>your fault, or any commiter's fault, except the fault of the
>developer who thought that bleedging edge technology would
>stop bleeding before it was released.
>
>A couple days back, Dakota Jack replied to something similar
>because you've expressed this sentiment before. He said that
>it's better to do things correctly than to have hasty releases.
>I 10,000% agree with him.
>
>You shouldn't feel compelled to prevent breaking people's
>production code with alpha/beta level software. Really, it
>isn't your responsiblity to support non-production releases.
>That's a bad gamble on their part and that has nothing to do
>with you.
>
>So I hear at least one Committer (maybe three?) are using
>Struts 1.3 in production, but they must own THEIR decision
>and deal with the consequences with using unreleased software.
>They should get no more deference than any other Struts user,
>and I hope you don't have them in mind when you're thinking
>about not breaking non-released code.
>
>Please, let's do things "the right way" by refactoring
>unreleased software (even it breaks the early adopters) as
>necessary, and not breaking released software. That sounds
>like a winning strategy to me.
>
>Paul
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
Re: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by Paul Benedict <pa...@yahoo.com>.
>> Of course, some people are already using what
>> we already have in production, so we need to be careful.
Ted, I am really surprised to hear this. Whose fault is it
to be using alpha/beta quality code in production? Certainly not
your fault, or any commiter's fault, except the fault of the
developer who thought that bleedging edge technology would
stop bleeding before it was released.
A couple days back, Dakota Jack replied to something similar
because you've expressed this sentiment before. He said that
it's better to do things correctly than to have hasty releases.
I 10,000% agree with him.
You shouldn't feel compelled to prevent breaking people's
production code with alpha/beta level software. Really, it
isn't your responsiblity to support non-production releases.
That's a bad gamble on their part and that has nothing to do
with you.
So I hear at least one Committer (maybe three?) are using
Struts 1.3 in production, but they must own THEIR decision
and deal with the consequences with using unreleased software.
They should get no more deference than any other Struts user,
and I hope you don't have them in mind when you're thinking
about not breaking non-released code.
Please, let's do things "the right way" by refactoring
unreleased software (even it breaks the early adopters) as
necessary, and not breaking released software. That sounds
like a winning strategy to me.
Paul
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Next steps for Action 1.3.1 (was Re: Reasons for 1.3 release)
Posted by Ted Husted <te...@gmail.com>.
On 2/20/06, Paul Benedict <pa...@yahoo.com> wrote:
>> On 2/19/06, Martin Cooper <ma...@apache.org> wrote:
>>>This is what I meant when I said earlier (in this thread) that I
don't have any Action
>>> classes in my 1.3 app. I don't need 'em any more, even just to
invoke a chain.
>
> If this is the future direction of Struts ...
Part of the reason we wanted to release Action 1.3.0 before we went
any farther is because we're trying to decide if Action should be a
Command. Or, if Action should fire a Command. Or, are there pros and
cons for either strategy?
A few of us have tried some things in our own applications, but we'd
like other engineers to also give the-story-so-far a try, and let us
know how it works in their applications too.
For the high points of some of what we've discussed so far, see the
Action Roadmap.
* http://struts.apache.org/struts-action/roadmap.html
A while back, Joe mentioned that he had started adding more
documentation for Struts Chain (our usage of Commons Chain to create
the Composable Request Processor), but realized that there some things
he might want to change. Of course, some people are already using what
we already have in production, so we need to be careful.
Now that we have a tagged build out there, it will be easier to make
changes. We can now talk in terms of changes between Action 1.3.0 and
Action 1.3.1, rather than changes between one nightly build and the
next.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org