cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
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" <jeremy@media.demon.co.uk>
> > 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:

       <component-instance
         class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
         logger="core.modules.mapper" name="mapper">
         <input-module name="site"/>
         <prefix>/site/</prefix>
         <suffix>/@href</suffix>
      </component-instance>

      <component-instance
        class="org.apache.cocoon.components.modules.input.XMLFileModule"
        logger="core.modules.xml" name="site">
        <reloadable>true</reloadable>
        <file src="cocoon://samples/link/linkmap"/>
      </component-instance>

Here, both {site:/site/index/@href} and {mapper:index} will refer to the
same node in the XML file generated by
http://localhost:8080/samples/link/linkmap.

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


<component-instance
  class="org.apache.cocoon.components.modules.input.SimpleMappingMetaModule"
  logger="core.modules.mapper" name="chainmapper"/>

component-instance
 class="org.apache.cocoon.components.modules.input.ChainMetaModule"
 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"/>
    <prefix>/site/</prefix>
    <suffix>/@href</suffix>
  </input-module>
</component-instance>

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


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


--Jeff

> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message