You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/12/29 15:51:54 UTC
Further Chain Engineering
While driving back and forth for the holidays, I spent some time
thinking about Struts and the new chain framework. Here are a few
thoughts I had:
* ChainAction should be obsoleted before a 1.3.0 release in favor of
direct handling in the default chain. As was mentioned on the user
list, we could easily add "command" and "catalog" properties to
ActionConfig and then add another link in the processing chain which
operated if those values were present, simply by looking up and
executing the specified command. As with the current action and
forward handling commands, it would simply do nothing if it saw an
ActionConfig which didn't have those values defined. This is
something I can do this week.
* It would also be pretty easy to tack on command/catalog parameters
to a ForwardConfig object and set up a similar preprocessing
mechanism. It might also be nice to have a way to specify a form
(and scope) so that an "output form" could be put into the context
for database prepopulation. (ForwardConfig *could* extend
ActionConfig and get all these things, but formally, that's probably
not really right.)
This is slightly more cumbersome because the ForwardConfig never gets
out into the wild, so we'd have to copy these properties to an
ActionForward before it is returned by "mapping.findForward(...)".
It crossed my mind that perhaps that should be the step when the form
config is resolved into an object, and the ActionForward would have a
form property instead of formName and formScope properties, but then
I thought maybe we should just leave that up to the command we're
envisioning which would create a ViewContext object.
I'd like to get some other ideas and opinions before I implement any of this.
* Now that we're moving around all these catalog/command pairs, I'm
starting to wonder if we wouldn't like to have a standard
representation of the pair in a single string. This may even belong
in the chain-package proper, but it seems so fundamental that it
would be very useful. I'm thinking split a command on ":" and if
there is text preceding the colon, treat that as a catalog name. We
could discuss whether we want to continue to truck around with double
parameters where we have them now (the controller config) or will
soon (ActionConfig, maybe ForwardConfig.) These parameters are also
some place where we might like to use the wildcard substitution
values, which is something I'll have to look at more closely, as I
haven't really started using that yet.
There were probably some other things, but since I was doing the
driving, I wasn't taking many notes.
Joe
(Apologies in advance for any duplicates; I think an earlier draft of
this got caught in the moderation queue. Have to figure out what the
mail server doesn't like about my primary account...)
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Further Chain Engineering
Posted by Joe Germuska <Jo...@Germuska.com>.
At 8:51 AM -0600 12/29/04, Joe Germuska wrote:
>While driving back and forth for the holidays, I spent some time
>thinking about Struts and the new chain framework. Here are a few
>thoughts I had:
>
>* ChainAction should be obsoleted before a 1.3.0 release in favor of
>direct handling in the default chain. As was mentioned on the user
>list, we could easily add "command" and "catalog" properties to
>ActionConfig and then add another link in the processing chain which
>operated if those values were present, simply by looking up and
>executing the specified command. As with the current action and
>forward handling commands, it would simply do nothing if it saw an
>ActionConfig which didn't have those values defined. This is
>something I can do this week.
I just committed this last night, although I haven't yet removed
ChainAction. Any objections? Technically, DispatchChainAction is
not obsoleted by this. Neither of these classes as they are now take
into account the named catalog functionality in commons-chain 1.0.
(They can only dispatch to commands in the "default" catalog.) If
either or both of them are preserved, that should be taken into
account.
As I implemented it, "ExecuteCommand" only operates if the request is
valid. This seems to make sense if you plan to use it in place of an
action (although it can also be used to do preprocessing before a
Forward, Include, or Action are processed -- and maybe in that case,
the validity check isn't correct?)
This also made me think that perhaps we should instead make a
sub-chain which is executed in the case of a valid form submission,
and remove those per-command validity checks. Comments on this are
welcomed while I wait for some more time to work on it.
I would rather have implemented this using an ActionContext class,
but I was interested in getting it into people's hands. I am even
more convinced that it's a good idea, but I think it will take more
time to assemble.
>* It would also be pretty easy to tack on command/catalog parameters
>to a ForwardConfig object and set up a similar preprocessing
>mechanism. It might also be nice to have a way to specify a form
>(and scope) so that an "output form" could be put into the context
>for database prepopulation. (ForwardConfig *could* extend
>ActionConfig and get all these things, but formally, that's probably
>not really right.)
>
>This is slightly more cumbersome because the ForwardConfig never
>gets out into the wild, so we'd have to copy these properties to an
>ActionForward before it is returned by "mapping.findForward(...)".
>It crossed my mind that perhaps that should be the step when the
>form config is resolved into an object, and the ActionForward would
>have a form property instead of formName and formScope properties,
>but then I thought maybe we should just leave that up to the command
>we're envisioning which would create a ViewContext object.
>
>I'd like to get some other ideas and opinions before I implement any of this.
Still waiting... ;-)
>* Now that we're moving around all these catalog/command pairs, I'm
>starting to wonder if we wouldn't like to have a standard
>representation of the pair in a single string.
This has since happened, but since there hasn't been a chain release,
the initial implementation doesn't use it. We can easily change it
later.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Further Chain Engineering
Posted by Sean Schofield <se...@gmail.com>.
FYI
I moved this discussion to commons-dev in case anyone there wants to
contribute. (Hopefully nobody minds)
sean
On Wed, 29 Dec 2004 17:01:31 -0500, Sean Schofield
<se...@gmail.com> wrote:
> > This is definitely an interesting notion, and probably does belong in
> > Commons Chain itself.
>
> Agreed.
>
> > To avoid any backwards compatibility issues, it might be easiest to add a
> > getCommand() method to CatalogFactory that
> > does this lookup (that kind of method doesn't really fit into a class
> > named CatalogFactory very well ... but its at the correct
> > architectural level).
>
> What about a CatalogUtils class (or maybe CommandUtils)? You could
> have a couple of static methods in there for doing this...
>
> getCommand(String catalogName, String commandName)
> getCommand(String catalogCommandPair)
> ...
> etc.
>
> > Regarding syntax, I like the ':' idea, but have only one reservation
> > -- what if we later on wanted to implement some sort of URL-ish
> > interpretation where the prefix was treated as an access scheme of
> > some sort (like "http:" or "ftp:" in a typical URL), and a string like
> > "foo:bar:baz" would mean "use access method 'foo' to access catalog
> > 'bar', then load command 'baz'. Perhaps we should reserve for future
> > use any string that has more than one ':' in it.
> >
>
> Maybe this wouldn't be an issue with a "Utils" class as mentioned above.
>
> getCommand(String accessMethod, String catalogName, String commandName)
> getCommand(String catalogCommandPair)
> getCommand(String catalogCommandPair, String accessMethod)
>
> ... or something like this ... you get the picture.
>
> > Craig
>
> sean
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Further Chain Engineering
Posted by Joe Germuska <Jo...@Germuska.com>.
At 5:01 PM -0500 12/29/04, Sean Schofield wrote:
> > This is definitely an interesting notion, and probably does belong in
>> Commons Chain itself.
>
>Agreed.
>
>> To avoid any backwards compatibility issues, it might be easiest to add a
>> getCommand() method to CatalogFactory that
>> does this lookup (that kind of method doesn't really fit into a class
>> named CatalogFactory very well ... but its at the correct
>> architectural level).
>
>What about a CatalogUtils class (or maybe CommandUtils)? You could
>have a couple of static methods in there for doing this...
>
>getCommand(String catalogName, String commandName)
>getCommand(String catalogCommandPair)
>...
>etc.
This seems kind of inappropriately indirect to me. I wouldn't put up
a big fight, but I prefer implementing it as a concrete
implementation in CatalogFactory, even though I also felt some of the
mismatch Craig noted.
In fact, I just wrote an implementation and test case. I was going
to put them in bugzilla because I wasn't sure if you were watching
over here, Sean! I could do it anyway, in case there are other
non-Struts chain users.
> > Regarding syntax, I like the ':' idea, but have only one reservation
>> -- what if we later on wanted to implement some sort of URL-ish
>> interpretation where the prefix was treated as an access scheme of
>> some sort (like "http:" or "ftp:" in a typical URL), and a string like
>> "foo:bar:baz" would mean "use access method 'foo' to access catalog
>> 'bar', then load command 'baz'. Perhaps we should reserve for future
>> use any string that has more than one ':' in it.
>>
>
>Maybe this wouldn't be an issue with a "Utils" class as mentioned above.
>
>getCommand(String accessMethod, String catalogName, String commandName)
>getCommand(String catalogCommandPair)
>getCommand(String catalogCommandPair, String accessMethod)
>
>... or something like this ... you get the picture.
It seems kind of early to work out these kinds of variations. Plus,
you'll always ultimately have a situation of clients who want minimal
configuration wanting to have a single string which goes somewhere
and gets decoded predictably. These various methods don't really
help with that. By putting it in CatalogFactory and putting some
implementation in the base, people can use it now, and, at least in
theory, custom subclasses of CatalogFactory could implement more
sophisticated lookup mechanisms themselves.
(Perhaps the method in CatalogFactory should be abstract and it
should be left up to implementations? Since CatalogFactories are
pluggable, I guess that would be OK, although realistically, people
would probably not need a wide variety of resolution strategies, and
would get confused if there were more than one in play...)
Anyway, I'll put my patches in Bugzilla and we can use that to
organize further discussions.
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Further Chain Engineering
Posted by Sean Schofield <se...@gmail.com>.
> This is definitely an interesting notion, and probably does belong in
> Commons Chain itself.
Agreed.
> To avoid any backwards compatibility issues, it might be easiest to add a
> getCommand() method to CatalogFactory that
> does this lookup (that kind of method doesn't really fit into a class
> named CatalogFactory very well ... but its at the correct
> architectural level).
What about a CatalogUtils class (or maybe CommandUtils)? You could
have a couple of static methods in there for doing this...
getCommand(String catalogName, String commandName)
getCommand(String catalogCommandPair)
...
etc.
> Regarding syntax, I like the ':' idea, but have only one reservation
> -- what if we later on wanted to implement some sort of URL-ish
> interpretation where the prefix was treated as an access scheme of
> some sort (like "http:" or "ftp:" in a typical URL), and a string like
> "foo:bar:baz" would mean "use access method 'foo' to access catalog
> 'bar', then load command 'baz'. Perhaps we should reserve for future
> use any string that has more than one ':' in it.
>
Maybe this wouldn't be an issue with a "Utils" class as mentioned above.
getCommand(String accessMethod, String catalogName, String commandName)
getCommand(String catalogCommandPair)
getCommand(String catalogCommandPair, String accessMethod)
... or something like this ... you get the picture.
> Craig
sean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Further Chain Engineering
Posted by Craig McClanahan <cr...@gmail.com>.
On Wed, 29 Dec 2004 08:51:54 -0600, Joe Germuska <Jo...@germuska.com> wrote:
> [snip]
> * Now that we're moving around all these catalog/command pairs, I'm
> starting to wonder if we wouldn't like to have a standard
> representation of the pair in a single string. This may even belong
> in the chain-package proper, but it seems so fundamental that it
> would be very useful. I'm thinking split a command on ":" and if
> there is text preceding the colon, treat that as a catalog name. We
> could discuss whether we want to continue to truck around with double
> parameters where we have them now (the controller config) or will
> soon (ActionConfig, maybe ForwardConfig.) These parameters are also
> some place where we might like to use the wildcard substitution
> values, which is something I'll have to look at more closely, as I
> haven't really started using that yet.
This is definitely an interesting notion, and probably does belong in
Commons Chain itself. To avoid any backwards compatibility issues, it
might be easiest to add a getCommand() method to CatalogFactory that
does this lookup (that kind of method doesn't really fit into a class
named CatalogFactory very well ... but its at the correct
architectural level).
Regarding syntax, I like the ':' idea, but have only one reservation
-- what if we later on wanted to implement some sort of URL-ish
interpretation where the prefix was treated as an access scheme of
some sort (like "http:" or "ftp:" in a typical URL), and a string like
"foo:bar:baz" would mean "use access method 'foo' to access catalog
'bar', then load command 'baz'. Perhaps we should reserve for future
use any string that has more than one ':' in it.
> Joe
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org