Stefano Mazzocchi wrote:
>Ok,
>
>sitemap code generation is getting slower every day and is likely to
>become worse as we add more bugfixes and error generation.
>
>Clearly, developping on cocoon with 20 seconds delays between changes is
>a nightmare and would scare people away instantly.
>
>Now that we have a functional interpreted sitemap engine, I suggest we
>move this on the main trunk and keep improving on it from there.
>
+1
>Also, I would like to propose a name change: TreeProcessor isn't exactly
>self-explanatory as a 'sitemap interpreter'.
>
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).
Having this clear in mind, there's no problem to speak of "interpreted
sitemap".
>Moreover, I'd love to be able to decide what to use (interpreted or
>compiled) from cocoon.xconf.... or, in case the treeprocessor ends up
>faster all the time, simply blast the compiled version and get rid of
>that stupid javac!
>
The Processor used by Cocoon is a regular component : just change the
class of the <sitemap> in cocoon.xconf and you're done !
And if we decide to blast the compiled version, we just have to change
the default class in cocoon.roles. But let's both live together until
we're sure the interpreted version is bug-free.
>What do you think?
>
Sounds good :)
However, I'd like to propose some package renaming to better organize
things (inspired by some off-list discussion with Vadim) :
- org.apache.cocoon.components.treeprocessor : the TreeProcessor framework
- org.apache.cocoon.sitemap : classes common to both implementations
- org.apache.cocoon.sitemap.java : classes specific to the compiled version
- org.apache.cocoon.sitemap.tree : classes specific to the tree-based
version
Vadim proposed to insert "processor" before sitemap (i.e.
"org.apache.cocoon.processor.sitemap") to outline the fact that sitemap
is only one implementations of Processor among others, but I don't think
such a depth is necessary unless we think to have more than a dozen
different languages ;)
And also, we should start discussing the integration of schecoon and
interpreted sitemap, and more generally about Processor implementations
that coexist in the system. I was thinking about some ProcessorManager
or ProcessorSelector that any xxmap ('xx' = 'flow', 'site' or something
else) could query to get others xxmaps (e.g. a sitemap calling a
flowmap). I don't have clear thoughts about that, but it seems to me it
should be able to discriminate Processor instances by the language
(xxmap), the source file that defines it and the mount path (since a
subsitemap behaviour depends on its parents).
Thoughts ?
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
