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/01 10:34:02 UTC
[struts-chain] Writing a command to process a Tiles Definition
I'm trying to write a Command or set of Commands that will process a
Tiles definition to help complete the 1.x-compatible chained request
processor. I've got something working, but I would like some community
input before I submit it.
First, I created another subclass of AbstractPerformForward that looks
like this:
// Resolve module-relative paths
if (forwardPath.startsWith("/")) {
uri = RequestUtils.forwardURL(swcontext.getRequest(),
forwardConfig);
} else {
if (processTilesDefinition(context, forwardConfig)) {
return;
} else {
uri = forwardPath;
}
}
// Perform redirect or forward
if (forwardConfig.getRedirect()) {
if (uri.startsWith("/")) {
uri = swcontext.getRequest().getContextPath() + uri;
}
swcontext.getResponse().sendRedirect
(swcontext.getResponse().encodeRedirectURL(uri));
} else {
RequestDispatcher rd =
swcontext.getContext().getRequestDispatcher(uri);
rd.forward(swcontext.getRequest(), swcontext.getResponse());
}
You'll notice that's the same code as the other PerformForward class
with the exception that I call processTilesDefinition(). The
processTilesDefinition() method does the same thing as
processTilesDefinition() in TilesRequestProcessor except that it adds
the init() code that ensures a DefinitionsFactory is in place. If
processTilesDefinition() returns true we exit the command, otherwise we
perform the standard forward logic.
There's a few problems I have with the way this is written.
First, I would like to make processTilesDefinition() its own command
because it will be inserted here and in the replacement for
processForward() if/when that gets supported. But I can't make it a
Command because it is only inserted here conditionally. So either 1)
PerformForward will need to be broken up into multiple commands so logic
such as Tiles can be inserted, 2) processTilesDefinition should be
placed in a util class so it can be called from anywhere, or 3) I take a
different approach with Tiles and not extend AbstractPerformForward at
all. Maybe there's another approach. Any suggestions?
Secondly, there's a lot of stuff in processTilesDefinition() that could
and probably should go into an abstract base class with a standard
implementation like all the other commands. Would it be preferable to
create another abstract extension of AbstractPerformForward or just go
down a different path altogether (i.e. AbstractPerformTilesForward
extends AbstractPerformForward vs. AbstractPerformTilesForward
implements Command)? Again, it's kind of a problem because the Tiles
functionality is executed conditionally. If certain conditions are not
met, the standard processing occurs. The Command interface doesn't
support "if-else" logic and I don't think that's a shortcoming. I'd
just assume write my if-else logic in Java as opposed to XML.
Another thing is that the current TilesRequestProcessor doesn't support
redirects unless I've misread it, so neither does the chain version.
Also TilesRequestProcessor will do an include instead of a forward in
certain places, so I included that functionality in the chain version.
Next, is there any problem with doing the initDefinitionsFactory() logic
on every execution of the command instead of only during the init(). As
far as I can tell, this function only checks ot see if the
DefinitionsFactory is present. It doesn't actually initialize anything.
That's all done in the PlugIn. I don't think there's the equivalent
of the init() method in the chain interface. Should there be?
Which brings me to the PlugIn. The TilesPlugin verifies that the
RequestProcessor is a TilesRequestProcessor and returns an error if not.
Should we 1) remove this from TilesPlugin, 2) write another
TilesPlugin that does not do this verification, 3) add
ComposableRequestProcessor to the verification in TilesPlugin, or 4)
write a TilesComposableRequestProcessor (yuck)?
I think that's enough for now. Let me know if some of that doesn't make
sense.
Thanks,
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [struts-chain] Writing a command to process a Tiles Definition
Posted by Ted Husted <hu...@apache.org>.
Jing Zhou wrote:
> I am wondering how I could implement a "jump behavior" in the main
> chain. The use case for a "jump behavior" is that the main chain should
> continue with several commands skipped over. For example, I would like
> to jump to the last command in the main chain after the current command.
> Any ideas?
As a general concept, "jumping" smells wrong to me. The commands should
handle or not handle whatever is passed to them, as each individual
Command sees fit. When context dictates, the commands should be able to
"skip themselves". The chain shouldn't be cast as a controller.
I suppose you could use the Context as a psuedo-controller. For example,
it could have an attribute that told these Commands that they should be
skip themselves. (If ([whatever]) return false;)
Though, for skipping to a final Command, would a Filter work for you? I
haven't started using them yet (though I may today), but I understand
the idea is that once a Command returns true, it skips to a postprocess
method (even if an exception is thrown). The Javadoc mentions reclaiming
resources, but it could be to do anything that might need to be done
when a Chain completes. Even call itself to trigger some behavior now
that the Context has reached a certain state.
Either the Command that would trigger the "jump" could be a Filter, or
the Filter Command could be executed early in the chain (and just return
false).
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
RE: [struts-chain] Writing a command to process a Tiles Definition
Posted by Andrew Hill <an...@gridnode.com>.
<snip>
Didn't your O-O programming classes explain to you the evils of the
"goto" statement? :-)
</snip>
Of course everyone knows gotos are naughty.
Thats why programming languages nowdays market them under the much
friendlier sounding terms "break" and "continue". ;->
-----Original Message-----
From: Craig R. McClanahan [mailto:craigmcc@apache.org]
Sent: Friday, 3 October 2003 12:48
To: Struts Developers List
Subject: Re: [struts-chain] Writing a command to process a Tiles
Definition
Jing Zhou wrote:
>----- Original Message -----
>From: "Craig R. McClanahan" <cr...@apache.org>
>To: "Struts Developers List" <st...@jakarta.apache.org>
>Sent: Wednesday, October 01, 2003 11:24 AM
>Subject: Re: [struts-chain] Writing a command to process a Tiles Definition
>
>
>
>
>>There's a "conditional behavior" use case in the existing code as well;
>>when validation fails, we want to redisplay the input form. Originally,
>>I modelled this command as a Chain that conditionally executed its child
>>commands, but that seemed a little hokey. Now, this command definition
>>says:
>>
>> <command
>>
>>
>className="org.apache.struts.chain.servlet.ValidateActionForm"
>
>
>> failureCommand="servlet-validation-failure"/>
>>
>>so I'm declaring the name of another chain to go execute if validation
>>fails. The actual code that does the conditional execution looks like
>>this (in the abstract base class):
>>
>> // Call the environment-specific protected validate() method in our
>>implementation class
>> ActionErrors errors = validate(context, actionConfig, actionForm);
>>
>> // If there were no errors, proceed normally
>> if ((errors == null) || (errors.isEmpty()) {
>> return (false); // Proceed with the main chain
>> }
>>
>> // Execute the specified validation failure command
>> try {
>> Catalog catalog = (Catalog)
>> context.get(getCatalogKey());
>> Command command = catalog.getCommand(getFailureCommand());
>> command.execute(context);
>> } catch (Exception e) {
>> ... deal with exception ...
>> }
>> return (true); // Terminate the main chain
>>
>>This approach seems more scalable -- for example, you can have several
>>different conditional options, you aren't binding all the behavior
>>definitions into a single chain definition, and you can decide based on
>>your needs whether to return false or true from the main command (which
>>dictates whether the owning chain thinks processing is complete or not).
>>
>>
>>Craig
>>
>>
>>
>
>I am wondering how I could implement a "jump behavior" in the main
>chain. The use case for a "jump behavior" is that the main chain should
>continue with several commands skipped over. For example, I would like
>to jump to the last command in the main chain after the current command.
>Any ideas?
>
>Jing
>
>
Didn't your O-O programming classes explain to you the evils of the
"goto" statement? :-)
More seriously, if I was faced with that choice, I would refactor it
into an "if" decision rather than a "skip" decision, just like I would
refactor any code where a "goto" seemed like the right answer to use an
"if" instead. Just because we're talking about scripting languages
(which is what we're doing when we talk about using chain definitions as
the definition of control flows) does not change the use of correct
design principles.
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: [struts-chain] Writing a command to process a Tiles Definition
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Jing Zhou wrote:
>----- Original Message -----
>From: "Craig R. McClanahan" <cr...@apache.org>
>To: "Struts Developers List" <st...@jakarta.apache.org>
>Sent: Wednesday, October 01, 2003 11:24 AM
>Subject: Re: [struts-chain] Writing a command to process a Tiles Definition
>
>
>
>
>>There's a "conditional behavior" use case in the existing code as well;
>>when validation fails, we want to redisplay the input form. Originally,
>>I modelled this command as a Chain that conditionally executed its child
>>commands, but that seemed a little hokey. Now, this command definition
>>says:
>>
>> <command
>>
>>
>className="org.apache.struts.chain.servlet.ValidateActionForm"
>
>
>> failureCommand="servlet-validation-failure"/>
>>
>>so I'm declaring the name of another chain to go execute if validation
>>fails. The actual code that does the conditional execution looks like
>>this (in the abstract base class):
>>
>> // Call the environment-specific protected validate() method in our
>>implementation class
>> ActionErrors errors = validate(context, actionConfig, actionForm);
>>
>> // If there were no errors, proceed normally
>> if ((errors == null) || (errors.isEmpty()) {
>> return (false); // Proceed with the main chain
>> }
>>
>> // Execute the specified validation failure command
>> try {
>> Catalog catalog = (Catalog)
>> context.get(getCatalogKey());
>> Command command = catalog.getCommand(getFailureCommand());
>> command.execute(context);
>> } catch (Exception e) {
>> ... deal with exception ...
>> }
>> return (true); // Terminate the main chain
>>
>>This approach seems more scalable -- for example, you can have several
>>different conditional options, you aren't binding all the behavior
>>definitions into a single chain definition, and you can decide based on
>>your needs whether to return false or true from the main command (which
>>dictates whether the owning chain thinks processing is complete or not).
>>
>>
>>Craig
>>
>>
>>
>
>I am wondering how I could implement a "jump behavior" in the main
>chain. The use case for a "jump behavior" is that the main chain should
>continue with several commands skipped over. For example, I would like
>to jump to the last command in the main chain after the current command.
>Any ideas?
>
>Jing
>
>
Didn't your O-O programming classes explain to you the evils of the
"goto" statement? :-)
More seriously, if I was faced with that choice, I would refactor it
into an "if" decision rather than a "skip" decision, just like I would
refactor any code where a "goto" seemed like the right answer to use an
"if" instead. Just because we're talking about scripting languages
(which is what we're doing when we talk about using chain definitions as
the definition of control flows) does not change the use of correct
design principles.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [struts-chain] Writing a command to process a Tiles Definition
Posted by Jing Zhou <ji...@netspread.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>
Sent: Wednesday, October 01, 2003 11:24 AM
Subject: Re: [struts-chain] Writing a command to process a Tiles Definition
>
> There's a "conditional behavior" use case in the existing code as well;
> when validation fails, we want to redisplay the input form. Originally,
> I modelled this command as a Chain that conditionally executed its child
> commands, but that seemed a little hokey. Now, this command definition
> says:
>
> <command
className="org.apache.struts.chain.servlet.ValidateActionForm"
> failureCommand="servlet-validation-failure"/>
>
> so I'm declaring the name of another chain to go execute if validation
> fails. The actual code that does the conditional execution looks like
> this (in the abstract base class):
>
> // Call the environment-specific protected validate() method in our
> implementation class
> ActionErrors errors = validate(context, actionConfig, actionForm);
>
> // If there were no errors, proceed normally
> if ((errors == null) || (errors.isEmpty()) {
> return (false); // Proceed with the main chain
> }
>
> // Execute the specified validation failure command
> try {
> Catalog catalog = (Catalog)
> context.get(getCatalogKey());
> Command command = catalog.getCommand(getFailureCommand());
> command.execute(context);
> } catch (Exception e) {
> ... deal with exception ...
> }
> return (true); // Terminate the main chain
>
> This approach seems more scalable -- for example, you can have several
> different conditional options, you aren't binding all the behavior
> definitions into a single chain definition, and you can decide based on
> your needs whether to return false or true from the main command (which
> dictates whether the owning chain thinks processing is complete or not).
>
>
> Craig
>
I am wondering how I could implement a "jump behavior" in the main
chain. The use case for a "jump behavior" is that the main chain should
continue with several commands skipped over. For example, I would like
to jump to the last command in the main chain after the current command.
Any ideas?
Jing
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [struts-chain] Writing a command to process a Tiles Definition
Posted by Greg Reddin <gr...@fnf.com>.
> I've found that experimenting has worked a lot better once I started
> doing it in the open :-).
Point taken :-) Here's what I have so far, most definitely to be
changed sometime soon.
Greg
Re: [struts-chain] Writing a command to process a Tiles Definition
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Greg Reddin wrote:
>> There's a "conditional behavior" use case in the existing code as
>> well; when validation fails, we want to redisplay the input form.
>> Originally, I modelled this command as a Chain that conditionally
>> executed its child commands, but that seemed a little hokey. Now,
>> this command definition says:
>>
>> <command
>> className="org.apache.struts.chain.servlet.ValidateActionForm"
>> failureCommand="servlet-validation-failure"/>
>>
>> so I'm declaring the name of another chain to go execute if
>> validation fails. The actual code that does the conditional
>> execution looks like this (in the abstract base class):
>
>
> I should've seen that, but didn't look hard enough. That's pretty
> cool. I guess, due to the way digester works, it doesn't have to be
> called "failureCommand" for my case. For Tiles, I could provide any
> number of attributes like that, right?
Yes ... the attribute names just have to match up with the JavaBeans
property names on your Command implementation classes (we're using
Digester's "Set Property Rule").
>
>> I suspect there is a lot of useful refactoring to be had in order to
>> employ chain underneath something like Tiles;
>
>
> I bet you're right. For now, I'm just pasting existing functionality
> inline to make sure I understand how it works and what it's doing.
> That's why I'm reluctant to submit it yet. I'd hate to submit
> something that gets committed and locks us into an approach when
> refactoring would produce something better. I'll look at it some more.
I've found that experimenting has worked a lot better once I started
doing it in the open :-).
Seriously, as long as we play in the contrib/struts-chain directory,
people will understand that this is an actively developing idea, not a
stable framework on which to build apps -- at least not yet. We're all
learning how to apply the chain concepts, and working out what design
patterns and idioms make the most sense. It'll go better for everyone
if we share that learning experience; and it's more fun to boot.
That's a long winded way of saying I'd welcome the work you're doing
being part of the contrib/struts-chain package, if you'd like.
>
>> perhaps the best approach for development might be to go ahead and
>> let TilesPlugIn configure things the way it wants, but add your own
>> plugin (running after the Tiles one) to replace the configured
>> RequestProcessor for executing your chain(s) instead.
>
>
> The problem is that TilesPlugin throws an exception and doesn't
> configure anything if your RequestProcessor is not a
> TilesRequestProcessor. So we'd really have to replace it with
> something that doesn't do that.
>
> Thanks for the suggestions -- especially on the conditional processing
> thing. I'll take a good look at that.
>
> 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: [struts-chain] Writing a command to process a Tiles Definition
Posted by Greg Reddin <gr...@fnf.com>.
> There's a "conditional behavior" use case in the existing code as well;
> when validation fails, we want to redisplay the input form. Originally,
> I modelled this command as a Chain that conditionally executed its child
> commands, but that seemed a little hokey. Now, this command definition
> says:
>
> <command className="org.apache.struts.chain.servlet.ValidateActionForm"
> failureCommand="servlet-validation-failure"/>
>
> so I'm declaring the name of another chain to go execute if validation
> fails. The actual code that does the conditional execution looks like
> this (in the abstract base class):
I should've seen that, but didn't look hard enough. That's pretty cool.
I guess, due to the way digester works, it doesn't have to be called
"failureCommand" for my case. For Tiles, I could provide any number of
attributes like that, right?
> I suspect there is a lot of useful refactoring to be had in order to
> employ chain underneath something like Tiles;
I bet you're right. For now, I'm just pasting existing functionality
inline to make sure I understand how it works and what it's doing.
That's why I'm reluctant to submit it yet. I'd hate to submit something
that gets committed and locks us into an approach when refactoring would
produce something better. I'll look at it some more.
> perhaps the best approach
> for development might be to go ahead and let TilesPlugIn configure
> things the way it wants, but add your own plugin (running after the
> Tiles one) to replace the configured RequestProcessor for executing your
> chain(s) instead.
The problem is that TilesPlugin throws an exception and doesn't
configure anything if your RequestProcessor is not a
TilesRequestProcessor. So we'd really have to replace it with something
that doesn't do that.
Thanks for the suggestions -- especially on the conditional processing
thing. I'll take a good look at that.
Greg
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org
Re: [struts-chain] Writing a command to process a Tiles Definition
Posted by "Craig R. McClanahan" <cr...@apache.org>.
Greg Reddin wrote:
> I'm trying to write a Command or set of Commands that will process a
> Tiles definition to help complete the 1.x-compatible chained request
> processor. I've got something working, but I would like some
> community input before I submit it.
>
> First, I created another subclass of AbstractPerformForward that looks
> like this:
>
> // Resolve module-relative paths
> if (forwardPath.startsWith("/")) {
> uri = RequestUtils.forwardURL(swcontext.getRequest(),
> forwardConfig);
> } else {
> if (processTilesDefinition(context, forwardConfig)) {
> return;
> } else {
> uri = forwardPath;
> }
> }
>
>
> // Perform redirect or forward
> if (forwardConfig.getRedirect()) {
> if (uri.startsWith("/")) {
> uri = swcontext.getRequest().getContextPath() + uri;
> }
> swcontext.getResponse().sendRedirect
> (swcontext.getResponse().encodeRedirectURL(uri));
> } else {
> RequestDispatcher rd =
> swcontext.getContext().getRequestDispatcher(uri);
> rd.forward(swcontext.getRequest(), swcontext.getResponse());
> }
>
> You'll notice that's the same code as the other PerformForward class
> with the exception that I call processTilesDefinition(). The
> processTilesDefinition() method does the same thing as
> processTilesDefinition() in TilesRequestProcessor except that it adds
> the init() code that ensures a DefinitionsFactory is in place. If
> processTilesDefinition() returns true we exit the command, otherwise
> we perform the standard forward logic.
>
> There's a few problems I have with the way this is written.
>
> First, I would like to make processTilesDefinition() its own command
> because it will be inserted here and in the replacement for
> processForward() if/when that gets supported. But I can't make it a
> Command because it is only inserted here conditionally. So either 1)
> PerformForward will need to be broken up into multiple commands so
> logic such as Tiles can be inserted, 2) processTilesDefinition should
> be placed in a util class so it can be called from anywhere, or 3) I
> take a different approach with Tiles and not extend
> AbstractPerformForward at all. Maybe there's another approach. Any
> suggestions?
There's a "conditional behavior" use case in the existing code as well;
when validation fails, we want to redisplay the input form. Originally,
I modelled this command as a Chain that conditionally executed its child
commands, but that seemed a little hokey. Now, this command definition
says:
<command className="org.apache.struts.chain.servlet.ValidateActionForm"
failureCommand="servlet-validation-failure"/>
so I'm declaring the name of another chain to go execute if validation
fails. The actual code that does the conditional execution looks like
this (in the abstract base class):
// Call the environment-specific protected validate() method in our
implementation class
ActionErrors errors = validate(context, actionConfig, actionForm);
// If there were no errors, proceed normally
if ((errors == null) || (errors.isEmpty()) {
return (false); // Proceed with the main chain
}
// Execute the specified validation failure command
try {
Catalog catalog = (Catalog)
context.get(getCatalogKey());
Command command = catalog.getCommand(getFailureCommand());
command.execute(context);
} catch (Exception e) {
... deal with exception ...
}
return (true); // Terminate the main chain
This approach seems more scalable -- for example, you can have several
different conditional options, you aren't binding all the behavior
definitions into a single chain definition, and you can decide based on
your needs whether to return false or true from the main command (which
dictates whether the owning chain thinks processing is complete or not).
>
> Secondly, there's a lot of stuff in processTilesDefinition() that
> could and probably should go into an abstract base class with a
> standard implementation like all the other commands. Would it be
> preferable to create another abstract extension of
> AbstractPerformForward or just go down a different path altogether
> (i.e. AbstractPerformTilesForward extends AbstractPerformForward vs.
> AbstractPerformTilesForward implements Command)? Again, it's kind of
> a problem because the Tiles functionality is executed conditionally.
> If certain conditions are not met, the standard processing occurs.
> The Command interface doesn't support "if-else" logic and I don't
> think that's a shortcoming. I'd just assume write my if-else logic in
> Java as opposed to XML.
Or, factor it into separate commands that can be looked up and executed
at the appropriate times. Then, you're building your conditional logic
in Java, but only the "if-then-else" statement itself; the actual
straight line processing is still configured with a chain.
>
> Another thing is that the current TilesRequestProcessor doesn't
> support redirects unless I've misread it, so neither does the chain
> version. Also TilesRequestProcessor will do an include instead of a
> forward in certain places, so I included that functionality in the
> chain version.
>
> Next, is there any problem with doing the initDefinitionsFactory()
> logic on every execution of the command instead of only during the
> init(). As far as I can tell, this function only checks ot see if the
> DefinitionsFactory is present. It doesn't actually initialize
> anything. That's all done in the PlugIn. I don't think there's the
> equivalent of the init() method in the chain interface. Should there be?
>
> Which brings me to the PlugIn. The TilesPlugin verifies that the
> RequestProcessor is a TilesRequestProcessor and returns an error if
> not. Should we 1) remove this from TilesPlugin, 2) write another
> TilesPlugin that does not do this verification, 3) add
> ComposableRequestProcessor to the verification in TilesPlugin, or 4)
> write a TilesComposableRequestProcessor (yuck)?
>
> I think that's enough for now. Let me know if some of that doesn't
> make sense.
I suspect there is a lot of useful refactoring to be had in order to
employ chain underneath something like Tiles; perhaps the best approach
for development might be to go ahead and let TilesPlugIn configure
things the way it wants, but add your own plugin (running after the
Tiles one) to replace the configured RequestProcessor for executing your
chain(s) instead.
I'll sure be interested to see how this works out.
>
> Thanks,
> Greg
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org