cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: current status of global input module / variables
Date Thu, 19 Dec 2002 14:10:33 GMT
On Thu, Dec 19, 2002 at 03:09:22PM +0300, Konstantin Piroumian wrote:
> From: "Jeremy Quinn" <>
> > On Thursday, Dec 19, 2002, at 11:48 Europe/London, Christian Haul wrote:
> <snip-to-save-space-and-time />
> > >
> > > which would result is {chain:other-var} being looked up as
> > > {myxml:/root/section/other-var} and {request-param:other-var} but of
> > > course {chain:my-var} would turn into {myxml:/root/section/my-var}
> > > which is not desired here. SimpleMappingMetaModule supports some more
> > > mapping options if you need it.
> > >
> > > Chris.
> >
> >
> > WOW! This stuff is amazing!
> > And very complicated!
> Agree.
> The mapping seems a little complicated to me. Can't we implement it a little
> different, something like that was proposed by Jeff Turner:
> <component-instance
>   class="org.apache.cocoon.components.modules.input.ChainMetaModule"
>   logger="core.modules.input" name="chain">
>          <input-module name="request-param" />
>          <input-module name="myxml" map-to="/root/section/{0}"/>
>   </component-instance>

What's implemented currently is flexible enough to support two models:

1) Each IM is defined separately:

         logger="core.modules.mapper" name="mapper">
         <input-module name="site"/>

        logger="core.modules.xml" name="site">
        <file src="cocoon://samples/link/linkmap"/>

Here, both {site:/site/index/@href} and {mapper:index} will refer to the
same node in the XML file generated by

(incidentally, isn't the fact that XMLFileModule can use cocoon: protocol
incredibly cool?:)

2) When a meta module 'uses' another module, it can override that
module's configuration.  For example, let's declare an unconfigured
SimpleMappingMetaModule and configure it inside a ChainMetaModule:

  logger="core.modules.mapper" name="chainmapper"/>

 logger="core.modules.input" name="mapped">
  <input-module name="request-param"/>
  <input-module name="request-attr"/>
  <input-module name="session-attr"/>
  <input-module name="chainmapper">
    <input-module name="site"/>

Again, {mapped:index} would refer to the same thing as
{site:/site/index/@href}, unless, say, you added ?index=bob to the URL
and the request-param kicked in to override it.

It's even possible to 'partially' configure a module in another one. Eg,
the <input-module name="site"/> could be moved to the chainmapper

I'm currently knee-deep in IMs implementing an
InputModuleTransformer-based linking system for Forrest, after which I
promise to help document this stuff (or rather, write lots and lots of


> But of course, there's no much problems to use request parameters like
> 'root/section/name'. This can cause a little troubles with JavaScript if
> used as input element names.
> > Thank you very much for this explanation, I would not have groked that!
> Yes, we need a more detailed documentation on modules, especially for input
> modules and their usage in the sitemap.
> Regards,
>   Konstantin
> >
> > regards Jeremy
> >

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

View raw message