> This is definitely an interesting notion, and probably does belong inCommons 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 [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
