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.
(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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
