Jelly as treepressor was: rollback Cocoon 2.2 and do Fortress merge later

[Stephan Michels <st...@apache.org>]

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.

Re: Jelly as treepressor was: rollback Cocoon 2.2 and do Fortress merge later

[peter royal <pr...@apache.org>]

On Nov 4, 2003, at 5:03 AM, Stephan Michels wrote:
> 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) {
>             ...
>   }
> }

That's only an option. You can pass what is essentially a NoopXmlOutput 
that doesn't output anything.

> 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.

That can still be captured and turned into a Configuration object, as 
it is currently.

> 3. Jelly seems to need a <jelly> root element.

You can have your own root element.

-pete