On 5/23/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> Marco wrote:
> >Does Shale use chain? Could you integrate chain in Shale?
>
> Shale does use chain, but to be honest, I don't know much more about
> it than that.
>
Shale uses Commons Chain to configure it's application level
processing (i.e.
At 9:23 AM +0100 5/25/05, Marco Mistroni wrote:
Hello Joe & all,
I have one question regarding the chain..
Am I correct to assume that The SelectInput command that comes after
ValidateActionForm in chain-config.xml should be called in case
validation fails?
How does that happen? Javadoc s
d regards
marco
-Original Message-
From: Joe Germuska [mailto:[EMAIL PROTECTED]
Sent: 23 May 2005 14:10
To: Marco Mistroni; 'Struts Users Mailing List'; 'Frank W. Zammetti'
Subject: RE: sTRUTS 1.3 - chain flow / complex app
Marco wrote:
>Does Shale use cha
Excellent, I am looking forward to it!
Frank
-Original Message-
From: "Marco Mistroni"<[EMAIL PROTECTED]>
Sent: 5/24/05 4:08:39 AM
To: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>
Cc: "'Struts Users Mailing List'"
Subjec
Excellent, I am looking forward to it!
Frank
-Original Message-
From: "Marco Mistroni"<[EMAIL PROTECTED]>
Sent: 5/24/05 4:08:39 AM
To: "[EMAIL PROTECTED]"<[EMAIL PROTECTED]>
Cc: "'Struts Users Mailing List'"
Subjec
marco
-Original Message-
From: Frank W. Zammetti [mailto:[EMAIL PROTECTED]
Sent: 23 May 2005 23:42
To: Marco Mistroni
Cc: 'Struts Users Mailing List'
Subject: Re: sTRUTS 1.3 - chain flow / solved
Sorry I didn't respond sooner Marco,
Fantastic work! I haven't had a chance
Sorry I didn't respond sooner Marco,
Fantastic work! I haven't had a chance to look at what you sent me yet,
but I definitely look forward to doing so. Would you have any objection
to me putting your code out on SF in CVS, maybe as a separate branch?
That way others can benefit from your eff
Marco wrote:
Does Shale use chain? Could you integrate chain in Shale?
Shale does use chain, but to be honest, I don't know much more about
it than that.
I am looking forward to add more complexity for 'testing' the chain..
If you have anything to suggest me, go ahead :-) ..
Just keep doi
Hello all,
>It's interesting to have some more complex use cases to test the
>chain model against...
I would offer my app as 'guinea pig' for complex cases :-)
Currently it's a small app that manage my own 'expenses' (I have a mysql
as backend and jboss 3.2.5/tomcat 5.5 as app server)to see
Wha
Hello,
Looks like I found a way to make it work! :-)
I have submitted the code to Frank..surely he'll find way to optimize
it..
For now, I had to extend few commands (SelectAction, ValidateActionForm,
PopulateActionForm & SelectForward) and I had to rewrite struts
chain-config.xml to use my
Joe Germuska wrote:
I'm not sure I think that would be nice ;-) Seems kind of risky, in
that it adds a lot of indeterminacy. That's the main reason why lots of
us are down on request chaining too.
Just talking about the chain pattern generically... think about trying
to implement a recursive p
At 3:23 PM -0400 5/20/05, Frank W. Zammetti wrote:
It's interesting to have some more complex use cases to test the
chain model against...
Absolutely. One thing that would be nice, and maybe it already is
and I just don't know enough yet, is to be able to essentially
restart the chain at any gi
Joe Germuska wrote:
Well, the difference between extending PopulateForm and putting a
command after it which re-populates in the case of a SOAP request is
small; the only caveat being that in the add-a-command-after model you
must do it after or the existing PopulateForm action would clobber you
I'd suggest adding a preprocessing command which recognizes the
SOAP header, as Frank described, and instead of forwarding, simply
sets a key/value pair in the ActionContext which other commands can
interpret. Then later, you could extend the PopulateForm class to
look for the flag and to do i
Joe Germuska wrote:
I do think that it would be much easier in 1.3 than in 1.2 to solve this
without doing a forward and re-engaging the request processor; I can see
where the complexity of intervening in arbitrary spots in the request
process in the "template pattern" approach of the RequestPro
However, just to level-set as far as the current 1.2.x version goes...
Thanks, Frank. That helps a lot.
I do think that it would be much easier in 1.3 than in 1.2 to solve
this without doing a forward and re-engaging the request processor; I
can see where the complexity of intervening in arbitra
I don't want to comment much, if at all, on the chain-based
implementation Marco is trying to accomplish because I am frankly not up
to speed on the 1.3 code base and so am not in a position to comment
intelligently. I'm trying to help him off the list as best I can, but
I'm actually having tr
It works, but yes, you are right in the sense that If I override
The struts catalog, everything will screw up... unless I have a look at
Chain-config before, so that I know what commands are supposed to be
In struts chain, and then add mine while keeping original ones..
I think that's the best solu
Hello Joe,
Thanx a lot for your reply...
>If you have time to try this, let me know -- but I'd be afraid that
>if you defined another catalog with the name "struts", it would
>overwrite the base "struts" catalog instead of merging with it. If
>that's true, then you either must edit the one ch
At 2:43 PM +0100 5/20/05, Marco Mistroni wrote:
Hello Joe,
As an aside, I think reveals an unfortunate (though minor)
shortcoming of the basic chain model: either way, you must edit the
struts chain-config.xml in order to use this behavior. I would
prefer if there were a way for users to register
Hello Joe,
>As an aside, I think reveals an unfortunate (though minor)
>shortcoming of the basic chain model: either way, you must edit the
>struts chain-config.xml in order to use this behavior. I would
>prefer if there were a way for users to register their preprocessing
>command without ha
No, rather than changing LookupCommand, you would put your logic into
one or more classes that are clean implementations of Command and
configure in a catalog with a name so that the existing lookup
command would find them -- either put them in catalog "struts" under
the name "servlet-standard
Hello Joe,
I have read in a sample chain-config.xml that I have downloaded,
That RequestProcessor.processPreprocess maps now to 'LookupCommand with
optional="true"'
Does that mean that, If in my webapp my
RequestProcessor.processPreProcess was doing some logic, now I have to
put that logi
At 10:05 AM +0100 5/17/05, Marco Mistroni wrote:
Hello Joe,
I am trying to port an app (Frank Zammetti's strutsws)that was
using Struts 1.1 to Struts 1.3.
I have a quick question: in which class/method the ActionForm is
populated with parameters from request?
org.apache.struts.chain.comman
24 matches
Mail list logo
