On Mon, 3 Nov 2003, Antonio Gallardo wrote:
> peter royal dijo:
> > On Nov 3, 2003, at 4:33 PM, Berin Loritsch wrote:
> >> Anyhoo, the basic solution is to either build a tree/graph of pure
> >> components
> >> or a tree/graph of pure beans. Either solution will work. We need to
> >> get rid
> >> of the need for the LifecycleHelper type class. I would lean more
> >> toward the
> >> bean approach for assembling the actual pipelines. It might make
> >> things a bit
> >> simpler, even to make custom hard-coded sitemaps.
> >
> > Anyone:
> >
> > Any thoughts about using Jelly as the builder for the sitemap?
> >
> > Its usage can be completely hidden, but as a tag processor, it might
> > work very well. We could use it to construct a bean-graph to model the
> > sitemap.
>
> Great! That also means usage of JXPath for retrieve the tags?
Yes, the idea is very interesting.
But I see following problems:
1. Every tag seems to produce some XML content:
// pass the output of the script somewhere
Writer someWriter = new FileWriter( "output.xml" );
XMLOutput output = XMLOutput.createXMLOutput( someWriter );
// now run a script using a URL
JellyContext context = new JellyContext();
context.runScript( "foo.jelly", output );
-------
public class FooTag extends TagSupport {
public void doTag(XMLOutput output) {
...
}
}
2. We configure components in the sitemap, which
means we have some XML code, which should be processed.
IHMO, its not a bad move to get rid of the configurations.
Most cases can be solve by using Parameterizable.
3. Jelly seems to need a <jelly> root element.
After all I see a great chance to refactor and clean up
the treeprocessor.
BTW, the Berin's idea to use a command queue
is also great. I like the idea very much.
request -> addCommand(process uri)
process uri -> addCommand(process flow)
process flow -> addCommand(process pipeline)
addCommand(release components);
addCommand(finish transactions);
Stephan.
