From: "Jeff Turner" <[EMAIL PROTECTED]>
> On Thu, Dec 19, 2002 at 03:09:22PM +0300, Konstantin Piroumian wrote:
> > From: "Jeremy Quinn" <[EMAIL PROTECTED]>
> > > 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.
Great!
>
> (incidentally, isn't the fact that XMLFileModule can use cocoon: protocol
> incredibly cool?:)
Yes it's 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.
>
Fine!
> 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.
Ok, you've both - Chris and Jeff - convienced me.
These thread could be a good source for a Wiki documentation on input
modules.
Listeners, are there any volunteer to write a summary? ;)
Konstantin
>
>
> 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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
