Multiple matches which replace elements in containers not working as expected

[Heiko Wundram]

Hey!

Another problem I'm currently facing is the following:

<py:match path="a/b">
<test />
</py:match>
<py:match path="a/c">
<test2 />
</py:match>
<py:match path="a">
<test3>
${select('*|text()')}
</test3>
</py:match>

applied to

<a>
<c />
<b />
<b />
</a>

produces

<test3>
<test2 />
<b />
<b />
</test3>

It seems as through Genshi forgets the context after the first replacement,
so that the additional matches are no longer applied (i.e., the path "a/b"
isn't found). I have no (simple) means of replacing the contained "b"s to
be matchable on their own (which fixes the problem), due to the fact that
the name is also in use in other contexts.

Thanks for any hint!

--- Heiko Wundram.

[Simon Cross]

I think this is how things are expected to work -- match templates are
applied one after the other and the previous state of the XML isn't
remember (I'm not even sure how to define the behaviour in such a
scenario).

I'm a bit surprised the "a/b" match statement wasn't applied first
though. Could you perhaps paste a complete example [1] and I can see
if I can spot anything.

[1] By "complete example" here I mean something short I can paste into
a Python shell to confirm behaviour easily.

Schiavo
Simon

[Heiko Wundram]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Simon Cross
I'm a bit surprised the "a/b" match statement wasn't applied first
though. Could you perhaps paste a complete example [1] and I can
see if I can spot anything.

The simplest, self-contained example that I could come up with that
demonstrates the behaviour:


from genshi.template import MarkupTemplate

tmpl = MarkupTemplate("""<test xmlns:py="http://genshi.edgewall.org/">
<py:match path="a/b">
<test1 />
</py:match>
<py:match path="a/c">
<test2 />
</py:match>
<py:match path="a">
<test3>
${select('*|text()')}
</test3>
</py:match>
<a>
<c />
<b />
<b />
<b />
</a>
</test>""")

print tmpl.generate()

The output is

<test>
<test3>
<test2/>
<b/>
<b/>
<b/>
</test3>
</test>

and not (as I would've expected and which is - AFAICT - generally what
you want):

<test>
<test3>
<test2/>
<test1/>
<test1/>
<test1/>
</test3>
</test>

Reordering the match templates for a/b and a/c generates the expected
output, but in case the two <a /> and <b /> elements are intermixed in
the template, there's no way to create the appropriate output.
Generally, this is part of a more complex problem for templating UI
elements (where sub-elements, which define contained functionality,
should be extended before the base element is extended, thus working
around the problem that it's pretty much impossible to *loop* over all
subtags of a specific type inside the match template for the outer type).

Thanks for the heads up that this is generally not expected to work,
but I'm somewhat at a loss at how to recreate the template to make it
work (and which would make UI-templating a whole lot easier).

- --
- --- Heiko.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSG1sfAAoJEDMqpHf921/S34YH/2+oMNVDxFryhJOBVU8sVUdS
6r9ovclef+oS0Grz1+a9oymTNGySvPWwCatu2jYoksRzDIp5Z2CQAQIKOEjFEquo
hc71bKgYfC/cv6rx8wCkTlJziDKn7ntKgaa4bkxgk1HDP8Wyw1BE6zOgYovGSW2W
m7wPo0Au9ubr5zhXu6ioYYn6g65D89qZ6ubr5CMy3Oa9h/elpdwanS2Eq5HnzQze
eV35MwAvOzo2I4sWM1J3y/hCE+hyDytBktDlP274AGkjbI3g11v3ZS39SXumau8O
33HZi5O7PpAIU7z/AqKIC9GEKoAiM5Zx+bxJ6OfX2LNIKWEMMFKmTMZi7Mdc768=
=xVmI
-----END PGP SIGNATURE-----