<snip/>
Imagine sending Cocoon a command snippet in XML like this: <rpc> <uri>do/something</uri> <body></body> </rpc> The snippet could be sent to a master handler and then that pipeline could forward the XML package to cocoon://do/something/handler. That pipeline is then responsible to dealing with the request, and returning whatever result set was asked for... maybe it's a recipe for cookies, or an image, or a list of songs. The real advantage is that all commands can be handled via the one pipeline. Yes, we could solve the problem using many different matchers... but really it would be more flexible in design if we pass all calls to the one pipeline which delegates the tasks appropriately. Then any software integrating with Cocoon just has to know the one URI for the request handler.
Really no need to solve this in the pipeline. You can solve this with an action handler that builds request parameters that hang around for a single generator on the other side of the POST. Essentially, you end up using your incoming XML to configure this generator. Based on this configuration information it then uses a factory pattern to invoke the various possible classes. You push the setup/generate methods of the generator (or invent your own interface as needed) down to these new classes. Nothing needs to change on the Cocoon pipeline side of things. Probably the only thing that stops this from making into the Cocoon code base is coming up with some reasonable way for the factory package/class naming conventions to work. In our case we do name based look up out of a database, but a property file based approach might suffice for general use. Heck, you could even hard code the package and just directly map the "something" directly to the class name... -- Peter Hunsberger
