Sylvain Wallez wrote:
> <snip/>
>
> The sitemap variables are, as you say, a list and not a tree. Writing
> "../" makes sense because - a tree node having only one parent - it
> has the same meaning in a list an in a tree : "go to the previous
> element".
>
> To crawl the list from its start, using the "/" seems to me a bad
> choice (see all the confusion it produces) since our minds have been
> biased for years and see in this character the symbol of a *tree*
> navigation, which must be followed by something identifying a child in
> the tree.
>
> So we should invent another syntax, and a numbered one seems good to
> me as - let's remind it - we're navigating in a list.
>
> So what about a numbered syntax such as "[/pos/]/name/". Pos is a
> number which, if positive starts from the root, and if negative starts
> from the current element. So :
> - "[1]foo" is the root variable "foo"
> - "[2]1" is the variable "1" of the top-level matcher
> - "[-1]foo" is the "foo" variable of the immediate parent of the
> current statement
> - etc.
The problem with relative or absolute paths to parameters is that they
get invalidated as soon as you change the nesting of sitemap elements.
For example, you may be using absolute parameter paths in a fragment of
a sitemap, and then realize that you have to put all of that fragment
inside another action or a selector. Bam! You have to go through all the
absolute parameter references and change them before your sitemap is
functional again.
The alternative solution with using prefixing and with inheritance of
namespaces is in my opinion a more traditional, intuitive and familiar
approach. In most modern programming languages symbols have a scope and
in many of them a symbol in the inner scope obscures the ones in the
outer scope. Some languages also provide mechanisms for unambiguously
referencing a symbol by explicitly identifying the scope. Assigning a
name to a scope is one way of identifying it. This, in my opinion, is an
intuitive (at least by virtue of being familiar to most) and convenient
way to solve the problem of referencing parameters from various levels
in the sitemap execution stack.
(BTW, I think read something somewhere about folks arguing whether
sitemap is a programming language or not. I hope my use of analogy to
the former doesn't hijack the debate of the issue here. :)
> Note that the index comes _before_ the variable name to avoid any
> confusion with XPath or Java arrays where "foo[2]" means "second
> element of foo".
This would be mighty-inconvenient for when you change the depth of
nesting of a site-map fragment. With "{////1}" syntax (which I agree
isn't all that intuitive) at least you could search-and-replace "{//"
with "{///" or "{/". With numbers however, you'd probably have to go
through all the references and manually increment or decrement all the
numbers.
Also, explicit prefixing allows you to use meaningful names, whereas
numbers bear little semantic meaning for someone looking merely at a
fragment of the sitemap. I am [clearly] against numbers or absolute path
mostly in particular for reasons of code readability and ease of
maintenance. Relative paths are OK because as long as they are short
they are easily readable.
Just think of what coding in Java or C++ would be like if you had to use
absolute (or even relative) numbers to reference parent class's members
instead of using "super." or "ClassName::". Shrug...
> My 0.02 euro...
>
> Sylvain
>
My 2 kopecks right back ach'ya. ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
