On 2/19/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/19/06, Michael Jouravlev [EMAIL PROTECTED] 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
On 2/21/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 2/19/06, Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/19/06, Michael Jouravlev [EMAIL PROTECTED] 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
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
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
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
On 2/19/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 2/19/06, Frank W. Zammetti [EMAIL PROTECTED] 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
On 2/20/06, Paul Benedict [EMAIL PROTECTED] wrote:
On 2/19/06, Martin Cooper [EMAIL PROTECTED] 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
On 2/20/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
I mean, we look up chains in a catalog, not
commands, right? (except technically you *are* looking up a command, I
think conceptually for Struts developers that isn't an accurate
description though).
In our C# implementation, we give
Of course, some people are already using what
we already have in production, so we need to be careful.
Ted, I am really surprised to hear this. Whose fault is it
to be using alpha/beta quality code in production? Certainly not
your fault, or any commiter's fault, except the fault of the
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 [EMAIL PROTECTED] wrote:
You want
to be able to plug into the request processor, which is a CoR pattern,
/snip
I guess
Here is a non-committer speaking (me): The CoR stuff is great as it is.
We have used it in production since mid last year. I have written an
article a year ago to tell people how great it is, and how we use
Commands instead of Actions (read up if you like
On 2/20/06, Paul Benedict [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED] wrote:
Dakota Jack wrote:
The flexibility is clear. But, from what I can see the pattern is not
CoR.
Ok, I'll
Might I suggest, and not to toot my own horn or anything, but if you are
going to launch a chain manually from an Action and not use what 1.3
provides, you might want to look at the chain implementation in Java Web
Parts:
On 2/20/06, Wolfgang Gehner [EMAIL PROTECTED] wrote:
Struts has a long history of betas being used in production (I remember
very large sites using 1.1b3 (or was it b2) in production, without me
telling them to).
Yes, that's true. I was using a Struts 1.0 beta in production for a
large site
On 2/20/06, Wolfgang Gehner [EMAIL PROTECTED] wrote:
Here is a non-committer speaking (me): The CoR stuff is great as it is.
We have used it in production since mid last year. I have written an
article a year ago to tell people how great it is, and how we use
Commands instead of Actions (read
Paul Benedict wrote:
Of course, some people are already using what
we already have in production, so we need to be careful.
Ted, I am really surprised to hear this. Whose fault is it
to be using alpha/beta quality code in production? Certainly
not your fault, or any commiter's fault,
George,
You misunderstand me. I am not against using alpha/beta Struts
in production; I think Ted was very astute to point out that ASF
eats its own dog food to display that the Foundation puts out
provable software. Take for example how the ASF websites are
all using the latest Apache 2.2.0
If you use it, the reponsibility is purely on the early adopters,
not the software developers, to maintain their unreleased
features. This is how I believe Struts 1.3.x should be handled.
Being one of these early adopters, I agree with you. My inaction on
making any changes to Struts 1.3
On 2/20/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Putting out a release just encourages developers outside of the
circle of committers to make that value judgement.
Quite right. If we were talking about an API that we introduced into
the nightly build last week or last month, then I think
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.
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
On 2/19/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 2/19/06, Frank W. Zammetti [EMAIL PROTECTED] 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
On 2/19/06, Craig McClanahan [EMAIL PROTECTED] 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
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
On 2/19/06, Frank W. Zammetti [EMAIL PROTECTED] 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
From: Martin Cooper [EMAIL PROTECTED]
On 2/19/06, Frank W. Zammetti 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
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
Why don't you guys just look at the code? It is fairly simple and
straightforward.
On 2/19/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 2/19/06, Frank W. Zammetti [EMAIL PROTECTED] wrote:
Anyone can quote chapter and verse from the GoF book. Can you instead
explain *why* what's in
On 2/19/06, Martin Cooper [EMAIL PROTECTED] wrote:
On 2/19/06, Frank W. Zammetti [EMAIL PROTECTED] 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
snip
On 2/19/06, Craig McClanahan [EMAIL PROTECTED] 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
The flexibility is clear. But, from what I can see the pattern is not CoR.
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] 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,
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 [EMAIL PROTECTED] wrote:
Craig McClanahan wrote:
This pattern, of course, can be used today in a Struts 1.x action ...
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
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
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
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: [EMAIL PROTECTED]
On Thu, February 16, 2006 12:39 pm, Michael Jouravlev said:
How Struts
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
On 2/16/06, Don Brown [EMAIL PROTECTED] 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
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
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
On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 2/16/06, Don Brown [EMAIL PROTECTED] 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
On 2/16/06, Martin Cooper [EMAIL PROTECTED] 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
On 2/16/06, Michael Jouravlev [EMAIL PROTECTED] wrote:
On 2/16/06, Martin Cooper [EMAIL PROTECTED] 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
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
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] 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,
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] 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
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
On 2/16/06, Paul Benedict [EMAIL PROTECTED] 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.
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 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
On 2/16/06, Paul Benedict [EMAIL PROTECTED] wrote:
Right now ActionContext exposes too 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
On 2/16/06, Paul Benedict [EMAIL PROTECTED] 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
Thank you for pointing out previous design flaws ;-)
--- Craig McClanahan [EMAIL PROTECTED] wrote:
On 2/16/06, Paul Benedict [EMAIL PROTECTED] 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
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
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
On 2/16/06, Frank W. Zammetti [EMAIL PROTECTED] 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.
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
58 matches
Mail list logo
