You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Greg Reddin <gr...@fnf.com> on 2003/10/22 20:35:35 UTC
[chain] conditionals again
I'm sorry to bring back up a discussion that's been hashed out already,
but there's something I still don't understand...
I can see why it's better for every command in the chain to be executed
rather than executing a "sub-chain" based on some condition. I can see
the correlation of the sub-chain idea to the goto notion.
But this leaves some baggage that I'm still not comfortable with. Now
every command after ValidateActionForm has to know about the "validKey"
attribute. So far, that's ok. At least I can readily see the chain of
execution and there's no variation in it. But, what if I introduce a
command of my own that creates some conditions? Now do I have to
customize *every* command in the chain after mine just to check for my
condition? This also makes it difficult at best to change the order of
execution if I so desired, but I don't know if that's necessarily a bad
thing.
If this is the case, how are we any better off with this model than we
were with a monolithic request processor? Why should the commands have
so much inter-dependence now that they are separate objects? Are we
better off with them as inter-dependent separate objects than we were as
one monolithic object?
Now, is there any way to get the best of both worlds -- no gotos, and no
"state baggage"? Is it possible that the command could just be
responsible for executing and not ever be called unless all the
conditions are in place for it to be executed? Something at a higher
level than the command would have to determine whether it should be
executed? So, you might have something between the chain and the
command that determines that. I'm not sure if that's any better because
then *that* component would have to know about all the commands as well.....
Anyway, I hope I'm making sense. I hate to ask a question and then
leave the room, but I'll have to take answers in the morning :-)
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by Greg Reddin <gr...@fnf.com>.
Ok, thanks for the clarification. So you're not suggesting that the
branching thing was a wholesale bad idea that should never be used. You
just prefer the "state checking" method for validation. I'm cool with that.
Greg
Craig R. McClanahan wrote:
> Greg Reddin wrote:
>
>> I'm sorry to bring back up a discussion that's been hashed out
>> already, but there's something I still don't understand...
>>
>> I can see why it's better for every command in the chain to be
>> executed rather than executing a "sub-chain" based on some condition.
>> I can see the correlation of the sub-chain idea to the goto notion.
>>
>> But this leaves some baggage that I'm still not comfortable with. Now
>> every command after ValidateActionForm has to know about the
>> "validKey" attribute. So far, that's ok. At least I can readily see
>> the chain of execution and there's no variation in it. But, what if I
>> introduce a command of my own that creates some conditions? Now do I
>> have to customize *every* command in the chain after mine just to
>> check for my condition? This also makes it difficult at best to
>> change the order of execution if I so desired, but I don't know if
>> that's necessarily a bad thing.
>>
>> If this is the case, how are we any better off with this model than we
>> were with a monolithic request processor? Why should the commands
>> have so much inter-dependence now that they are separate objects? Are
>> we better off with them as inter-dependent separate objects than we
>> were as one monolithic object?
>>
>> Now, is there any way to get the best of both worlds -- no gotos, and
>> no "state baggage"? Is it possible that the command could just be
>> responsible for executing and not ever be called unless all the
>> conditions are in place for it to be executed? Something at a higher
>> level than the command would have to determine whether it should be
>> executed? So, you might have something between the chain and the
>> command that determines that. I'm not sure if that's any better
>> because then *that* component would have to know about all the
>> commands as well.....
>>
>> Anyway, I hope I'm making sense. I hate to ask a question and then
>> leave the room, but I'll have to take answers in the morning :-)
>>
>
> If you've got tightly connected commands that are already highly
> interdependent (and a chain for replacing RequestProcessor definitely
> fits this description), there is normally so much shared state
> information already that adding tests for conditions isn't going to add
> any coupling that wasn't present already. If you're wiring together
> commands that are loosely coupled, and don't necessarily want the
> commands to know about each other's state, you're probably better off
> doing the "branch to an alternate chain" trick, based on a decision in a
> command that implements the branch.
>
> Both styles do work, and (in fact) both are still employed in the
> chain-config.xml right now:
>
> * The "servlet-complete" chain selects the appropriate sub-application
> module and branches, giving you the opportunity to plug in
> per-module chains that are completely different and independent,
> without introducing any coupling other than placing the ModuleConfig
> in the right place (i.e. the "servlet-standard" chain expects that as a
> precondition, instead of loading the ModuleConfig at the beginning
> of its own work).
>
> * The "servlet-standard" chain is mostly synchronous, but still has a
> branch for exception handling (required, in this case, because it's
> not caught until the postprocess() method, meaning that the rest
> of the chain has already been executed and someone threw an
> exception).
>
> For any given chain, pick the style that makes the most sense for your
> use case. But, while we're still experimenting, I tend to play with
> lots of fine-grained chains that are glued together by "smart" commands
> that branch based on conditions, and then look later to see if there is
> enough shared state to collapse those chains into one.
>
>> Thanks,
>> Greg
>>
> Craig
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Greg Reddin wrote:
> I'm sorry to bring back up a discussion that's been hashed out
> already, but there's something I still don't understand...
>
> I can see why it's better for every command in the chain to be
> executed rather than executing a "sub-chain" based on some condition.
> I can see the correlation of the sub-chain idea to the goto notion.
>
> But this leaves some baggage that I'm still not comfortable with. Now
> every command after ValidateActionForm has to know about the
> "validKey" attribute. So far, that's ok. At least I can readily see
> the chain of execution and there's no variation in it. But, what if I
> introduce a command of my own that creates some conditions? Now do I
> have to customize *every* command in the chain after mine just to
> check for my condition? This also makes it difficult at best to
> change the order of execution if I so desired, but I don't know if
> that's necessarily a bad thing.
>
> If this is the case, how are we any better off with this model than we
> were with a monolithic request processor? Why should the commands
> have so much inter-dependence now that they are separate objects? Are
> we better off with them as inter-dependent separate objects than we
> were as one monolithic object?
>
> Now, is there any way to get the best of both worlds -- no gotos, and
> no "state baggage"? Is it possible that the command could just be
> responsible for executing and not ever be called unless all the
> conditions are in place for it to be executed? Something at a higher
> level than the command would have to determine whether it should be
> executed? So, you might have something between the chain and the
> command that determines that. I'm not sure if that's any better
> because then *that* component would have to know about all the
> commands as well.....
>
> Anyway, I hope I'm making sense. I hate to ask a question and then
> leave the room, but I'll have to take answers in the morning :-)
>
If you've got tightly connected commands that are already highly
interdependent (and a chain for replacing RequestProcessor definitely
fits this description), there is normally so much shared state
information already that adding tests for conditions isn't going to add
any coupling that wasn't present already. If you're wiring together
commands that are loosely coupled, and don't necessarily want the
commands to know about each other's state, you're probably better off
doing the "branch to an alternate chain" trick, based on a decision in a
command that implements the branch.
Both styles do work, and (in fact) both are still employed in the
chain-config.xml right now:
* The "servlet-complete" chain selects the appropriate sub-application
module and branches, giving you the opportunity to plug in
per-module chains that are completely different and independent,
without introducing any coupling other than placing the ModuleConfig
in the right place (i.e. the "servlet-standard" chain expects that as a
precondition, instead of loading the ModuleConfig at the beginning
of its own work).
* The "servlet-standard" chain is mostly synchronous, but still has a
branch for exception handling (required, in this case, because it's
not caught until the postprocess() method, meaning that the rest
of the chain has already been executed and someone threw an
exception).
For any given chain, pick the style that makes the most sense for your
use case. But, while we're still experimenting, I tend to play with
lots of fine-grained chains that are glued together by "smart" commands
that branch based on conditions, and then look later to see if there is
enough shared state to collapse those chains into one.
> Thanks,
> Greg
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by David Graham <gr...@yahoo.com>.
--- Greg Reddin <gr...@fnf.com> wrote:
>
> David Graham wrote:
> > --- Greg Reddin <gr...@fnf.com> wrote:
> >>BTW, there's about five ways to submit code here. Would you prefer an
>
> >>email attachment, a bugzilla ticket, or some other way?
> >
> >
> > Bugzilla with attached cvs diff -u formatted patches.
>
> But, this is new stuff, nothing to diff...
Then you would attach the .java files.
David
>
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by Greg Reddin <gr...@fnf.com>.
David Graham wrote:
> --- Greg Reddin <gr...@fnf.com> wrote:
>>BTW, there's about five ways to submit code here. Would you prefer an
>>email attachment, a bugzilla ticket, or some other way?
>
>
> Bugzilla with attached cvs diff -u formatted patches.
But, this is new stuff, nothing to diff...
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by David Graham <gr...@yahoo.com>.
--- Greg Reddin <gr...@fnf.com> wrote:
> > The next step might be to try and integrate something like Struts
> > Workflow and/or Tiles into the RequestProcessor chain and see what the
>
> > various Chains look like.
>
> I get about a day every three weeks to look at this, but Tiles is what
> I'm working on. I'll share early and often.
>
> BTW, there's about five ways to submit code here. Would you prefer an
> email attachment, a bugzilla ticket, or some other way?
Bugzilla with attached cvs diff -u formatted patches.
David
>
> > Though, regardless of what happens with the Struts RequestProcessor (a
>
> > *very* complicated bit of business logic), I'm finding Chain to be a
> > very useful interface to an application's business layer.
>
> Yes, I'm looking that direction as well.
>
> Greg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-dev-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by Greg Reddin <gr...@fnf.com>.
> The next step might be to try and integrate something like Struts
> Workflow and/or Tiles into the RequestProcessor chain and see what the
> various Chains look like.
I get about a day every three weeks to look at this, but Tiles is what
I'm working on. I'll share early and often.
BTW, there's about five ways to submit code here. Would you prefer an
email attachment, a bugzilla ticket, or some other way?
> Though, regardless of what happens with the Struts RequestProcessor (a
> *very* complicated bit of business logic), I'm finding Chain to be a
> very useful interface to an application's business layer.
Yes, I'm looking that direction as well.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [chain] conditionals again
Posted by Ted Husted <hu...@apache.org>.
Greg Reddin wrote:
> If this is the case, how are we any better off with this model than we
> were with a monolithic request processor? Why should the commands have
> so much inter-dependence now that they are separate objects? Are we
> better off with them as inter-dependent separate objects than we were as
> one monolithic object?
The next step might be to try and integrate something like Struts
Workflow and/or Tiles into the RequestProcessor chain and see what the
various Chains look like.
Though, regardless of what happens with the Struts RequestProcessor (a
*very* complicated bit of business logic), I'm finding Chain to be a
very useful interface to an application's business layer.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org