You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ovidiu Predescu <ov...@cup.hp.com> on 2002/01/17 01:02:00 UTC
org.apache.cocoon.sitemap.Handler a Component?
Hi Sylvain,
I'd like to override some of the behavior of
org.apache.cocoon.sitemap.Handler class; however SitemapManager
hard-codes the name of the Handler class in its implementation.
I'd like to make a component out the sitemap.Handler class. Are you OK
with this?
Thanks,
--
Ovidiu Predescu <ov...@cup.hp.com>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: org.apache.cocoon.sitemap.Handler a Component?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ovidiu Predescu wrote:
> Hi Sylvain,
>
> I'd like to override some of the behavior of
> org.apache.cocoon.sitemap.Handler class; however SitemapManager
> hard-codes the name of the Handler class in its implementation.
>
> I'd like to make a component out the sitemap.Handler class. Are you OK
> with this?
>
> Thanks,
>
Do you want to make Handler a top-level component or just be able to
change the actual class used by the compiled sitemap implementation ?
I'm asking this because the contract of Handler is mainly Processor,
which is also the role of SitemapManager and TreeProcessor, but tied to
a particular URI prefix in the application context (i.e. the prefix used
in map:mount)
During the design of TreeProcessor, I had a lot of thoughts about how to
allow several implementations of Processor to coexist in the same Cocoon
instance / URI space.
This is IMO key to allow for example a sitemap to delegate processing of
particular URI patterns to a flowmap engine, and also for the flowmap
engine to delegate back actual page construction to the sitemap engine
(through the "send-page" function).
The <map:mount> implementation in TreeProcessor accepts an additional
"language" attribute which implements this, but only for languages
implemented using TreeProcessor, which is obviously too limiting.
Due to lack of time, I didn't investigate further multi-engine
iteroperability, but I'm sure this is the way to go.
What do you think of this ?
Going back to your question, I wouldn't like to see sitemap.Handler
being a top-level component as it is really tied to the compiled
implementation of the sitemap language.
However, if you want to have a specialized implementation inside the
compiled engine, what about making this a configuration of
SitemapManager ? This shouldn't be difficult, since, as far as can see,
Handler is hardcoded only in Manager.getHandler()
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: org.apache.cocoon.sitemap.Handler a Component?
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
> Resist the temptation
> to make everything under the sun into a Component.
I resonate with Berin's comment.
--
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: org.apache.cocoon.sitemap.Handler a Component?
Posted by Berin Loritsch <bl...@apache.org>.
Ovidiu Predescu wrote:
> Hi Sylvain,
>
> I'd like to override some of the behavior of
> org.apache.cocoon.sitemap.Handler class; however SitemapManager
> hard-codes the name of the Handler class in its implementation.
>
> I'd like to make a component out the sitemap.Handler class. Are you OK
> with this?
:/
A Handler is a utility class for the Sitemap and its Manager.
To that end, the Handler is free to be hardcoded. Resist the temptation
to make everything under the sun into a Component.
If you have a new SitemapManager, you can use a different utility class.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org