Re: input module question

[Nicola Ken Barozzi]

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                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]