XSP Languages, RE: [vote] move tree-processor in the main trunk

[Vadim Gritsenko <va...@verizon.net>]

> From: Jason Foster [mailto:jafoster@uwaterloo.ca]
> 
> <snip/>
> 
> > Just to make things clear : sitemap is only one of the possible uses
of
> > the TreeProcessor : it's a generic framework for implementing
pipeline
> > assembly languages (hence "Processor") with an evaluation tree
(hence
> > "Tree").
> >
> > The supported languages are defined in treeprocessor.xconf or
> > cocoon.xconf, and the interpreted sitemap is "only" a particular
pipeline
> > assembly language implemented using this framework, but we could
> > implement others like Berin's proposal or Daniela Gehle's flowmap
(go
> > back to october 2001 in the archives to find them).
> 
> Does that mean that XSPs that do not use compiled code fragments (Go
> Python! Go JavaScript! Go JavaBean! Down with Java source code!) can
be
> handled by the TreeProcessor?

XSPs written in not Java, but BSF languages, can be handled by XSP
mechanism without any problem. Existing XSP machinery is ready for other
languages, and this might be as compiled (into Java) languages and
interpreted ones. Do you know something better then IBM's BSF? I did not
found support for script pre-parsing, to improve performance.


> If this is the case, then the door is open for another aspect of
Cocoon to
> support the "dropping in" and automatic configuration of packages.
I'm
> not as up on XSP as I could be, but I get the impression that there is
> currently no support for "contracts" between the different taglibs.

What do you mean?


Vadim


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org