Wow, I need to get on European time. I miss all the fun while I'm asleep. I was in a hurry to write before, so I've added clarification below:
> -----Original Message----- > From: Konstantin Piroumian [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 19, 2002 4:15 AM > To: [EMAIL PROTECTED] > Subject: Re: current status of global input module / variables > > > From: "Geoff Howard" <[EMAIL PROTECTED]> > > > Update: It works fine. I had to try so many different variations on the > > configuration first that I had gotten turned around. > > Strange... AFAIR, we've agreed to deprecate or even remove > 'global-parameters' from the sitemap in favour of Input modules. I think > that what you are looking for is the XMLModule. You'll find a sample in > /webapp/samples/modules (C2.1-dev). Yes, 'global-parameters' was removed (possibly twice if I understand the archive correctly!) and replaced with the GlobalInputModule implementation, which can be given values in the sitemap with the appropriate name: global-variables inside map:component-configurations like authentication-manager. Here's the snippet that's working for me in my sitemap as we speak (last updated from cvs around Dec. 7): <map:pipelines> <map:component-configurations> <global-variables> <mount-dir>leverage</mount-dir> </global-variables> <authentication-manager> <handlers> <handler name="provAdmin"> <redirect-to uri="cocoon:/login"/> <authentication uri="cocoon:raw:/authenticate"/> </handler> </handlers> </authentication-manager> </map:component-configurations> ... and in the sitemap mounted by each of the host-specific sitemaps I described in my original message, the variable is inherited "polymorpically" so to speak so that a reference to {global:mount-dir} is assigned a different value in the shared sitemap depending on which context it's called in. It works great, is very cool, please don't say it's going away. > > I'd volunteer to submit a snippet or wiki entry on this, but wasn't sure > > this feature/syntax was going to last based on the discussions from > october. > > Anyone have a problem with making this more visible? > > Not sure about the map:component-configurations though. Let's see what > others think. I've expected that the syntax may change, and that component definition may go away (referring to the undocumented ability to define components in the sitemap) but what is crucial is the ability to achieve 1) the definition specific to a sitemap (and probably therefore in the sitemap) and 2) inheritance, or at very least a way to reference the value defined by the preceding sitemap. (OT Wish: I have wished for a way to refer to the previous sitemap with the cocoon: protocol // gets you all the way back and slash refers to the one you're in, but there's no way to refer to the mount-er unless it happens to be the root sitemap.) > > Konstantin > Thanks for getting back, Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
