You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Sylvain Wallez <sy...@anyware-tech.com> on 2002/01/15 16:31:08 UTC
[update] TreeProcessor now available
Hi team,
I finally finished the interpreted implementation of the sitemap engine.
The treeprocessor package in scratchpad contains a generic engine for
pipeline-assembly languages based on evaluation trees, and the sitemap
subpackage contains the implementation of the (well-known) sitemap language.
This engine builds a tree of nodes that are used to process an
environment (i.e. incoming requests). Nodes can also be linked to nodes
in other branches of the tree, thus actually turning the tree into a
graph. This is used, for example, for sitemap views and resources.
The main design goals were :
- short load time,
- detect errors or inconsistencies ASAP and provide meaningfull messages
to help sitemap writers,
- strong modularization to allow easy integration of new features or
languages,
- cleanly separate build-time classes from run-time classes, to allow
for optimized runtime classes and garbage collection of the build
environment.
The first two goals were of primary importance and are fully achieved :
on my PC, reloading the main sitemap takes less that 1 second, to be
compared with the 17 seconds taken by the current engine. And the
criptyc "the sitemap handler is not available" has disappeared :)
Still to do : some low-level optimizations, speed tests and write more
javadocs.
I'd be happy to hear your comments on this stuff.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>Vadim Gritsenko wrote:
>>
>>>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>>>
>>><snip/>
>>>
>>>
>>>>I have seen Cocoon newbies really frightened by the lengthy
>>>><map:components> section full of class names that starts the
>>>>
>sitemap.
>
>>>>When they finally arrive at <map:pipelines>, their mindstate is such
>>>>that they hardly perceive the simplicity of the language.
>>>>
>>>Can I then suggest something? Is it meaningful to move Cocoon
>>>
>built-in
>
>>>component declarations into cocoon.xconf (preserving ability to
>>>declare them in sitemap, of course)?
>>>
>>>
>>>Then sitemap will be greatly simplified, and sitemap from
>>>"chello.war" could be as simple as several lines.
>>>
>>>
>>>Are there issues with this approach?
>>>
>>
>>Not really. This is a good idea as it would allow newbies to be less
>>frightened :)
>>
>
>First step is here: Now you can move components definitions from the
>sitemap to the cocoon.xconf. Labels and mime-types are taken into
>account by modified SitemapComponentSelector.
>
>Vadim
>
Nice ! I'll check that.
Thanks.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [update] TreeProcessor now available
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> Vadim Gritsenko wrote:
>
> >>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> >>
> >
> > <snip/>
> >
> >
> >>I have seen Cocoon newbies really frightened by the lengthy
> >><map:components> section full of class names that starts the
sitemap.
> >>When they finally arrive at <map:pipelines>, their mindstate is such
> >>that they hardly perceive the simplicity of the language.
> >>
> >
> > Can I then suggest something? Is it meaningful to move Cocoon
built-in
> > component declarations into cocoon.xconf (preserving ability to
declare
> > them in sitemap, of course)?
> >
> > Then sitemap will be greatly simplified, and sitemap from
"chello.war"
> > could be as simple as several lines.
> >
> > Are there issues with this approach?
>
>
> Not really. This is a good idea as it would allow newbies to be less
> frightened :)
First step is here: Now you can move components definitions from the
sitemap to the cocoon.xconf. Labels and mime-types are taken into
account by modified SitemapComponentSelector.
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>
> <snip/>
>
>
>>I have seen Cocoon newbies really frightened by the lengthy
>><map:components> section full of class names that starts the sitemap.
>>When they finally arrive at <map:pipelines>, their mindstate is such
>>that they hardly perceive the simplicity of the language.
>>
>
> Can I then suggest something? Is it meaningful to move Cocoon built-in
> component declarations into cocoon.xconf (preserving ability to declare
> them in sitemap, of course)?
>
> Then sitemap will be greatly simplified, and sitemap from "chello.war"
> could be as simple as several lines.
>
> Are there issues with this approach?
Not really. This is a good idea as it would allow newbies to be less
frightened :)
But it will more likely cause sitemap interoperability problems than
hints, because a type can be more easily changed that a hint, which is
part of the language definition (in the TreeProcessor).
However, this problem already exists since it is the same behaviour as
subsitemaps inheriting component definitions from their parent sitemap.
Change the type in the parent sitemap, and the children are broken !
>
>>Using hints in the sitemap is just like using "jdbc" or "j2ee" in the
>>"datasources" section of cocoon.xconf : hints avoid explicitly naming
>>the class, but their name identify their functionnality.
>>
One more thing about local components : we talked several times about
being able to choose locally between caching/non-caching pipelines.
Local components allow this choice to be done at sitemap level.
>
> BTW: I'm not against hints in sitemap...
Cool :)
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [update] TreeProcessor now available
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
<snip/>
> I have seen Cocoon newbies really frightened by the lengthy
> <map:components> section full of class names that starts the sitemap.
> When they finally arrive at <map:pipelines>, their mindstate is such
> that they hardly perceive the simplicity of the language.
Can I then suggest something? Is it meaningful to move Cocoon built-in
component declarations into cocoon.xconf (preserving ability to declare
them in sitemap, of course)?
Then sitemap will be greatly simplified, and sitemap from "chello.war"
could be as simple as several lines.
Are there issues with this approach?
> Using hints in the sitemap is just like using "jdbc" or "j2ee" in the
> "datasources" section of cocoon.xconf : hints avoid explicitly naming
> the class, but their name identify their functionnality.
BTW: I'm not against hints in sitemap...
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
<snip/>
>>Look at the "roles" section in treeprocessor.xconf in
>>org.apache.cocoon.treeprocessor (in scratchpad) : it defines a
>>RoleManager for a ComponentManager, which is configured with the
>>contents of <map:components>.
>>
>>There are hints defined in this file for some commonly used components.
>>With these hints, you can write
>> <wildcard-uri-matcher name="wildcard"/>
>>instead of
>> <map:matcher name="wildcard"
>> src="org.apache.cocoon.matching.WildcardURIMatcher"/>
>>
>>This allows to hide class names for Cocoon builtin sitemap components,
>>thus increasing readability of the sitemap.
>>
>>And since <map:components> is a Configuration for an
>>ExcaliburComponentManager, you can use all its features, including
>>declaration of components not explicitly defined by a role. This is what
>> <component role...> is for.
>>
>>Hope it's more clear now.
>>
>
>I'm not sure I like this from a markup point of view:
>
> <map:matchers>
> <map:matcher name="wildcard"
> src="org.apache.cocoon.matching.WildcardURIMatcher"/>
> </map:matchers>
>
>clearly indicates (at least to me) that:
>
>the matcher named 'wildcard' gets its source from the class
>'org.apache.cocoon.matching.WildcardURIMatcher'
>
Indeed. But what the average user wants to know is what this matcher
does. And the words "wildcard" "uri" "matcher" indicate that, be them a
class name or a hint.
>
>but you are now proposing that
>
> <map:matchers>
> <wildcard-uri-matcher name="wildcard"/>
> </map:matchers>
>
>does the same thing, since you have connected
>
> wildcard-uri-matcher -> org.apache.cocoon.matching.WildcardURIMatcher
>
>someplace else.
>
Exactly. But the first notation is still valid and available.
>
>If reducing verbosity is the only reason for this, I'm seriously
>thinking about -1 it since it provides another contract (the component
>role) that might be misleading and create another source for failure and
>failed interoperability of sitemaps.
>
This notation is not exactly to reduce verbosity, but to allow Cocoon
builtin components to be used without having to explicitly state their
full class name. Also, as hints are defined only for Cocoon builtins,
there is no interoperability problem since their definition is part of
Cocoon.
I have seen Cocoon newbies really frightened by the lengthy
<map:components> section full of class names that starts the sitemap.
When they finally arrive at <map:pipelines>, their mindstate is such
that they hardly perceive the simplicity of the language.
Using hints in the sitemap is just like using "jdbc" or "j2ee" in the
"datasources" section of cocoon.xconf : hints avoid explicitly naming
the class, but their name identify their functionnality.
Sylvain
>
>What do others think?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>
> Stefano Mazzocchi wrote:
>
> > Sylvain Wallez wrote:
> >
> >>Sylvain Wallez wrote:
> >>
> >>>Hi team,
> >>>
> >>>I finally finished the interpreted implementation of the sitemap engine.
> >>>
> >
> > way cool.
>
> Thanks :)
>
> > How do we try it out?
>
> The <sitemap> entry in cocoon.xconf is a regular component. Just replace
> it by the following :
>
> <sitemap class="org.apache.cocoon.treeprocessor.TreeProcessor"
> logger="sitemap"/>
Ok, cool.
> >>- we can also add arbitrary components such as datasources that are
> >>local to a sitemap.
> >>
> >>For example, the following is allowed :
> >>
> >><map:components>
> >>
> >> <map:matchers default="wildcard"/>
> >> <wildcard-uri-matcher name="wildcard"/>
> >> <regexp-uri-matcher name="regexp"/>
> >> <map:matcher src="my.nice.Matcher"/>
> >> <map:matchers>
> >>
> >> <component role="my.nice.Component"
> >> class="my.nice.ComponentImpl"/>
> >>
> >></map:components>
> >>
> >>I know the above isn't backward compatible with the current compiled
> >>engine, but don't you think such features can be useful ?
> >>
> >
> > Sorry but I don't get the picture from the example, can you elaborate
> > more on this?
> >
>
> Look at the "roles" section in treeprocessor.xconf in
> org.apache.cocoon.treeprocessor (in scratchpad) : it defines a
> RoleManager for a ComponentManager, which is configured with the
> contents of <map:components>.
>
> There are hints defined in this file for some commonly used components.
> With these hints, you can write
> <wildcard-uri-matcher name="wildcard"/>
> instead of
> <map:matcher name="wildcard"
> src="org.apache.cocoon.matching.WildcardURIMatcher"/>
>
> This allows to hide class names for Cocoon builtin sitemap components,
> thus increasing readability of the sitemap.
>
> And since <map:components> is a Configuration for an
> ExcaliburComponentManager, you can use all its features, including
> declaration of components not explicitly defined by a role. This is what
> <component role...> is for.
>
> Hope it's more clear now.
I'm not sure I like this from a markup point of view:
<map:matchers>
<map:matcher name="wildcard"
src="org.apache.cocoon.matching.WildcardURIMatcher"/>
</map:matchers>
clearly indicates (at least to me) that:
the matcher named 'wildcard' gets its source from the class
'org.apache.cocoon.matching.WildcardURIMatcher'
but you are now proposing that
<map:matchers>
<wildcard-uri-matcher name="wildcard"/>
</map:matchers>
does the same thing, since you have connected
wildcard-uri-matcher -> org.apache.cocoon.matching.WildcardURIMatcher
someplace else.
If reducing verbosity is the only reason for this, I'm seriously
thinking about -1 it since it provides another contract (the component
role) that might be misleading and create another source for failure and
failed interoperability of sitemaps.
What do others think?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> Nicola Ken Barozzi wrote:
>
> >----- Original Message -----
> >>>From: "Sylvain Wallez" <sy...@anyware-tech.com>
> >>>
> >>>>- we can also add arbitrary components such as datasources that are
> >>>>local to a sitemap.
> >
> >I like this a lot. Avalon Components can, in this way, easily used in
> >sitemap components; just declare them in the sitemap.
> >Anyway, a feature that makes cocoon autoload Components that are needed
in
> >other sitemap components would be very nice. A kind of jar to install
> >Generators, Transformers, etc.
> >
> I didn't catch that. Can you please elaborate more ?
Imagine I want to use an AcmeDatabaseGenerator in my sitemap;
AcmeDatabaseGenerator is Composable and uses an AcmeCoolComponent.
Current Scenario
To "install" it I need to add AcmeCoolComponent to cocoon.xconf and
AcmeDatabaseGenerator in the sitemap.
It's not immediate.
Possible scenario
I drop in an AcmeDatabaseGenerator.xar in the /components directory and it
gets installed automatically.
The AcmeCoolComponent is also available to other Components.
IIRC Phoenix has this mechanism. I think it increases easiness for
developers a lot.
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>----- Original Message -----
>From: "Sylvain Wallez" <sy...@anyware-tech.com>
>
>>Stefano Mazzocchi wrote:
>>
>>>How do we try it out?
>>>
>>The <sitemap> entry in cocoon.xconf is a regular component. Just replace
>>it by the following :
>>
>><sitemap class="org.apache.cocoon.treeprocessor.TreeProcessor"
>> logger="sitemap"/>
>>
>
>Very nice indeed. You sure scratch where it itches ;-)
>Anyway, here are my quick comments on the TreeProcessor sitemap, using the
>latest cocoon webapp demos from CVS.
>- images are not displayed, although SVG is correctly displayed
>- The documentation gives me this error directly from the servlet:
> Cocoon 2 - Internal server error
> type fatal
> message Error while evaluating 'cocoon:/book-{1}.xml' : not so
> many levels
> description org.apache.cocoon.sitemap.PatternException: Error while
> evaluating 'cocoon:/book-{1}.xml' : not so many
>levels
> sender org.apache.cocoon.servlet.CocoonServlet
> source Cocoon servlet
> request-uri
> /cocoon/documents/index.html
> path-info
> documents/index.html
>- the sitemap reload is fast indeed :-)
>- other samples that currently return 404 on the compiled version here
>return:
> org.apache.cocoon.sitemap.PatternException:
> Error while evaluating 'docs/samples/samples-{1}.xml' :
> not so many levels
>
Damn ! A last minute changes that wasn't tested as it should have been.
Shame on me :-/
This is now fixed (one-byte fix : ">=" changed to ">")
>
>- sometimes it seems that response time is slower than usual on the same
>page... can't seem to find correlations, anyway nothing numeric, only a
>sensation
>- cocoon:// protocol seems really slow. The examples of it under More
>Samples-Sources are consistently slower to load than other pages.
>
?? Everything works smoothly here...
>
>This is the first impression, "a caldo".
>
Well, time now for "a frigo" (?) impressions : I'll make some time
measurements.
><snip/>
>
>>>>- we can also add arbitrary components such as datasources that are
>>>>local to a sitemap.
>>>>
>
>I like this a lot. Avalon Components can, in this way, easily used in
>sitemap components; just declare them in the sitemap.
>Anyway, a feature that makes cocoon autoload Components that are needed in
>other sitemap components would be very nice. A kind of jar to install
>Generators, Transformers, etc.
>
I didn't catch that. Can you please elaborate more ?
Sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Nicola Ken Barozzi <ba...@nicolaken.com>.
----- Original Message -----
From: "Sylvain Wallez" <sy...@anyware-tech.com>
> Stefano Mazzocchi wrote:
> > How do we try it out?
>
> The <sitemap> entry in cocoon.xconf is a regular component. Just replace
> it by the following :
>
> <sitemap class="org.apache.cocoon.treeprocessor.TreeProcessor"
> logger="sitemap"/>
Very nice indeed. You sure scratch where it itches ;-)
Anyway, here are my quick comments on the TreeProcessor sitemap, using the
latest cocoon webapp demos from CVS.
- images are not displayed, although SVG is correctly displayed
- The documentation gives me this error directly from the servlet:
Cocoon 2 - Internal server error
type fatal
message Error while evaluating 'cocoon:/book-{1}.xml' : not so
many levels
description org.apache.cocoon.sitemap.PatternException: Error while
evaluating 'cocoon:/book-{1}.xml' : not so many
levels
sender org.apache.cocoon.servlet.CocoonServlet
source Cocoon servlet
request-uri
/cocoon/documents/index.html
path-info
documents/index.html
- the sitemap reload is fast indeed :-)
- other samples that currently return 404 on the compiled version here
return:
org.apache.cocoon.sitemap.PatternException:
Error while evaluating 'docs/samples/samples-{1}.xml' :
not so many levels
- sometimes it seems that response time is slower than usual on the same
page... can't seem to find correlations, anyway nothing numeric, only a
sensation
- cocoon:// protocol seems really slow. The examples of it under More
Samples-Sources are consistently slower to load than other pages.
This is the first impression, "a caldo".
> >>Forgot to say in the previous post...
> >>
> >>The latest commit includes a major rewrite of component management which
> >>allowed a lot of code cleanup.
Good, it also helps in maintaining contracts.
> >>As a side benefit, these changes allow the <map:components> section to
> >>be given "as is" to a ComponentManager.configure().
<snip/>
> >>- we can also add arbitrary components such as datasources that are
> >>local to a sitemap.
I like this a lot. Avalon Components can, in this way, easily used in
sitemap components; just declare them in the sitemap.
Anyway, a feature that makes cocoon autoload Components that are needed in
other sitemap components would be very nice. A kind of jar to install
Generators, Transformers, etc.
--
Nicola Ken Barozzi xml-cocoon@nicolaken.com
These are the days of miracle and wonder...
...so don't cry baby, don't cry...
Paul Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Sylvain Wallez wrote:
>
>>Sylvain Wallez wrote:
>>
>>>Hi team,
>>>
>>>I finally finished the interpreted implementation of the sitemap engine.
>>>
>
> way cool.
Thanks :)
> How do we try it out?
The <sitemap> entry in cocoon.xconf is a regular component. Just replace
it by the following :
<sitemap class="org.apache.cocoon.treeprocessor.TreeProcessor"
logger="sitemap"/>
>
>>Forgot to say in the previous post...
>>
>>The latest commit includes a major rewrite of component management which
>>allowed a lot of code cleanup.
>>
>>As a side benefit, these changes allow the <map:components> section to
>>be given "as is" to a ComponentManager.configure().
>>
>>Practically, this means :
>>- we can use hints to name components instead of their class name (I
>>defined a few in treeprocessor.xconf),
>>
>
> cool
>
>
>>- we can also add arbitrary components such as datasources that are
>>local to a sitemap.
>>
>>For example, the following is allowed :
>>
>><map:components>
>>
>> <map:matchers default="wildcard"/>
>> <wildcard-uri-matcher name="wildcard"/>
>> <regexp-uri-matcher name="regexp"/>
>> <map:matcher src="my.nice.Matcher"/>
>> <map:matchers>
>>
>> <component role="my.nice.Component"
>> class="my.nice.ComponentImpl"/>
>>
>></map:components>
>>
>>I know the above isn't backward compatible with the current compiled
>>engine, but don't you think such features can be useful ?
>>
>
> Sorry but I don't get the picture from the example, can you elaborate
> more on this?
>
Look at the "roles" section in treeprocessor.xconf in
org.apache.cocoon.treeprocessor (in scratchpad) : it defines a
RoleManager for a ComponentManager, which is configured with the
contents of <map:components>.
There are hints defined in this file for some commonly used components.
With these hints, you can write
<wildcard-uri-matcher name="wildcard"/>
instead of
<map:matcher name="wildcard"
src="org.apache.cocoon.matching.WildcardURIMatcher"/>
This allows to hide class names for Cocoon builtin sitemap components,
thus increasing readability of the sitemap.
And since <map:components> is a Configuration for an
ExcaliburComponentManager, you can use all its features, including
declaration of components not explicitly defined by a role. This is what
<component role...> is for.
Hope it's more clear now.
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Stefano Mazzocchi <st...@apache.org>.
Sylvain Wallez wrote:
>
> Sylvain Wallez wrote:
>
> > Hi team,
> >
> > I finally finished the interpreted implementation of the sitemap engine.
> >
way cool.
How do we try it out?
> Forgot to say in the previous post...
>
> The latest commit includes a major rewrite of component management which
> allowed a lot of code cleanup.
>
> As a side benefit, these changes allow the <map:components> section to
> be given "as is" to a ComponentManager.configure().
>
> Practically, this means :
> - we can use hints to name components instead of their class name (I
> defined a few in treeprocessor.xconf),
cool
> - we can also add arbitrary components such as datasources that are
> local to a sitemap.
>
> For example, the following is allowed :
>
> <map:components>
>
> <map:matchers default="wildcard"/>
> <wildcard-uri-matcher name="wildcard"/>
> <regexp-uri-matcher name="regexp"/>
> <map:matcher src="my.nice.Matcher"/>
> <map:matchers>
>
> <component role="my.nice.Component"
> class="my.nice.ComponentImpl"/>
>
> </map:components>
>
> I know the above isn't backward compatible with the current compiled
> engine, but don't you think such features can be useful ?
Sorry but I don't get the picture from the example, can you elaborate
more on this?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [update] TreeProcessor now available
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Sylvain Wallez wrote:
> Hi team,
>
> I finally finished the interpreted implementation of the sitemap engine.
>
Forgot to say in the previous post...
The latest commit includes a major rewrite of component management which
allowed a lot of code cleanup.
As a side benefit, these changes allow the <map:components> section to
be given "as is" to a ComponentManager.configure().
Practically, this means :
- we can use hints to name components instead of their class name (I
defined a few in treeprocessor.xconf),
- we can also add arbitrary components such as datasources that are
local to a sitemap.
For example, the following is allowed :
<map:components>
<map:matchers default="wildcard"/>
<wildcard-uri-matcher name="wildcard"/>
<regexp-uri-matcher name="regexp"/>
<map:matcher src="my.nice.Matcher"/>
<map:matchers>
<component role="my.nice.Component"
class="my.nice.ComponentImpl"/>
</map:components>
I know the above isn't backward compatible with the current compiled
engine, but don't you think such features can be useful ?
Cheers,
Sylvain
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Dev Snapshots Server Down
Posted by theranthem <th...@luarsoft.com>.
The Dev Snapshots server seeems to be down. Does anyone here have control
over that?
Thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org