On Wed, 29 Jan 2003, 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.?
>
> What would the syntax in the 2nd example look like in the sitemap?
I think solution 1 will be preferred. To allow a syntax like
<map:parameter name="bla" value="{replace:{1}}"/>
is more intuitive.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
