cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: input module question
Date Wed, 29 Jan 2003 15:12:18 GMT

On Wednesday, Jan 29, 2003, at 13:56 Europe/London, Christian Haul 
wrote:

> On 29.Jan.2003 -- 01:42 PM, Jeremy Quinn wrote:
>>
>> On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul
>> wrote:
>>
>>> On 29.Jan.2003 -- 11:48 AM, Jeremy Quinn wrote:
>>>>
>>>> On Tuesday, Jan 28, 2003, at 13:40 Europe/London, Christian Haul
>>>> wrote:
>>>>> Like
>>>>>
>>>>> <...... name="phonebook" src="o.a.c.c.m.i.ReplaceAttributeModule">
>>>>>     <attribute-module name="sitemap"/>
>>>>>     <value-module     name="xmlfile"/>
>>>>> </.........>
>>>>>
>>>>> Thoughts?
>>>>
>>>> that snippet was a little too abstract for me, sorry ;)
>>>>
>>>> could you explain that again?
>>>
>>> I see two possible roads ahead: Either to restrict the space of
>>> possible attribute names e.g. by forbidding "{","}" characters and
>>> evaluate the {} expressions recursively from inner most to outer
>>> most.
>>>
>>> The second approach would be to have something similar to the "chain"
>>> module, which glues together different sources. Here, we would need a
>>> source for the attribute name and a source for the actual value. This
>>> way the attribute space would be unrestricted.
>>>
>>> The snippet above intended to show such a glue:
>>>
>>>          (1)a              (2)a
>>>  caller <======> replace <======> sitemap
>>>          (6)c       ^      (3)b
>>>                     #
>>>                (5)c # (4)b
>>>                     #
>>>                     V
>>>                  xmlfile
>>>
>>> Where (1)...(6) denotes the order in which messages are send and 
>>> a,b,c
>>> denotes values.
>>>
>>> "caller" asks "replace" for a value for "a", "replace" asks "sitemap"
>>> for a value for "a" and receives "b". "replace" now uses "b" to ask
>>> "xmlfile" for a value. "xmlfile" returns "c" which is then delivered
>>> back to "caller".
>>
>> Many thanks, Chris, that is a bit clearer.
>>
>> Which solution do people prefer?
>> Is this something we ought to add or is it FS?
>>
>> Do both solutions require changing the SiteMap code to expose runtime
>> sitemap params {0}, {1}, {2} etc.?
>
> The second requires that sitemap variables are exposed. The first
> requires changes to the substitution mechanism, though.

yup

>> What would the syntax in the 2nd example look like in the sitemap?
>
> The snippet above would (currently) be located in cocoon.xconf and the
> lookup process would be hidden from a sitemap designer's point of
> view. To the designer, it would be just {foo:bar}.

So (forgive me if I have misunderstood this again) .... the setup that 
says "the value of sitemap-param-1 is used to map to a node's name in 
XMLFileModule" resides globally in Cocoon.xconf, not in the sitemap?

Would this not mean that this module setup could not be re-used in a 
different but similar matcher/pipelines where the key-word comes 
through in a different sitemap=param-#?

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