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 *n
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).
>
> Almo
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 thi
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 mysel
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
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
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 (
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 sit
Might I suggest, and not to toot my own horn or anything, but if you are
going to launch a chain manually from an Action and not use what 1.3
provides, you might want to look at the chain implementation in Java Web
Parts:
http://javawebparts.sourceforge.net/javadocs/javawebparts/misc/chain/pac
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'l
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 foolha
Here is a non-committer speaking (me): The CoR stuff is great as it is.
We have used it in production since mid last year. I have written an
article a year ago to tell people how great it is, and how we use
Commands instead of Actions (read up if you like
http://www.infonoia.com/en/content.jsp?
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?
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,
I guess this i
>> 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
dev
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
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 t
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 is
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 su
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 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 fra
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 importan
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
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
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* wha
Responses are following of your remarks, Frank.
Anyone can quote chapter and verse from the GoF book. Can you instead
explain *why* what's in Struts isn't CoR?
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 te
>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 A
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 whe
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, Cr
On 2/19/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
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
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
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 exact match for the
> pattern, it matters one bit?
By the
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 con
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:
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 ...
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
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 so
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
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 *flex
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 h
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 re
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 q
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
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
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 alre
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 be
On 2/16/06, Craig McClanahan <[EMAIL PROTECTED]> 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 C
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
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
>>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 S
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 u
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
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 technical
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
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
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 sta
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
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 h
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 a
>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 Act
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 committe
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 shoul
61 matches
Mail list logo
