cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <h...@dvs1.informatik.tu-darmstadt.de>
Subject Re: current status of global input module / variables
Date Thu, 19 Dec 2002 13:46:03 GMT
On 19.Dec.2002 -- 03:09 PM, 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.
> > >
> > 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:

The mapping itself should not be difficult to understand, though: The
example I gave just prepends the string "/root/section/" to any
requested attribute name, just like the "/root/section/{0}" would do,
I guess. (But it also allows to append a string, remove prefixes and
suffixes plus use a mapping table)

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

The rationale here is that every module would need such mapping
facilities and a central place would be nicer. In addition, someone
might come up with a different mapping syntax (regexp or the above)

Now, two things happen here: the requested attribute name travels down
to the innermost module. Since every meta module has to hand the name
over, the name can be changed on every stage. Next, the innermost
module creates an object and hands it one stage up. On every stage
something is done with this object until it finally is returned to the
caller.

The nesting is not visible to the outside, thus hiding this complexity
and allowing to change the inner workings without affecting the result.

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

Which is a little difficult as it really depends on the module itself,
how to use it. I have tried to put enough into the javadocs to get one
started using a module, but obviously I am the wrong one to judge that
;-)

Hence a solution could be me answering questions and perhaps someone
could work that into a document of some sort.

(Or we could move such discussions to the wiki and send notifications
to the list.)

	Chris.
-- 
C h r i s t i a n       H a u l
haul@informatik.tu-darmstadt.de
    fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message