cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Hunsberger" <peter.hunsber...@gmail.com>
Subject Re: [RT] Design Alternatives To XPath Selectors?
Date Fri, 28 Apr 2006 20:48:01 GMT
<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

Mime
View raw message