cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: input module question
Date Wed, 29 Jan 2003 13:53:23 GMT


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.

Just to be mud the waters still, it seems we are ceating our expression 
language here with this option.

There are plenty o expression languages available, like jxpath, jexl, 
jext, etc. These can be used as inputmodules, and if we create our own 
language, we might complicate things.

Example:

Let's say we are using a jxpath inputmodule. It uses $ notation for 
variables. If we add the {} recursive system, we are creating an 
expression language on top of another... would the user use jxpath $ or 
the inputmodule {}?

This seems IMHO to reinforce the following solution:

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

Given the above, the second.

> Is this something we ought to add or is it FS?

Something to add IMHO. In practice I've seen that it's needed, like 
variables in xpaths.

> Do both solutions require changing the SiteMap code to expose runtime 
> sitemap params {0}, {1}, {2} etc.?
> 
> What would the syntax in the 2nd example look like in the sitemap?


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message