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.
> 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}.
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
