On Wednesday, Jan 29, 2003, at 13:21 Europe/London, Christian Haul wrote:
Many thanks, Chris, that is a bit clearer.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".
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?
Thanks for your suggestions.
regards Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
