Edgewall Software

Opened 16 years ago

Closed 14 years ago

Last modified 12 years ago

#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)

test_duplicated_item.py (1.1 KB) - added by felix.schwarz@… 16 years ago.
This is a test case for the described problem (can reproduce it with the current 0.6 trunk, too)
test_no_match_with_single_slash.py (1.3 KB) - added by felix.schwarz@… 16 years ago.
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)
duplicated_item.JPG (11.0 KB) - added by didley@… 16 years ago.
Screenshot
genshi-254.patch (2.0 KB) - added by Felix Schwarz <felix.schwarz@…> 14 years ago.
finally a patch for the dreaded issue

Download all attachments as: .zip

Change History (21)

Changed 16 years ago by felix.schwarz@…

This is a test case for the described problem (can reproduce it with the current 0.6 trunk, too)

comment:1 Changed 16 years ago by felix.schwarz@…

The change of behavior was introduced in r884, r885.

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@…

I'm using 0.5.2dev and I got this in my admin panel

Screenshot

Could be it's the same reason.

didley

Changed 16 years ago by didley@…

Screenshot

comment:7 follow-up: Changed 15 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 14 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 14 years ago by anonymous

  • Resolution set to fixed
  • Status changed from assigned to closed

comment:13 Changed 14 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

Changed 14 years ago by Felix Schwarz <felix.schwarz@…>

finally a patch for the dreaded issue

comment:14 Changed 14 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  
    1212# history and logs, available at http://genshi.edgewall.org/log/.
    1313
    1414import doctest
     15import re
    1516import sys
    1617import 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 14 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 14 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 14 years ago by anonymous

i tried to change the condition in setup.py file from 0.6 ---> 0.5 and it works fine

Note: See TracTickets for help on using tickets.