On Thu, 17 Jan 2002 11:29:08 +0100, Sylvain Wallez <[EMAIL PROTECTED]> wrote:
> 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 sitemap. 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. Greetings, -- Ovidiu Predescu <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
