You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Michael Jouravlev <jm...@gmail.com> on 2006/02/16 18:39:55 UTC
Reasons for 1.3 release
How Struts committers justify the reason for 1.3 release? What is the
point in 1.3 considering that WebWork / 2.0 already has interceptors
and other goodies? People need time to learn how to use CoR stuff.
While they learn, WebWork will push 1.x out of the window. Am I wrong?
Maybe 1.3 branch should contain only bugfixes?
Another way to look at 1.3 is that some early adopters use 1.3
nightlies for quite some time already. These adopters do not need a
lot of docs/samples in official release since they already are using
this version. For them, official 1.3.x release will mean adoption by
management.
So, one might think that 1.3 is intended mostly for early adopters to
please their management. Everybody else will eventually switch from
1.2 directly to 2.0. Thus, 1.3 might be seen as a release not really
intended for general public.
Do I get it all wrong? Apache Struts web page talks about two
frameworks meaning Shale and Action, it does not differentiate between
Classic and 2.0. From an outsider standpoint, does 1.3 worth
investment for someone who have not used its nightlies for a year or
so?
One of the reasons for WebWork merger was that WebWork has almost
everything that has been planned for 1.3 and 1.4. What is the point t
continue 1.x development then?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Don Brown <mr...@twdata.org>.
Once Struts Action 2.0 is stable, yes, I'd recommend it for new development. Even now, I'd recommend WebWork 2.2.1 for
new development since migration to Action 2 will be trivial.
Still, I see Action 1.3 living a long, full life even with its older sibling taking the spotlight. Heck, look at how
WebWork 1 is still going strong and it has a small fraction of the user base Struts Action 1 has. I see many more GA
releases to come from the Action 1 branch.
Don
Michael Jouravlev wrote:
> Can I rephrase the above as: "1.3 is a bugfix + some internal surgery
> release for legacy Struts apps in case you want to perform a mild
> refactoring on them"? Can I also assume that you recommend using
> WebWork / 2.0 for new projects? What is your outlook on future of 1.3
> branch after it released as GA?
>
> ---------------------------------------------------------------------
> 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: Reasons for 1.3 release
Posted by Paul Benedict <pa...@yahoo.com>.
Thank you for pointing out previous design flaws ;-)
--- Craig McClanahan <cr...@apache.org> wrote:
> On 2/16/06, Paul Benedict <pa...@yahoo.com> wrote:
> >
> > Martin, you may have to reel back to my first email about this. The
> > context exposes so much of the
> > Struts internal data that it is obvious, to me, that it's not supposed to
> > be an end point
> > processing. What good is having the end point changing the action servlet?
> > Probably no good which
> > is why I am making the case there probably needs to be 2 action contexts.
> > One for the RP, another
> > for the end point. Right now ActionContext exposes toooooooooo much, in my
> > opinion, for a public API.
>
>
> It's not surprising that this pattern creates a bit of cognitive dissonance
> :-), since it is *so* different from the object oriented design approach of
> exposing rigidly controlled interfaces that only "allow" clients to do the
> things you think they need. The problem, when you are trying to support a
> notion of assembling functionality out of very finely grained processing
> units, is that it's *very* hard to predict what the actual clients will
> really want/need to be able to do.
>
> The other thing to note is that essentially everything visible through
> ActionContext is also visible to the execute() method of an Struts 1.0/1.1/1.2
> Action ... it's just a heck of a lot easier to get at :-).
>
> Craig
>
__________________________________________________
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: Reasons for 1.3 release
Posted by Craig McClanahan <cr...@apache.org>.
On 2/16/06, Paul Benedict <pa...@yahoo.com> wrote:
>
> Martin, you may have to reel back to my first email about this. The
> context exposes so much of the
> Struts internal data that it is obvious, to me, that it's not supposed to
> be an end point
> processing. What good is having the end point changing the action servlet?
> Probably no good which
> is why I am making the case there probably needs to be 2 action contexts.
> One for the RP, another
> for the end point. Right now ActionContext exposes toooooooooo much, in my
> opinion, for a public API.
It's not surprising that this pattern creates a bit of cognitive dissonance
:-), since it is *so* different from the object oriented design approach of
exposing rigidly controlled interfaces that only "allow" clients to do the
things you think they need. The problem, when you are trying to support a
notion of assembling functionality out of very finely grained processing
units, is that it's *very* hard to predict what the actual clients will
really want/need to be able to do.
The other thing to note is that essentially everything visible through
ActionContext is also visible to the execute() method of an Struts 1.0/1.1/1.2
Action ... it's just a heck of a lot easier to get at :-).
Craig
Re: Reasons for 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 2/16/06, Paul Benedict <pa...@yahoo.com> wrote:
>Right now ActionContext exposes toooooooooo much, in my opinion, for
a public API.
As mentioned elsewhere, the next step would be to define an "API
object" for the use of Taglibs and other UI technologies. The Velocity
Tools for Struts has already created an API that can do everything the
Struts Taglibs do, and more.
* http://jakarta.apache.org/velocity/tools/
The idea would be that the Action would push the "API object" out to
the response rersource (JSP, Velocity Template), so that the response
resource would not need to know where Struts hides everything.
Everything a UI would need to know would be in the API object. The
concept goes back several years to the "ConfigHelper", but was lost in
the module hullabaloo.
* http://shorl.com/gytulalumuna
Happily, the Velocity gang ran with the idea, and came up with the
Velocity Tools.
But, before starting down the "UI API object" road, we first wanted to
get a numbered build out.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Paul Benedict <pa...@yahoo.com>.
Martin, you may have to reel back to my first email about this. The context exposes so much of the
Struts internal data that it is obvious, to me, that it's not supposed to be an end point
processing. What good is having the end point changing the action servlet? Probably no good which
is why I am making the case there probably needs to be 2 action contexts. One for the RP, another
for the end point. Right now ActionContext exposes toooooooooo much, in my opinion, for a public API.
__________________________________________________
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: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/16/06, Paul Benedict <pa...@yahoo.com> wrote:
>
> >>I think CoR is a great pattern, I've used it with great success, but I'm
> not as sure how it fits into Struts *outside* the composable RP, which is
> a *perfect* application for it. Just curious how you (and/or others) are
> already using it.
>
> This is my opinion too. I think the CoR is made for the Struts internal
> processing only but some
> people are testing it out, as Ted said and Martin admitted to, as an end
> point for action
> processing.
> From my perspective, it's clear what the intention of CoR is by its design
> and use, but since it
> was never explicitly spelled out how it is used in Struts, I have to defer
> to other opinions too.
> But unless I am wrong, I think it's strongly geared towards the RP and not
> actions.
In Struts 1.3, you can do:
<action path="/MyAction"
catalog="MyCatalog"
command="MyCommand"/>
or, if you use the default catalog, as I do for my mappings:
<action path="/MyAction"
command="MyCommand"/>
I'd say that's geared towards actions.
--
Martin Cooper
That's why I said, ActionContext should be InternalActionContext. If Struts
> 1.4+ is going to have
> actions without a subclass or interface, you want a method signature like:
> public void
> execute(ActionContext cxt);
>
> 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: Reasons for 1.3 release
Posted by Paul Benedict <pa...@yahoo.com>.
Am I being unclear? I might be. My focus of complaint is not the CoR but the ActionContext. I say
"thin it out" before exposing it to the end point. That's all. I see others disagree. -- 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: Reasons for 1.3 release
Posted by Ted Husted <te...@gmail.com>.
On 2/16/06, Craig McClanahan <cr...@apache.org> wrote:
> Ted has some good use case examples in his Agility stuff.
Yes, we've been basing our ASPX applications on a port of Commons
Chain for well over a year now. We bind and read the controls to a
Commons Context in the code behind, and execute Commands from a
Catalog as needed. We find that a Chain of Command handles business
logic quite well. A Chain is also a handy way to bind rich controls on
a page, since you can have a command for each control and then add or
remove the commands as the page changes.
The Chain of Command is in no way specific to the request processor.
It's just that the Request Processor is a good use case for a Chain of
Command. It's very much the same idea as the WebWork interceptors. The
next step in that regard would be to let each Action have it's own
request processing chain, instead of insisting there only be one. A
very useful pattern there is to define a pre-opt and post-op chain.
Then, at runtime, create a new chain around the "Action" command:
instant interceptor!
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
Following is a sample implementation of a real CoR pattern. Notice how
different it looks? Notice how data driven it is?
On 2/18/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Dakota Jack wrote:
> > The flexibility is clear. But, from what I can see the pattern is not
> CoR.
>
> Ok, I'll bite... can you explain that?
*JAVA DESIGN PATTERNS*
*Behavioral Patterns - Chain of Responsibility Pattern*
The chain of responsibility pattern is based on the same principle as
written above. It decouples the sender of the request to the receiver. The
only link between sender and the receiver is the request which is sent.
Based on the request data sent, the receiver is picked. This is called
"data-driven". In most of the behavioral patterns, the data-driven concepts
are used to have a loose coupling.
The responsibility of handling the request data is given to any of the
members of the "chain". If the first link of the chain cannot handle the
responsibility, it passes the request data to the next level in the chain,
i.e. to the next link. For readers, familiar with concepts of Java, this is
similar to what happens in an Exception Hierarchy. Suppose the code written
throws an ArrayIndexOutOfBoundsException. Now, this exception is because of
some bug in coding and so, it gets caught at the correct level. Suppose, we
have an application specific exception in the catch block. This will not be
caught by that. It will find for an Exception class and will be caught by
that as both the application specific exceptions and the
ArrayIndexOutOfBoundsException are sub-classes of the class Exception.
Once get caught by the exception, which is the base class, it will then not
look for any other exception. This is precisely the reason why, we get an
"Exception is unreachable" message when we try to add a catch block with the
exception below the parent exception catch block.
So, in short, the request rises in hierarchy till some object takes
responsibility to handle this request.
It's the same mechanism used for multi-level filtration. Suppose, we have a
multi level filter and gravel of different sizes and shapes. We need to
filter this gravel of different sizes to approx size categories. We will put
the gravel on the multi-level filtration unit, with the filter of maximum
size at the top and then the sizes descending. The gravel with the maximum
sizes will stay on the first one and rest will pass, again this cycle will
repeat until, the finest of the gravel is filtered and is collected in the
sill below the filters. Each of the filters will have the sizes of gravel
which cannot pass through it. And hence, we will have approx similar sizes
of gravels grouped.
Let's apply the same example in the form of code.
First, let's talk about the request data. In this case, it is the gravel. We
call it Matter. It has size and quantity. Now, the size determines whether
it matches the size of filter or not and the quantity tells how much matter
is below the size.
*Matter.java*
package bahavioral.chainofresponsibility;
public class Matter { // size of matter
private int size;
// quantity
private int quantity;
/**
* returns the size
*/
public int getSize() {
return size;
}
/**
* sets the size
*/
public void setSize(int size) {
this.size = size;
}
/**
* returns the quantity
*/
public int getQuantity() {
return quantity;
}
/**
* sets the quantity
*/
public void setQuantity(int quantity) {
this.quantity = quantity;
}
}// End of class
The next thing is now the base class. This base class in our case is Sill.
Nothing escapes the Sill. All the matter is collected in the sill.
Everything which cannot be filtered gets collected in the Sill. Like all the
requests which cannot be handled at a lower level rise to higher level and
are handled at the highest level.
*Sill.java*
package bahavioral.chainofresponsibility;
/**
* Sill.java
*
* This is the base class, you can say, which collects everything
* and nothing passes this. Whatever matter is remaining, and is
* still not filtered, is collected here.
*/
public class Sill {
/**
* Method collect.
* Everything is collected here.
*/
public void collect(Matter gravel) {
} }// End of class
And of course, the next class will be the chain. In the example, I have just
created one single class called Filter1. This class extends from the Sill.
And the chain grows on. Every class like Filter2, Filter3 etc extends from
Filter1, Filter2 and so on.
* Filter1.java* package bahavioral.chainofresponsibility;
/**
* This is a filter. This filters out the gravel and
* passes the rest to the next level.
*/
public class Filter1 extends Sill {
private int size;
public Filter1(int size) {
this.size = size;
}
/**
* over-ridden method from base class
*/
public void collect(Matter gravel) { // for the entire quantity of
matter
for(int i = 0; i < gravel.getQuantity(); i++) { // if gravel size is
less than size of filter,
// the gravel will pass to the next level. if(gravel.getSize() <
size) {
super.collect(gravel);
} else {
//collect here. that means, only matter with less
// size will pass...
} } }
}// End of class This is how, this pattern works. Based on principles
of decoupling, the pattern is totally data-driven. The famous example is the
Exception hierarchy.
The other advantage is distribution of responsibilities. There can be such a
scenario when none of the objects in the chain can handle the request. In
this case, the chain will discard the request. The basic object can also be
an interface depending on needs.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
Responses are following <snippets> of your remarks, Frank.
<snip>
Anyone can quote chapter and verse from the GoF book. Can you instead
explain *why* what's in Struts isn't CoR?
</snip>
I assumed you had looked at the code, and in case you had not, encouraged
you to do so and even indicated where the problem was by telling you there
were "Iterations".
<snip>
And, perhaps more
importantly, explain why, even if it isn't an exact match for the
pattern, it matters one bit?
</snip>
If you think that there are "exact" and "inexact" "matches" for patterns, as
if this were something like a pattern for making a dress, then I don't have
much to say. Patterns don't work like that in software development.
<snip>
Would you deny that that the flexibility of the chain approach,
regardless of it's "correctness" as far as pattern implementation goes,
doesn't make Struts better? THAT is what I care about, and likely most
other developers would care about.
</snip>
I in fact said it was flexible. So are POJOs. If you don't care if it is
CoR or not and want to call it "CoR" whether it is or not, go ahead. I
cannot say I would trust a developer much who used basic pattern names
wrong. But, if you are comfortable not understanding what you say or what
you are talking about, you and your "other developer[]" friends can have at
it. I work and live in development communities and we damn sure do care
about being precise and knowing what we talk about.
<snip>
I'm not writing my thesis on why or
why not Struts implements this pattern or that pattern as advertised,
I'm interested in whether it makes my life better, and I for one am
convinced the chain approach does. If you disagree, that's fine, I
would like to hear why, but with specifics, not by quoting a theoretical
abstraction.
</snip>
If you have decided that the GoF book is a "theoretical abstraction", then
you and I probably have very little to discuss. If you don't care if it is
CoR or not, I have no idea why you responded to the note that it is not,
which it is not. If you think understanding and employing design patterns
in a wise way is an academic "thesis" matter, then you are running in a very
different development crowd than I am. If you said anything like that where
I work, they would be shocked. We don't write theses around here. We write
code. Good code and we know what patterns we are using.
Actually, the reason Struts has to be tossed is just because it is a mess in
regard to the flexibility and the use of deep level design patterns. Maybe
it is easy to use, but so are lots of bad ideas. Had Struts used a Strategy
pattern instead of whatever that is that they have now, it might have had a
chance to use AOP, and other cook features that this code won't help. It is
easy to code, that is true. It is flexible as hell in the sense that anyone
with any sense can code it and it is easy to change in the concrete
classes. There are much deeper problems which it not only does not address
but exascerbates.
Why don't you look at the code and see where there is iteration? I don't
think I should have to go to the code and show you. If you insist you don't
want to even look at the code and still defend it, then that's your
perogative.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
Why don't you guys just look at the code? It is fairly simple and
straightforward.
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.
>
> If I understand correctly, in CoR pattern a client calls the chain
> head and "the request propagates along the chain until a
> ConcreteHandler object takes responsibility for handling it." (GoF)
>
> In Struts Classic prior to 1.3 a client calls a concrete action (which
> is why I consider Struts Classic to *not* be an implementation of
> Front Controller pattern). It is possible to stick additional
> processing before the action class is called. Though it is not as easy
> as in WebWork, it is possible. So, Struts Classic implements
> Interceptor pattern, not Chain of Responsibility.
>
> So, how the whole thing works in 1.3? A client still calls a
> particular mapping like in older Struts versions, right? Does this
> mapping define a head of chain (CoR) or an end of chain
> (interceptors)? If it defines the head of chain, is it still possible
> to sneak interceptors into an arbitrary chain?
>
> Michael.
>
> ---------------------------------------------------------------------
> 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."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by Craig McClanahan <cr...@apache.org>.
On 2/21/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 2/19/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > > In Struts Classic prior to 1.3 a client calls a concrete action (which
> > > is why I consider Struts Classic to *not* be an implementation of
> > > Front Controller pattern).
> >
> > Almost, but not quite ... there was always processng going on before and
> > after the call to the action, and you couldn't bypass it except where
> Struts
> > allowed you to explictly configure bypassing it (like turning off
> > validation). For someone who doesn't use form beans (like you, Michael?
> :-)
> > there isn't a lot actually done there, but it does exist.
>
> I know that I cannot bypass it. And I think it sucks big time. This is
> the ultimate flaw of Struts. I value the framework, it does job for
> me. But let me push the buttons, switch the levers and pull the
> strings, ok? I appreciate, for example, a chunk of code that populates
> form bean from the request. But let me call populate() myself. I
> appreciate validator, but let me call validate() myself (this I can
> do, thank you). It is not a big deal for me to write couple of lines
> of code, but the code looks simpler, I can immediately see what
> happens without looking into deployment descriptor... I mean, into
> struts-config.xml.
>
> I do use form beans. I use them in session scope.
>
> > The primary change in 1.3 is to re-implement the standard request
> processor
> > pipeline as a chain instead of a monolithic single class (in other
> words,
> > promoting the sandbox CoR implementation into the mainstream). So, the
> use
> > of a chain is just an *implementation detail* that does not change the
> > "Front Controller" nature of the original framework. But it's now much
> > easier to customize the framework's behavior for all requests, by
> adjusting
> > the definition of the standard chain and/or utilizing optional call-outs
> to
> > applicaton defined chains.
> >
> > The next step would be to provide customizable chains per Action
> (becoming
> > even more like how you configure actions in WebWork) -- but you can even
> do
> > that today by using an Action that itself executed a chain.
>
> Why is it always like this? Either everything is done for me (and I
> can do little about changing what's happening), or it is super-duper
> configurable system? I do not need super-duper. There comes request
> with arguments. There is my action (or command, or chain, does not
> matter) which is *an endpoint of the request*, because this is how it
> is defined in struts-config.xml file. Great. Now just call this
> endpoint, and provide me with dozen or so lifecycle methods, that I
> can call myself. This would be so much easier than bolting on the
> whole CoR pattern and then customizing it.
I would suggest that your preferred approach is certainly legitimate, but is
*not* the most common set of preferences. Indeed, things like dependency
injection are popular, at least in part, because they do *not* require
"lifecycle methods that I can call myself" ... instead, many people *like*
an environment where the framework employs the Hollywood Principle (don't
call us, we'll call you).
Is it possible to have something both extremely simple *and* extremely
> flexible?
It sounds like you might want to forgo frameworks completely, like Simon
Brown is blogging about on java.net :-). Pure servlets and JSP anyone
(perhaps with filters thrown in for extra spice)?
Or, if you want an itsy bitsy bit of structure, you could think about
starting from something like ChainServlet (part of Commons Chain), and
implement a service() method that mapped from an incoming URL to the name of
a chain to execute. About 5 lines of code, and TOTAL control over what
happens for each individual request, because you can compose the chain for
each request individually ... or share them when you have common
requirements.
You could do something similar with almost any favorite paradigm for mapping
incoming requests to the corresponding processing logic -- but if frameworks
get in your way, why in the heck are you using them in the first place?
Guess this is just a Tuesday rant...
>
> Michael.
Craig
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Reasons for 1.3 release
Posted by Craig McClanahan <cr...@apache.org>.
On 2/19/06, Martin Cooper <ma...@apache.org> wrote:
>
> On 2/19/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >
> > Does "MyCommand" represent a chain in MyCatalog?
>
>
> Yep.
>
> If so, while I
> > wouldn't presume to speak for Craig, it sure seems like it :) I've
> > personally used the "fire a chain from an Action" in the past, but I can
> > certainly see where this would be very nice.
>
>
> 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.
What you describe is indeed possible today, but it has a subtle difference
in implementation requirements:
* What you can do today -- implement your Action logic as a command,
and build a customized chain that includes it. (That's what you have
described as your current solution, so you won't have any migration
issues.)
* What would be nice for migrating 1.2 apps -- support some mechanism
to customize a per-Action chain that included calling the Action.execute()
method so it does not need to be re-implemented.
The latter would let you take an existing app and later decorate individual
actions (just like WebWork lets you add intercepters) without requiring any
change to the initial implementation of the Action itself. That's not the
way I would ever write a new app based on Action 1.3, but it'd sure help
migrating users.
--
> Martin Cooper
Craig
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
The pattern is NOT CoR. Does anyone look at the code? How do you code
without knowing what is going on at the foundations of this design?
<snip>
On 2/20/06, Paul Benedict <pa...@yahoo.com> wrote:
>
> You want
> to be able to plug into the request processor, which is a CoR pattern,
</snip>
I guess this is like the Bush approach. Repeat a lie enough times and the hoi
polloi will buy it hook line and sinker. If I am wrong, I am wrong, but I
am looking at the code and it is NOT a CoR pattern. It is merely a bunch of
procedural based code out of commons chain iterating away.
I assume that you mean the ComposableRequestProcessor and not the
RequestProcessor in 1.3. Neither are CoR. But, if you think that the
RequestProcessor in 1.3 is CoR there is not much hope. The
ComposableRequestProcessor, once again, merely implements chain in commons
and I should that code before. Here it is all once again:
ComposableRequestProcessor:
public void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Create and populate a Context for this request
ServletWebContext context = new ServletWebContext();
context.initialize(getServletContext(), request, response);
context.getAttributes().put("catalog", this.catalog);
context.getAttributes().put(Constants.MODULE_CONFIG_KEY,
this.moduleConfig);
// Create and execute the command.
Command command = this.catalog.getCommand("servlet-standard");
try {
command.execute(context);
} catch (Exception e) {
// Execute the exception processing chain??
throw new ServletException(e);
}
// Release the context.
context.release();
}
ChainBase:
public boolean execute(Context context) throws Exception {
// Verify our parameters
if (context == null) {
throw new IllegalArgumentException();
}
// Freeze the configuration of the command list
frozen = true;
// Execute the commands in this list until one returns true
// or throws an exception
boolean saveResult = false;
Exception saveException = null;
int i = 0;
int n = commands.length;;
for (i = 0; i < n; i++) {
try {
saveResult = commands[i].execute(context);
if (saveResult) {
break;
}
} catch (Exception e) {
saveException = e;
break;
}
}
// Call postprocess methods on Filters in reverse order
if (i >= n) { // Fell off the end of the chain
i--;
}
boolean handled = false;
boolean result = false;
for (int j = i; j >= 0; j--) {
if (commands[j] instanceof Filter) {
try {
result =
((Filter) commands[j]).postprocess(context,
saveException);
if (result) {
handled = true;
}
} catch (Exception e) {
; // Silently ignore
}
}
}
// Return the exception or result state from the last execute()
if ((saveException != null) && !handled) {
throw saveException;
} else {
return (saveResult);
}
}
RequestProcessor
public void process(HttpServletRequest request,
HttpServletResponse response)
throws IOException, ServletException {
// Wrap multipart requests with a special wrapper
request = processMultipart(request);
// Identify the path component we will use to select a mapping
String path = processPath(request, response);
if (path == null) {
return;
}
if (getDebug() >= 1) {
log("Processing a '" + request.getMethod() +
"' for path '" + path + "'");
}
// Select a Locale for the current user if requested
processLocale(request, response);
// Set the content type and no-caching headers if requested
processContent(request, response);
processNoCache(request, response);
// General purpose preprocessing hook
if (!processPreprocess(request, response)) {
return;
}
// Identify the mapping for this request
ActionMapping mapping = processMapping(request, response, path);
if (mapping == null) {
return;
}
// Check for any role required to perform this action
if (!processRoles(request, response, mapping)) {
return;
}
// Process any ActionForm bean related to this request
ActionForm form = processActionForm(request, response, mapping);
processPopulate(request, response, form, mapping);
if (!processValidate(request, response, form, mapping)) {
return;
}
// Process a forward or include specified by this mapping
if (!processForward(request, response, mapping)) {
return;
}
if (!processInclude(request, response, mapping)) {
return;
}
// Create or acquire the Action instance to process this request
Action action = processActionCreate(request, response, mapping);
if (action == null) {
return;
}
// Call the Action instance itself
ActionForward forward =
processActionPerform(request, response,
action, form, mapping);
// Process the returned ActionForward instance
processActionForward(request, response, forward);
}
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/20/06, Paul Benedict <pa...@yahoo.com> 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, then it's pretty foolhardy to
> call it the "action
> framework"? Call it the chain framework, but that sounds pretty lousy ;-)
As Joe has explained, the Action in Struts Action Framework does not relate
to the way the framework is implemented, but to the way in which it is
designed.
Paul, I would really recommend that you spend some time in the mailing list
archives. Virtually all of the points you've been bringing up recently were
discussed to death on the list several months ago, so you'll find lots of
explanatory material in there.
--
Martin Cooper
And this goes back to the heart of my problem with Struts 1.3 vs. WebWork
> vs. Struts 2.0. You want
> to be able to plug into the request processor, which is a CoR pattern, but
> not directly connect
> the request processor to business logic. If you want to do chains for your
> business logic, they
> should begin in an action.
>
> I think the whole <action chain=""> is good since you can customize the
> end of the request
> processor, so to speak, but I believe an action MUST be mandatory. It
> should be bad programming
> practice not to have an Action which is the end point of each request --
> or it is NOT the action
> framework anymore. Call it the "historical action framework" or the "chain
> framework" to match the
> visionaries of the framework. You guys are the commiters, so if you are
> not going to use actions,
> then the name does not represent the intentions of the thought leaders of
> this project, and the
> product's final destination.
>
> 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: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
This may be slightly OT, but not entirely...
I would like to suggest a change to what is being done in 1.3...
As I've mentioned before, I have a CoR implementation in JWP... I wrote
my own because Commons Chain didn't have some features I needed for a
project I was working on, and while I'm sure I could have modified it to
have those, it seemed easier to just write my own (and it was pretty
easy, so it worked out well). One of the decisions I made is that I
wanted to have a distinction between a Command and a Chain. I didn't
want a Chain=Command and Command=Chain as I believe is the case in
Commons Chain, right?
With that in mind, I'd like to see Struts have *two* attributes on the
Action mapping, "command" and "chain". Or alternatively, simply replace
"command" with "chain". In this way, people could make a declarative
distinction between the case where they are replacing an Action with a
Command, and the case where they are firing off a Chain in place of an
Action. More importantly, either change makes it clear what you are
actually executing. 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).
One of the things that people complain about with Struts is that some of
the config attributes don't really make much sense naming-wise... I
believe this may be a continuation of that complaint.
What are everyones' thoughts on this? I'd be happy to open a ticket and
submit patches, if there is any agreement.
Frank
Martin Cooper wrote:
> On 2/19/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> Does "MyCommand" represent a chain in MyCatalog?
>
>
> Yep.
>
> If so, while I
>> wouldn't presume to speak for Craig, it sure seems like it :) I've
>> personally used the "fire a chain from an Action" in the past, but I can
>> certainly see where this would be very nice.
>
>
> 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.
>
> --
> Martin Cooper
>
>
> Frank
>> Martin Cooper wrote:
>>> On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
>>> <snip/>
>>>
>>> The next step would be to provide customizable chains per Action
>> (becoming
>>>> even more like how you configure actions in WebWork) -- but you can
>> even
>>>> do
>>>> that today by using an Action that itself executed a chain.
>>>
>>> Craig, isn't that what we already have with:
>>>
>>>
>>> <action path="/MyAction"
>>> catalog="MyCatalog"
>>> command="MyCommand"/>
>>>
>>> or am I misunderstanding?
>>>
>>> --
>>> Martin Cooper
>>>
>>>
>>> Michael.
>>>> Craig
>>>>
>>>>
>> ---------------------------------------------------------------------
>> 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: Reasons for 1.3 release
Posted by Joe Germuska <Jo...@Germuska.com>.
At 5:48 AM -0800 2/20/06, Paul Benedict 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, then it's pretty
>foolhardy to call it the "action
>framework"? Call it the chain framework, but that sounds pretty lousy ;-)
"Action" refers more to a style of development and organization than
to a specific class. "Action" describes the fact that the
organizational focus is on coding request handling paths as opposed
to wiring together components and events (as in Shale).
Joe
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Paul Benedict <pa...@yahoo.com>.
>>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, then it's pretty foolhardy to call it the "action
framework"? Call it the chain framework, but that sounds pretty lousy ;-)
And this goes back to the heart of my problem with Struts 1.3 vs. WebWork vs. Struts 2.0. You want
to be able to plug into the request processor, which is a CoR pattern, but not directly connect
the request processor to business logic. If you want to do chains for your business logic, they
should begin in an action.
I think the whole <action chain=""> is good since you can customize the end of the request
processor, so to speak, but I believe an action MUST be mandatory. It should be bad programming
practice not to have an Action which is the end point of each request -- or it is NOT the action
framework anymore. Call it the "historical action framework" or the "chain framework" to match the
visionaries of the framework. You guys are the commiters, so if you are not going to use actions,
then the name does not represent the intentions of the thought leaders of this project, and the
product's final destination.
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: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/19/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Does "MyCommand" represent a chain in MyCatalog?
Yep.
If so, while I
> wouldn't presume to speak for Craig, it sure seems like it :) I've
> personally used the "fire a chain from an Action" in the past, but I can
> certainly see where this would be very nice.
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.
--
Martin Cooper
Frank
>
> Martin Cooper wrote:
> > On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
> > <snip/>
> >
> > The next step would be to provide customizable chains per Action
> (becoming
> >> even more like how you configure actions in WebWork) -- but you can
> even
> >> do
> >> that today by using an Action that itself executed a chain.
> >
> >
> > Craig, isn't that what we already have with:
> >
> >
> > <action path="/MyAction"
> > catalog="MyCatalog"
> > command="MyCommand"/>
> >
> > or am I misunderstanding?
> >
> > --
> > Martin Cooper
> >
> >
> > Michael.
> >>
> >> Craig
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
Here is the ChainBase execute method, gentlemen. If you think that is CoR,
then I have nothing further to say. This is the real "pattern". It is not
even OOP. It merely uses a class as a repository to do C coding.
// Documented in Chain interface
public boolean execute(Context context) throws Exception {
// Verify our parameters
if (context == null) {
throw new IllegalArgumentException();
}
// Freeze the configuration of the command list
frozen = true;
// Execute the commands in this list until one returns true
// or throws an exception
boolean saveResult = false;
Exception saveException = null;
int i = 0;
int n = commands.length;;
for (i = 0; i < n; i++) {
try {
saveResult = commands[i].execute(context);
if (saveResult) {
break;
}
} catch (Exception e) {
saveException = e;
break;
}
}
// Call postprocess methods on Filters in reverse order
if (i >= n) { // Fell off the end of the chain
i--;
}
boolean handled = false;
boolean result = false;
for (int j = i; j >= 0; j--) {
if (commands[j] instanceof Filter) {
try {
result =
((Filter) commands[j]).postprocess(context,
saveException);
if (result) {
handled = true;
}
} catch (Exception e) {
; // Silently ignore
}
}
}
// Return the exception or result state from the last execute()
if ((saveException != null) && !handled) {
throw saveException;
} else {
return (saveResult);
}
}
On 2/19/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Does "MyCommand" represent a chain in MyCatalog? If so, while I
> wouldn't presume to speak for Craig, it sure seems like it :) I've
> personally used the "fire a chain from an Action" in the past, but I can
> certainly see where this would be very nice.
>
> Frank
>
> Martin Cooper wrote:
> > On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
> > <snip/>
> >
> > The next step would be to provide customizable chains per Action
> (becoming
> >> even more like how you configure actions in WebWork) -- but you can
> even
> >> do
> >> that today by using an Action that itself executed a chain.
> >
> >
> > Craig, isn't that what we already have with:
> >
> >
> > <action path="/MyAction"
> > catalog="MyCatalog"
> > command="MyCommand"/>
> >
> > or am I misunderstanding?
> >
> > --
> > Martin Cooper
> >
> >
> > Michael.
> >>
> >> Craig
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> 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."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Does "MyCommand" represent a chain in MyCatalog? If so, while I
wouldn't presume to speak for Craig, it sure seems like it :) I've
personally used the "fire a chain from an Action" in the past, but I can
certainly see where this would be very nice.
Frank
Martin Cooper wrote:
> On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
> <snip/>
>
> The next step would be to provide customizable chains per Action (becoming
>> even more like how you configure actions in WebWork) -- but you can even
>> do
>> that today by using an Action that itself executed a chain.
>
>
> Craig, isn't that what we already have with:
>
>
> <action path="/MyAction"
> catalog="MyCatalog"
> command="MyCommand"/>
>
> or am I misunderstanding?
>
> --
> Martin Cooper
>
>
> Michael.
>>
>> Craig
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
<snip/>
The next step would be to provide customizable chains per Action (becoming
> even more like how you configure actions in WebWork) -- but you can even
> do
> that today by using an Action that itself executed a chain.
Craig, isn't that what we already have with:
<action path="/MyAction"
catalog="MyCatalog"
command="MyCommand"/>
or am I misunderstanding?
--
Martin Cooper
Michael.
>
>
> Craig
>
>
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
<snip>
On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> >
> > If I understand correctly, in CoR pattern a client calls the chain
> > head and "the request propagates along the chain until a
> > ConcreteHandler object takes responsibility for handling it." (GoF)
>
>
> That's the most important sentence in the GoF description ... and the one
> that motivated the API design for a Comman in Commons Chain.
>
> </snip>
Craig is sure right that this is the most important sentence. It is the one
that keeps each link in the chain ignorant of the rest. Now, go look at
ChainBase in commons and you will see that this is NOT the API design in
commons chain. The Command, hopefully, but NOT, would be part of a command
pattern. ChainBase, NOT Command, hopefully, but NOT, would be part of a
chain pattern.
--
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
On 2/19/06, Craig McClanahan <cr...@apache.org> wrote:
> On 2/19/06, Michael Jouravlev <jm...@gmail.com> wrote:
> > In Struts Classic prior to 1.3 a client calls a concrete action (which
> > is why I consider Struts Classic to *not* be an implementation of
> > Front Controller pattern).
>
> Almost, but not quite ... there was always processng going on before and
> after the call to the action, and you couldn't bypass it except where Struts
> allowed you to explictly configure bypassing it (like turning off
> validation). For someone who doesn't use form beans (like you, Michael? :-)
> there isn't a lot actually done there, but it does exist.
I know that I cannot bypass it. And I think it sucks big time. This is
the ultimate flaw of Struts. I value the framework, it does job for
me. But let me push the buttons, switch the levers and pull the
strings, ok? I appreciate, for example, a chunk of code that populates
form bean from the request. But let me call populate() myself. I
appreciate validator, but let me call validate() myself (this I can
do, thank you). It is not a big deal for me to write couple of lines
of code, but the code looks simpler, I can immediately see what
happens without looking into deployment descriptor... I mean, into
struts-config.xml.
I do use form beans. I use them in session scope.
> The primary change in 1.3 is to re-implement the standard request processor
> pipeline as a chain instead of a monolithic single class (in other words,
> promoting the sandbox CoR implementation into the mainstream). So, the use
> of a chain is just an *implementation detail* that does not change the
> "Front Controller" nature of the original framework. But it's now much
> easier to customize the framework's behavior for all requests, by adjusting
> the definition of the standard chain and/or utilizing optional call-outs to
> applicaton defined chains.
>
> The next step would be to provide customizable chains per Action (becoming
> even more like how you configure actions in WebWork) -- but you can even do
> that today by using an Action that itself executed a chain.
Why is it always like this? Either everything is done for me (and I
can do little about changing what's happening), or it is super-duper
configurable system? I do not need super-duper. There comes request
with arguments. There is my action (or command, or chain, does not
matter) which is *an endpoint of the request*, because this is how it
is defined in struts-config.xml file. Great. Now just call this
endpoint, and provide me with dozen or so lifecycle methods, that I
can call myself. This would be so much easier than bolting on the
whole CoR pattern and then customizing it.
Is it possible to have something both extremely simple *and* extremely flexible?
Guess this is just a Tuesday rant...
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Craig McClanahan <cr...@apache.org>.
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.
>
> If I understand correctly, in CoR pattern a client calls the chain
> head and "the request propagates along the chain until a
> ConcreteHandler object takes responsibility for handling it." (GoF)
That's the most important sentence in the GoF description ... and the one
that motivated the API design for a Comman in Commons Chain.
In Struts Classic prior to 1.3 a client calls a concrete action (which
> is why I consider Struts Classic to *not* be an implementation of
> Front Controller pattern).
Almost, but not quite ... there was always processng going on before and
after the call to the action, and you couldn't bypass it except where Struts
allowed you to explictly configure bypassing it (like turning off
validation). For someone who doesn't use form beans (like you, Michael? :-)
there isn't a lot actually done there, but it does exist.
It is possible to stick additional
> processing before the action class is called. Though it is not as easy
> as in WebWork, it is possible. So, Struts Classic implements
> Interceptor pattern, not Chain of Responsibility.
The standard versions of Struts before 1.3 indeed do not use CoR (although
you could use a CoR based implementation of RequestProcessor from the
sandbox in 1.2.x).
So, how the whole thing works in 1.3? A client still calls a
> particular mapping like in older Struts versions, right? Does this
> mapping define a head of chain (CoR) or an end of chain
> (interceptors)? If it defines the head of chain, is it still possible
> to sneak interceptors into an arbitrary chain?
The primary change in 1.3 is to re-implement the standard request processor
pipeline as a chain instead of a monolithic single class (in other words,
promoting the sandbox CoR implementation into the mainstream). So, the use
of a chain is just an *implementation detail* that does not change the
"Front Controller" nature of the original framework. But it's now much
easier to customize the framework's behavior for all requests, by adjusting
the definition of the standard chain and/or utilizing optional call-outs to
applicaton defined chains.
The next step would be to provide customizable chains per Action (becoming
even more like how you configure actions in WebWork) -- but you can even do
that today by using an Action that itself executed a chain.
Michael.
Craig
Re: Reasons for 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
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.
If I understand correctly, in CoR pattern a client calls the chain
head and "the request propagates along the chain until a
ConcreteHandler object takes responsibility for handling it." (GoF)
In Struts Classic prior to 1.3 a client calls a concrete action (which
is why I consider Struts Classic to *not* be an implementation of
Front Controller pattern). It is possible to stick additional
processing before the action class is called. Though it is not as easy
as in WebWork, it is possible. So, Struts Classic implements
Interceptor pattern, not Chain of Responsibility.
So, how the whole thing works in 1.3? A client still calls a
particular mapping like in older Struts versions, right? Does this
mapping define a head of chain (CoR) or an end of chain
(interceptors)? If it defines the head of chain, is it still possible
to sneak interceptors into an arbitrary chain?
Michael.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
? I am not interested in
> "hooking" anyone, by the way, and so you don't need to "bite". I guess
> saying you'll "bite" is like saying I am "fishing" for bullshit. That is not
> true.
Isn't it interesting how you always managed to read into comments like
that some derisive connotation? I was simply saying I was interested in
your conjecture, nothing more. Is there some Freudian realization going
on there I wonder?
> Anyway, the actual design goes as follows. Please notice that none
> of the iterations in Struts CoR are present, for good reason.
>
> Chain of Responsibility
-snip-
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?
Would you deny that that the flexibility of the chain approach,
regardless of it's "correctness" as far as pattern implementation goes,
doesn't make Struts better? THAT is what I care about, and likely most
other developers would care about. I'm not writing my thesis on why or
why not Struts implements this pattern or that pattern as advertised,
I'm interested in whether it makes my life better, and I for one am
convinced the chain approach does. If you disagree, that's fine, I
would like to hear why, but with specifics, not by quoting a theoretical
abstraction.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
Have you looked at the actual code? And have you looked at what a CoR
pattern is? The actual code is not a CoR pattern. I am not interested in
"hooking" anyone, by the way, and so you don't need to "bite". I guess
saying you'll "bite" is like saying I am "fishing" for bullshit. That is not
true. Anyway, the actual design goes as follows. Please notice that none
of the iterations in Struts CoR are present, for good reason.
Chain of Responsibility
Avoid coupling the sender of a request to its receiver by giving more than
one object a chance to handle the request. Chain the receiving objects and
pass the request along the chain until an object handles it.
There is a potentially variable number of "handler" objects and a stream of
requests that must be handled. Need to efficiently process the requests
without hard-wiring handler relationships and precedence, or
request-to-handler mappings.
The pattern chains the receiving objects together, and then passes any
request messages from object to object until it reaches an object capable of
handling the message. The number and type of handler objects isn't known a
priori, they can be configured dynamically. The chaining mechanism uses
recursive composition to allow an unlimited number of handlers to be linked.
Chain of Responsibility simplifies object interconnections. Instead of
senders and receivers maintaining references to all candidate receivers,
each sender keeps a single reference to the head of the chain, and each
receiver keeps a single reference to its immediate successor in the chain.
Make sure there exists a "safety net" to "catch" any requests which go
unhandled.
Do not use Chain of Responsibility when each request is only handled by one
handler, or, when the client object knows which service object should handle
the request. [
http://www.cs.huji.ac.il/labs/parallel/Docs/C++/DesignPatterns/chain.html.]
The Chain of Responsibility pattern avoids coupling the sender of a request
to the receiver by giving more than one object a chance to handle the
request. Mechanical coin sorting banks use the Chain of Responsibility.
Rather than having a separate slot for each coin denomination coupled with a
receptacle for the denomination, a single slot is used. When the coin is
dropped, the coin is routed to the appropriate receptacle by the mechanical
mechanisms within the bank. [Michael Duell, "Non-software examples of
software design patterns", Object Magazine, Jul 97, p54]
Chain of Responsibility, Command, Mediator, and Observer, address how you
can decouple senders and receivers, but with different trade-offs. Chain of
Responsibility passes a sender request along a chain of potential receivers.
Chain of Responsibility can use Command to represent requests as objects.
[GOF, p349]
Chain of Responsibility is often applied in conjunction with Composite.
There, a component's parent can act as its successor. [GOF, p232]
---------------------------------------------------------------------------------------------
On 2/18/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Dakota Jack wrote:
> > The flexibility is clear. But, from what I can see the pattern is not
> CoR.
>
> Ok, I'll bite... can you explain that?
>
> Frank
>
> > On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
> >> Craig McClanahan wrote:
> >>> This pattern, of course, can be used today in a Struts 1.x action ...
> or
> >> in
> >>> the "action" equivalent of any other framework too (JSF, WebWork,
> >>> whatever). And, it's not even web specific ... you can design your
> >> whole
> >>> business logic layer out of chains.
> >> Having done this recently in a behavioral analysis application that was
> >> not web-based, I know exactly what your saying. I can't tell you how
> >> thrilled the business was in a meeting a few weeks ago when they said
> >> "well, what happens when we want to add a rule between C and D in this
> >> processing flow" and I was able to do it in about 1 minute right before
> >> their eyes. They flipped! CoR makes that flexibility very easy to do.
> >>
> >>> Craig
> >> Frank
> >>
> >> ---------------------------------------------------------------------
> >> 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."
> > ~Dakota Jack~
> >
>
> ---------------------------------------------------------------------
> 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."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Dakota Jack wrote:
> The flexibility is clear. But, from what I can see the pattern is not CoR.
Ok, I'll bite... can you explain that?
Frank
> On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>> Craig McClanahan wrote:
>>> This pattern, of course, can be used today in a Struts 1.x action ... or
>> in
>>> the "action" equivalent of any other framework too (JSF, WebWork,
>>> whatever). And, it's not even web specific ... you can design your
>> whole
>>> business logic layer out of chains.
>> Having done this recently in a behavioral analysis application that was
>> not web-based, I know exactly what your saying. I can't tell you how
>> thrilled the business was in a meeting a few weeks ago when they said
>> "well, what happens when we want to add a rule between C and D in this
>> processing flow" and I was able to do it in about 1 minute right before
>> their eyes. They flipped! CoR makes that flexibility very easy to do.
>>
>>> Craig
>> Frank
>>
>> ---------------------------------------------------------------------
>> 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."
> ~Dakota Jack~
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Dakota Jack <da...@gmail.com>.
The flexibility is clear. But, from what I can see the pattern is not CoR.
On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Craig McClanahan wrote:
> > This pattern, of course, can be used today in a Struts 1.x action ... or
> in
> > the "action" equivalent of any other framework too (JSF, WebWork,
> > whatever). And, it's not even web specific ... you can design your
> whole
> > business logic layer out of chains.
>
> Having done this recently in a behavioral analysis application that was
> not web-based, I know exactly what your saying. I can't tell you how
> thrilled the business was in a meeting a few weeks ago when they said
> "well, what happens when we want to add a rule between C and D in this
> processing flow" and I was able to do it in about 1 minute right before
> their eyes. They flipped! CoR makes that flexibility very easy to do.
>
> > Craig
>
> Frank
>
> ---------------------------------------------------------------------
> 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."
~Dakota Jack~
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> This pattern, of course, can be used today in a Struts 1.x action ... or in
> the "action" equivalent of any other framework too (JSF, WebWork,
> whatever). And, it's not even web specific ... you can design your whole
> business logic layer out of chains.
Having done this recently in a behavioral analysis application that was
not web-based, I know exactly what your saying. I can't tell you how
thrilled the business was in a meeting a few weeks ago when they said
"well, what happens when we want to add a rule between C and D in this
processing flow" and I was able to do it in about 1 minute right before
their eyes. They flipped! CoR makes that flexibility very easy to do.
> Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Craig McClanahan <cr...@apache.org>.
On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
>
> I think CoR is a great pattern, I've used it with great success, but I'm
> not as sure how it fits into Struts *outside* the composable RP, which is
> a *perfect* application for it. Just curious how you (and/or others) are
> already using it.
Ted has some good use case examples in his Agility stuff. One simple
scenario is where you want to reuse fine grained commands that allocate
resources, without the actual processing logic having to know where it came
from (and you're not using a dependency injection framework).
Consider a Filter (in the Commons Chain sense, a Command that gets control
on the way in and on the way out) that "injects" a JDBC Connection (or a
Hibernate session, or whatever) into the Context object. You'd do that part
in the execute() method, then clean up in postprocess() on the way back
out. This would be configured into a chain in front of the particular
Command that actually performs your business logic -- and its reusable for
all commands that need a Connection handed to them. Need some more
resources? Add some more fine grained reusable decoarator commands to
allocate and release them.
This pattern, of course, can be used today in a Struts 1.x action ... or in
the "action" equivalent of any other framework too (JSF, WebWork,
whatever). And, it's not even web specific ... you can design your whole
business logic layer out of chains.
Craig
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Good point Joe! :)
Frank
Joe Germuska wrote:
> At 12:16 AM -0500 2/17/06, Frank W. Zammetti wrote:
>> Martin Cooper wrote:
>>> Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps,
>>> primarily
>>> for stuff that needs to be centralised, such as authorisation, error /
>>> exception handling, and some specialised cancellation handling.
>>
>> This part is especially interesting because it leads me to a question
>> that may come up as CoR becomes more well-known in Struts land... why
>> is a composable RP better than a collection of filters?
>
> Because it's backwards compatible with Struts 1.2 and can be invisible
> to most users. You couldn't possibly use servlet filters instead of the
> chain without at least requiring those upgrading to Struts 1.3 to learn
> the new way to configure their web.xml.
>
> Joe
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Joe Germuska <Jo...@Germuska.com>.
At 12:16 AM -0500 2/17/06, Frank W. Zammetti wrote:
>Martin Cooper wrote:
>>Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps, primarily
>>for stuff that needs to be centralised, such as authorisation, error /
>>exception handling, and some specialised cancellation handling.
>
>This part is especially interesting because it leads me to a
>question that may come up as CoR becomes more well-known in Struts
>land... why is a composable RP better than a collection of filters?
Because it's backwards compatible with Struts 1.2 and can be
invisible to most users. You couldn't possibly use servlet filters
instead of the chain without at least requiring those upgrading to
Struts 1.3 to learn the new way to configure their web.xml.
Joe
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Craig McClanahan wrote:
> It is a little simpler to use than filters (the programming interface for a
> command is a *lot* simpler than for a Filter), and a bit easier to configure
> as well.
Certainly an easier interface, although I'm not as sure about
configuration... although you get more *flexibility* with chains
(catalogs, subchains, dynamic flow alteration, looping, etc), so even if
filters are simpler to configure, chains are certainly more flexible,
which makes up for it.
> But the primary reason for a CoR based request processor (RP) is
> to get rid of the restrictions of an RP implemented as a single class, where
> the mechanism for specialization is a subclass. Java's single inheritance
> makes it really difficult to combine more than one specialized subclass of
> RequestProcessor into a single app.
No argument there... but the same could be said of filters :) It would
give you the same result as far as the RP goes.
> If you already grok filters, go for it. But I can see a day coming where
> even more people are going to bitch about having to edit web.xml files to
> set up all the filter mappings :-).
I've done both filters and chains pretty extensively at this point...
I'm not sure why anyone would bitch any more about having to edit
web.xml vs. chain-config.xml :) Seems pretty comparable to me, and
arguably since everyone in the world (but me!) uses an IDE, and since
most of them these days have fancy little web.xml editors built-in, one
could argue it's even easier.
I probably lean towards chains myself based on nothing more than the
added flexibility they give you. In any case, I was just asking a
question for the sake of discussion, that's all. I'm sold on chains in
general anyway :)
> Craig
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Craig McClanahan <cr...@apache.org>.
On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Martin Cooper wrote:
> > Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps,
> primarily
> > for stuff that needs to be centralised, such as authorisation, error /
> > exception handling, and some specialised cancellation handling.
>
> This part is especially interesting because it leads me to a question
> that may come up as CoR becomes more well-known in Struts land... why is
> a composable RP better than a collection of filters?
It is a little simpler to use than filters (the programming interface for a
command is a *lot* simpler than for a Filter), and a bit easier to configure
as well. But the primary reason for a CoR based request processor (RP) is
to get rid of the restrictions of an RP implemented as a single class, where
the mechanism for specialization is a subclass. Java's single inheritance
makes it really difficult to combine more than one specialized subclass of
RequestProcessor into a single app.
It's essentially
> the same thing, except that you could probably say you have more control
> over your own chain. Why would something like security for instance be
> better implemented as a modified RP chain than some loosely-coupled
> filters? I ask this partly because we have a complex security framework
> at work that takes the filter approach, although it could just as easily
> be done in the app framework itself. Any thoughts?
If you already grok filters, go for it. But I can see a day coming where
even more people are going to bitch about having to edit web.xml files to
set up all the filter mappings :-).
Frank
Craig
Re: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin Cooper wrote:
> Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps, primarily
> for stuff that needs to be centralised, such as authorisation, error /
> exception handling, and some specialised cancellation handling.
This part is especially interesting because it leads me to a question
that may come up as CoR becomes more well-known in Struts land... why is
a composable RP better than a collection of filters? It's essentially
the same thing, except that you could probably say you have more control
over your own chain. Why would something like security for instance be
better implemented as a modified RP chain than some loosely-coupled
filters? I ask this partly because we have a complex security framework
at work that takes the filter approach, although it could just as easily
be done in the app framework itself. Any thoughts?
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> Martin, going OT just a bit... how are you using CoR now? Are you simply
> implementing your Actions as Commands instead, or are you actually
> composing your Actions out of a number of Commands?
The latter. I have no Action classes at all, and each action mapping
corresponds to a chain. There are some chains, as you describe below, that
degenerate to a single command, but most don't. I also have at least one
case where I have a special-purpose catalog that I look up (from within a
command) based on certain request characteristics, and invoke a chain from
that catalog to handle part of the request. This is all AJAX-driven. No JSP,
no Tiles, etc.
Or, are you simply
> altering the RP chain and still using Actions (or maybe making them
> Commands technically part of the RP chain)?
Yes, I'm modifying the RP chain in both my 1.3 and 1.2+chain apps, primarily
for stuff that needs to be centralised, such as authorisation, error /
exception handling, and some specialised cancellation handling.
I ask because I've dene two apps now where I used Struts 1.2.6 and my own
> CoR implementation from JWP, and the way I did it was to have a single
> Action that fires off a chain. But, in 95% of the cases, the "chain" was
> really just a single Command, so arguably there wasn't much benefit.
In my 1.2+chain app, which does use JSP & Tiles, a very common pattern is a
chain that has a command to save some state, followed by one or more
commands to load data for subsequent presentation. This allows me to
reconfigure the user's path through the app just by reconfiguring the chains
and forwards, without having to touch any Java code. My 1.3 app has
something similar in some ways, but it gets too complicated to try to
explain here.
--
Martin Cooper
I think CoR is a great pattern, I've used it with great success, but I'm
> not as sure how it fits into Struts *outside* the composable RP, which is
> a *perfect* application for it. Just curious how you (and/or others) are
> already using it.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> On Thu, February 16, 2006 4:20 pm, Martin Cooper said:
> > On 2/16/06, Michael Jouravlev <jm...@gmail.com> wrote:
> >>
> >> On 2/16/06, Martin Cooper <ma...@apache.org> wrote:
> >> > Amongst other things, 1.3 brings a clean way of implementing your
> >> action
> >> > mappings as chains of commands instead of using actions. That alone
> >> makes it
> >> > stand out from 1.2. I like it a lot. At the same time, you can still
> >> use
> >> > actions if you want to, which makes it a great platform ifor when you
> >> need
> >> > to be able to reuse some of the work you've put in on 1.2 or earlier
> >> > applications.
> >>
> >> Backward compatibility is great. Considering chain of commands, do you
> >> really think that someone who supports a legacy app, will get to
> >> refactor it with chain? (Unless this someone already did it a year ago
> >> using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR
> >> compares with learning curve for WebWork and interceptors? Therefore I
> >> have doubts that CoR will be used widely, outside of early adopters'
> >> circle. But I am glad that it finally is about to make it officially.
> >
> >
> > The chain stuff is actually available in 1.2.x as well, as an add-on
> > package, so it's not exactly new news. It's been available for 2-1/2
> years
> > now. It's just that it's not as cleanly integrated in 1.2 as it is in
> 1.3.
> >
> > I was actually talking about forwards compatibility, rather than
> backwards
> > compatibility. If I'm building a new app using 1.3, and I realise that I
> > need some of the same functionality that I built into an earlier 1.2app,
> > I
> > can, assuming I structured my actions properly, simply pick up my
> existing
> > actions and drop them into my 1.3 app, even if the rest of the app is
> > built
> > using chains.
> >
> > But even for someone who's working on a legacy app, moving to 1.3 will
> > allow
> > them to use chains for new parts of the application if they want to,
> > leaving
> > the rest using actions. The learning hump for using chains is very, very
> > low.
> >
> > So, how about clean docs/samples on using CoR? (I asked about this in
> >> another thread). What about up-to-date MailReader?
> >
> >
> > Volunteers are always welcome. ;-)
> >
> > --
> > Martin Cooper
> >
> >
> > To my shame, I have
> >> not looked into CoR since my last surge of interest in September last
> >> year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy).
> >>
> >> The docs/samples will be the major factor for adoption among Struts
> >> 1.2.x public.
> >>
> >> ---------------------------------------------------------------------
> >> 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: Reasons for 1.3 release
Posted by Paul Benedict <pa...@yahoo.com>.
>>I think CoR is a great pattern, I've used it with great success, but I'm
not as sure how it fits into Struts *outside* the composable RP, which is
a *perfect* application for it. Just curious how you (and/or others) are
already using it.
This is my opinion too. I think the CoR is made for the Struts internal processing only but some
people are testing it out, as Ted said and Martin admitted to, as an end point for action
processing.
>From my perspective, it's clear what the intention of CoR is by its design and use, but since it
was never explicitly spelled out how it is used in Struts, I have to defer to other opinions too.
But unless I am wrong, I think it's strongly geared towards the RP and not actions.
That's why I said, ActionContext should be InternalActionContext. If Struts 1.4+ is going to have
actions without a subclass or interface, you want a method signature like: public void
execute(ActionContext cxt);
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: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
Martin, going OT just a bit... how are you using CoR now? Are you simply
implementing your Actions as Commands instead, or are you actually
composing your Actions out of a number of Commands? Or, are you simply
altering the RP chain and still using Actions (or maybe making them
Commands technically part of the RP chain)?
I ask because I've dene two apps now where I used Struts 1.2.6 and my own
CoR implementation from JWP, and the way I did it was to have a single
Action that fires off a chain. But, in 95% of the cases, the "chain" was
really just a single Command, so arguably there wasn't much benefit.
I think CoR is a great pattern, I've used it with great success, but I'm
not as sure how it fits into Struts *outside* the composable RP, which is
a *perfect* application for it. Just curious how you (and/or others) are
already using it.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
On Thu, February 16, 2006 4:20 pm, Martin Cooper said:
> On 2/16/06, Michael Jouravlev <jm...@gmail.com> wrote:
>>
>> On 2/16/06, Martin Cooper <ma...@apache.org> wrote:
>> > Amongst other things, 1.3 brings a clean way of implementing your
>> action
>> > mappings as chains of commands instead of using actions. That alone
>> makes it
>> > stand out from 1.2. I like it a lot. At the same time, you can still
>> use
>> > actions if you want to, which makes it a great platform ifor when you
>> need
>> > to be able to reuse some of the work you've put in on 1.2 or earlier
>> > applications.
>>
>> Backward compatibility is great. Considering chain of commands, do you
>> really think that someone who supports a legacy app, will get to
>> refactor it with chain? (Unless this someone already did it a year ago
>> using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR
>> compares with learning curve for WebWork and interceptors? Therefore I
>> have doubts that CoR will be used widely, outside of early adopters'
>> circle. But I am glad that it finally is about to make it officially.
>
>
> The chain stuff is actually available in 1.2.x as well, as an add-on
> package, so it's not exactly new news. It's been available for 2-1/2 years
> now. It's just that it's not as cleanly integrated in 1.2 as it is in 1.3.
>
> I was actually talking about forwards compatibility, rather than backwards
> compatibility. If I'm building a new app using 1.3, and I realise that I
> need some of the same functionality that I built into an earlier 1.2 app,
> I
> can, assuming I structured my actions properly, simply pick up my existing
> actions and drop them into my 1.3 app, even if the rest of the app is
> built
> using chains.
>
> But even for someone who's working on a legacy app, moving to 1.3 will
> allow
> them to use chains for new parts of the application if they want to,
> leaving
> the rest using actions. The learning hump for using chains is very, very
> low.
>
> So, how about clean docs/samples on using CoR? (I asked about this in
>> another thread). What about up-to-date MailReader?
>
>
> Volunteers are always welcome. ;-)
>
> --
> Martin Cooper
>
>
> To my shame, I have
>> not looked into CoR since my last surge of interest in September last
>> year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy).
>>
>> The docs/samples will be the major factor for adoption among Struts
>> 1.2.x public.
>>
>> ---------------------------------------------------------------------
>> 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: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/16/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 2/16/06, Martin Cooper <ma...@apache.org> wrote:
> > Amongst other things, 1.3 brings a clean way of implementing your action
> > mappings as chains of commands instead of using actions. That alone
> makes it
> > stand out from 1.2. I like it a lot. At the same time, you can still use
> > actions if you want to, which makes it a great platform ifor when you
> need
> > to be able to reuse some of the work you've put in on 1.2 or earlier
> > applications.
>
> Backward compatibility is great. Considering chain of commands, do you
> really think that someone who supports a legacy app, will get to
> refactor it with chain? (Unless this someone already did it a year ago
> using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR
> compares with learning curve for WebWork and interceptors? Therefore I
> have doubts that CoR will be used widely, outside of early adopters'
> circle. But I am glad that it finally is about to make it officially.
The chain stuff is actually available in 1.2.x as well, as an add-on
package, so it's not exactly new news. It's been available for 2-1/2 years
now. It's just that it's not as cleanly integrated in 1.2 as it is in 1.3.
I was actually talking about forwards compatibility, rather than backwards
compatibility. If I'm building a new app using 1.3, and I realise that I
need some of the same functionality that I built into an earlier 1.2 app, I
can, assuming I structured my actions properly, simply pick up my existing
actions and drop them into my 1.3 app, even if the rest of the app is built
using chains.
But even for someone who's working on a legacy app, moving to 1.3 will allow
them to use chains for new parts of the application if they want to, leaving
the rest using actions. The learning hump for using chains is very, very
low.
So, how about clean docs/samples on using CoR? (I asked about this in
> another thread). What about up-to-date MailReader?
Volunteers are always welcome. ;-)
--
Martin Cooper
To my shame, I have
> not looked into CoR since my last surge of interest in September last
> year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy).
>
> The docs/samples will be the major factor for adoption among Struts
> 1.2.x public.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Reasons for 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
On 2/16/06, Martin Cooper <ma...@apache.org> wrote:
> Amongst other things, 1.3 brings a clean way of implementing your action
> mappings as chains of commands instead of using actions. That alone makes it
> stand out from 1.2. I like it a lot. At the same time, you can still use
> actions if you want to, which makes it a great platform ifor when you need
> to be able to reuse some of the work you've put in on 1.2 or earlier
> applications.
Backward compatibility is great. Considering chain of commands, do you
really think that someone who supports a legacy app, will get to
refactor it with chain? (Unless this someone already did it a year ago
using nightly build ;-) ). I mean, how the learning curve for 1.3 CoR
compares with learning curve for WebWork and interceptors? Therefore I
have doubts that CoR will be used widely, outside of early adopters'
circle. But I am glad that it finally is about to make it officially.
So, how about clean docs/samples on using CoR? (I asked about this in
another thread). What about up-to-date MailReader? To my shame, I have
not looked into CoR since my last surge of interest in September last
year. Frankly, I am pretty happy with 1.2.x (or maybe I am just lazy).
The docs/samples will be the major factor for adoption among Struts
1.2.x public.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Martin Cooper <ma...@apache.org>.
On 2/16/06, Michael Jouravlev <jm...@gmail.com> wrote:
>
> On 2/16/06, Don Brown <do...@gmail.com> wrote:
> > From a Struts user standpoint, I'm am very interested in a 1.3.x GA
> > release. I have legacy Struts applications that lost funding, save the
> > occastional bug fix, and I want a stable Struts that has the Commons
> Chain
> > request processor and the ability to pass multiple runtime parameters to
> > Struts Actions that only Struts 1.3 has.
> >
> > Yes, the WebWork 2-based Struts Action 2.0 is coming and yes, I think it
> > will be technically superior to 1.3 in most every way, but it doesn't
> exist
> > as far as my legacy Struts applications are concerned. In fact, I plan
> to
> > bundle Struts Action 1.3 with Struts Action 2.0 so that users like
> myself
> > can "upgrade" to the latest Struts without having to rewrite code or
> worry
> > about things breaking.
>
> Can I rephrase the above as: "1.3 is a bugfix + some internal surgery
> release for legacy Struts apps in case you want to perform a mild
> refactoring on them"?
You can, of course, and you just did, but it wouldn't be accurate. ;-)
Amongst other things, 1.3 brings a clean way of implementing your action
mappings as chains of commands instead of using actions. That alone makes it
stand out from 1.2. I like it a lot. At the same time, you can still use
actions if you want to, which makes it a great platform ifor when you need
to be able to reuse some of the work you've put in on 1.2 or earlier
applications.
Can I also assume that you recommend using
> WebWork / 2.0 for new projects? What is your outlook on future of 1.3
> branch after it released as GA?
I think that's going to depend on peoples' comfort levels and schedules.
Most Struts users today probably have never looked at WebWork. They know
that things are going to change as WebWork morphs into Struts 2. Maybe
they're ready to make the leap to WebWork now, and go with the flow as it
morphs. Or maybe they're more comfortable sticking with what they know for
now - the Struts 1 line - until Struts 2 solidifies. To each his own.
--
Martin Cooper
---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: Reasons for 1.3 release
Posted by Joe Germuska <Jo...@Germuska.com>.
>Can I rephrase the above as: "1.3 is a bugfix + some internal surgery
>release for legacy Struts apps in case you want to perform a mild
>refactoring on them"? Can I also assume that you recommend using
>WebWork / 2.0 for new projects? What is your outlook on future of 1.3
>branch after it released as GA?
The change from Struts 1.x to Struts 2.x is likely to be rather
dramatic, and many people may be more ready to use Struts 1.3, which
should be essentially backwards compatible with Struts 1.2 and
earlier apps than they are to learn a substantially new development
paradigm.
Others will never bother to touch Struts 1.3 and will have already
started using WebWork. There is a broad spectrum of users out there.
Joe
--
Joe Germuska
Joe@Germuska.com * http://blog.germuska.com
"You really can't burn anything out by trying something new, and
even if you can burn it out, it can be fixed. Try something new."
-- Robert Moog
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Michael Jouravlev <jm...@gmail.com>.
On 2/16/06, Don Brown <do...@gmail.com> wrote:
> From a Struts user standpoint, I'm am very interested in a 1.3.x GA
> release. I have legacy Struts applications that lost funding, save the
> occastional bug fix, and I want a stable Struts that has the Commons Chain
> request processor and the ability to pass multiple runtime parameters to
> Struts Actions that only Struts 1.3 has.
>
> Yes, the WebWork 2-based Struts Action 2.0 is coming and yes, I think it
> will be technically superior to 1.3 in most every way, but it doesn't exist
> as far as my legacy Struts applications are concerned. In fact, I plan to
> bundle Struts Action 1.3 with Struts Action 2.0 so that users like myself
> can "upgrade" to the latest Struts without having to rewrite code or worry
> about things breaking.
Can I rephrase the above as: "1.3 is a bugfix + some internal surgery
release for legacy Struts apps in case you want to perform a mild
refactoring on them"? Can I also assume that you recommend using
WebWork / 2.0 for new projects? What is your outlook on future of 1.3
branch after it released as GA?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Reasons for 1.3 release
Posted by Don Brown <do...@gmail.com>.
>From a Struts user standpoint, I'm am very interested in a 1.3.x GA
release. I have legacy Struts applications that lost funding, save the
occastional bug fix, and I want a stable Struts that has the Commons Chain
request processor and the ability to pass multiple runtime parameters to
Struts Actions that only Struts 1.3 has.
Yes, the WebWork 2-based Struts Action 2.0 is coming and yes, I think it
will be technically superior to 1.3 in most every way, but it doesn't exist
as far as my legacy Struts applications are concerned. In fact, I plan to
bundle Struts Action 1.3 with Struts Action 2.0 so that users like myself
can "upgrade" to the latest Struts without having to rewrite code or worry
about things breaking.
Just because there is something more "shiny", doesn't mean everyone will
jump to use it.
Don
On 2/16/06, Frank W. Zammetti <fz...@omnytex.com> wrote:
>
> We must have hit submit at the exact same time Michael :)
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
> AIM: fzammetti
> Yahoo: fzammetti
> MSN: fzammetti@hotmail.com
>
> On Thu, February 16, 2006 12:39 pm, Michael Jouravlev said:
> > How Struts committers justify the reason for 1.3 release? What is the
> > point in 1.3 considering that WebWork / 2.0 already has interceptors
> > and other goodies? People need time to learn how to use CoR stuff.
> > While they learn, WebWork will push 1.x out of the window. Am I wrong?
> > Maybe 1.3 branch should contain only bugfixes?
> >
> > Another way to look at 1.3 is that some early adopters use 1.3
> > nightlies for quite some time already. These adopters do not need a
> > lot of docs/samples in official release since they already are using
> > this version. For them, official 1.3.x release will mean adoption by
> > management.
> >
> > So, one might think that 1.3 is intended mostly for early adopters to
> > please their management. Everybody else will eventually switch from
> > 1.2 directly to 2.0. Thus, 1.3 might be seen as a release not really
> > intended for general public.
> >
> > Do I get it all wrong? Apache Struts web page talks about two
> > frameworks meaning Shale and Action, it does not differentiate between
> > Classic and 2.0. From an outsider standpoint, does 1.3 worth
> > investment for someone who have not used its nightlies for a year or
> > so?
> >
> > One of the reasons for WebWork merger was that WebWork has almost
> > everything that has been planned for 1.3 and 1.4. What is the point t
> > continue 1.x development then?
> >
> > ---------------------------------------------------------------------
> > 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: Reasons for 1.3 release
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
We must have hit submit at the exact same time Michael :)
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
AIM: fzammetti
Yahoo: fzammetti
MSN: fzammetti@hotmail.com
On Thu, February 16, 2006 12:39 pm, Michael Jouravlev said:
> How Struts committers justify the reason for 1.3 release? What is the
> point in 1.3 considering that WebWork / 2.0 already has interceptors
> and other goodies? People need time to learn how to use CoR stuff.
> While they learn, WebWork will push 1.x out of the window. Am I wrong?
> Maybe 1.3 branch should contain only bugfixes?
>
> Another way to look at 1.3 is that some early adopters use 1.3
> nightlies for quite some time already. These adopters do not need a
> lot of docs/samples in official release since they already are using
> this version. For them, official 1.3.x release will mean adoption by
> management.
>
> So, one might think that 1.3 is intended mostly for early adopters to
> please their management. Everybody else will eventually switch from
> 1.2 directly to 2.0. Thus, 1.3 might be seen as a release not really
> intended for general public.
>
> Do I get it all wrong? Apache Struts web page talks about two
> frameworks meaning Shale and Action, it does not differentiate between
> Classic and 2.0. From an outsider standpoint, does 1.3 worth
> investment for someone who have not used its nightlies for a year or
> so?
>
> One of the reasons for WebWork merger was that WebWork has almost
> everything that has been planned for 1.3 and 1.4. What is the point t
> continue 1.x development then?
>
> ---------------------------------------------------------------------
> 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