#254 closed defect (fixed)
Genshi since 0.5.1 produces duplicated items in py:match
Reported by: | felix.schwarz@… | Owned by: | cmlenz |
---|---|---|---|
Priority: | critical | Milestone: | 0.6 |
Component: | Template processing | Version: | 0.5.1 |
Keywords: | Cc: |
Description
Since the update to Genshi 0.5.1 the content from most of our py:match directives appears twice in the output. This happens on all platforms (Linux, Windows). I verified that this is still a problem in the current 0.5 stable branch (r908).
Attachments (4)
Change History (21)
Changed 16 years ago by felix.schwarz@…
comment:1 Changed 16 years ago by felix.schwarz@…
Changed 16 years ago by felix.schwarz@…
Actually, I found another problem in our code which was caused by the mentioned commits. However, for this second problem there is a workaround by using h1 as match expression (see the second testcase)
comment:2 Changed 16 years ago by felix.schwarz@…
Ok, I found a workaround for us now: The duplication test case does pass if the first py:match (which is essentially '<div py:match="div">') is modified to use '<div py:match="body//div">'.
So it's essentially the same workaround as for the "no match" test case.
comment:3 Changed 16 years ago by felix.schwarz@…
Sometimes I had to resort to something like '*/div'. For now this is okay with us but it seems to be very fragile so we are eager to see a real fix for this.
comment:4 Changed 16 years ago by cmlenz
- Status changed from new to assigned
I'm too tired for grokking the details of what's going on here, but here two simple options for fixing the first example you posted:
- The once="true" attribute can only be used when py:match is used as an element. In your example, it's simply ignored and passed on through into the output. If you make that match template a <py:match> example, the duplication goes away.
- Moving the first match template after the other two match templates also gets rid of the duplication.
comment:5 Changed 16 years ago by felix.schwarz@…
Thanks for looking at this. Unfortunately, we can't change the order of the py:match directives as we're re-using some trac templates and all these py:matches originate from trac. Only the last one with the wrong 'py:match' is ours.
comment:6 Changed 16 years ago by didley@…
comment:7 follow-up: ↓ 8 Changed 16 years ago by stromnov@…
Is it fixed in 0.6dev branch?
comment:8 in reply to: ↑ 7 Changed 15 years ago by Felix Schwarz <felix.schwarz@…>
No, both tests still fail for trunk (as of r1059).
comment:9 Changed 15 years ago by osimons
Isn't this the same as #293?
comment:10 Changed 15 years ago by Felix Schwarz <felix.schwarz@…>
I don't think so because I checked some weeks ago with the current trunk at that time but the bug was still there.
comment:11 Changed 15 years ago by Felix Schwarz <felix.schwarz@…>
Just as a note for further investigation: This bug might be present in 0.5.1 already. We had a customer report that indicated adding a site.html in trac (hence a fourth py:match) exposed the same behavior.
comment:12 Changed 15 years ago by anonymous
- Resolution set to fixed
- Status changed from assigned to closed
comment:13 Changed 15 years ago by anonymous
- Resolution fixed deleted
- Status changed from closed to reopened
comment:14 Changed 15 years ago by cboos
Great! I don't pretend to understand the fix, but it seems to work.
However import re is missing, for the test:
-
genshi/template/tests/directives.py
diff --git a/genshi/template/tests/directives.py b/genshi/template/tests/directives.py
a b 12 12 # history and logs, available at http://genshi.edgewall.org/log/. 13 13 14 14 import doctest 15 import re 15 16 import sys 16 17 import unittest
Otherwise all tests pass on Windows, if that helps. I'll keep the change in my test environment for Trac to check if there are no adverse effects.
comment:15 Changed 15 years ago by cmlenz
- Milestone changed from 0.5.2 to 0.6
- Resolution set to fixed
- Status changed from reopened to closed
Patch applied in r1093. Thanks you so much!
comment:16 Changed 15 years ago by Felix Schwarz <felix.schwarz@…>
Thanks for applying the patch :-)
You won't release another 0.5.x, right? Otherwise I would like to see the patch also for this branch - if the regression will make it in a stable release, we'll have a lot of support troubles.
comment:17 Changed 15 years ago by anonymous
i tried to change the condition in setup.py file from 0.6 ---> 0.5 and it works fine
This is a test case for the described problem (can reproduce it with the current 0.6 trunk, too)