cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: org.apache.cocoon.sitemap.Handler a Component?
Date Thu, 17 Jan 2002 17:55:52 GMT
On Thu, 17 Jan 2002 11:29:08 +0100, Sylvain Wallez <>

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

You're right, there's no need to have Handler a top-level component. I
just need to have a different Handler class being created.

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

It is based on Processor, but it also looks like it extends it with
methods for regenerating the sitemap, and other minor things.

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

I noticed in your TreeProcessor implementation that you in fact
duplicate a lot of code which is in the Handler class. I am trying to
come up with a scheme where by simply changing the Handler class, and
maybe the SitemapManager, you can hook up different engines for the

This would allow me for example to hook up a totally new, Scheme
based, implementation of the sitemap. Perhaps you can do exactly the
same thing with the TreeProcessor implementation.

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

Yes, definitely.

Until now the only way for me to hookup the flowmap engine was to
rewrite the whole sitemap in Scheme, which allows me to invoke Scheme
functions directly from the pipeline. Although I much like the
approach of having a Scheme sitemap implementation, I think it will
hinder its acceptance, as I don't plan to support all the features the
current sitemap implementation has. In addition reworking the whole
thing in Scheme means throwing away a lot of good work you've already
done with the tree processor. I'll think about it, and see how can I
fit my code in better ways inside the whole thing.

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

Yes, me too.

> What do you think of this ?

I think it's the right way to do it.

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

I don't think is too tied to it. I actually reworked much of the code
to serve my Scheme implementation purposes, and so far seems to be
working fine.

> 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()

I think this is actually a better idea than the current path I'm on
(Handler as a Component). I'll try to see how this works.

Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

To unsubscribe, e-mail:
For additional commands, email:

View raw message