[ZCM] [ZC] 940/11 Comment "TAL broken in Zope 2.7 when used in Filesystem based ZPT"

[Collector: Zope Bugs, Features, and Patches ...]

Issue #940 Update (Comment) "TAL broken in Zope 2.7 when used in Filesystem based ZPT"
 Status Pending, Zope/bug medium
To followup, visit:
  http://collector.zope.org/Zope/940

==============================================================
= Comment - Entry #11 by tejay on Oct 11, 2004 2:57 am

I have an app with ZODB based Page Templates, and much of the source contains \r\n.  The app used to run in Zope2.4.3/Python 2.1.3, but I recently  upgraded to Zope 2.7.2/Python 2.3.4, and all the Page Templates containing \r\n break with this syntax error.

Its not an option for me to change all the page template sources since the app has many installations our of our control..nor do I think I should have to...it should never have broken.

I suspect a change to the first line in PythonExpr.__init__() will fix the problem....it should also replace \r\n and \r with ' '.
________________________________________
= Comment - Entry #10 by gerry_kirk on Feb 11, 2004 10:04 am

i have gotten around this problem often by copy/pasting code into a new file and saving over original file.

Using 2.7 (various versions including RC1), python 2.3.2, CMF 1.4.2, Plone-2.0-final
________________________________________
= Comment - Entry #9 by fonso on Feb 4, 2004 3:45 am

This problem arised for me when I recompiled my Zope 2.6.2 (CMF 1.4.2) installation to Python 2.2.3 from Python 2.1.
________________________________________
= Comment - Entry #8 by tseaver on Sep 1, 2003 11:33 am

While there *may* be a bug in Zope 2.7's TAL here, it is
surfaced by a bug in CMF:  CMFCore/SPageTemplate,FSZSQLMethod,FSPropertiesObject,FSDTMLMethod}.py
each open their respective files in binary mode.

You can work around the problem by applying the patch from the CMF collector (made against CMF head, but should apply cleanly to CMF 1.4).

See the CMF collector issue:

  http://collector.zope.org/CMF/185
________________________________________
= Comment - Entry #7 by limi on Sep 1, 2003 8:23 am

Still present in Zope 2.7 beta 2.
________________________________________
= Comment - Entry #6 by limi on Jul 22, 2003 1:41 pm

I'm on Windows, btw - that might be relevant, as this is a line ending problem.

It looks like people can get Plone running under Linux with 2.7.
________________________________________
= Comment - Entry #5 by limi on Jul 22, 2003 8:05 am

Yes, we've been running Zope 2.6.x and CMF 1.4 as the base for Plone 1.1 for the past months now without problems.
________________________________________
= Comment - Entry #4 by mcdonc on Jul 22, 2003 8:01 am

Have you been able to confirm that this bug does *not* happen when running Zope 2.6.X and CMF 1.4?
________________________________________
= Comment - Entry #3 by limi on Jul 22, 2003 7:31 am

I can confirm that this bug still exists in the beta1 release of Zope 2.7.

I also suggest that the rating is upgraded to critical, as this affects 95% of the page templates out there. It's very very common to have line breaks in TAL expressions.

As it stands now, Zope 2.7 breaks all my CMF based products. I'm not sure whether this is a CMF or Zope problem.

Using Zope 2.7 and CMF 1.4.


________________________________________
= Comment - Entry #2 by philh on Jun 12, 2003 5:11 pm

Just a note to say that this was using CMF 1.4
________________________________________
= Request - Entry #1 by Anonymous User on Jun 12, 2003 5:02 pm

When a filesystem based ZPT (as would be used in a skin), has a TAL experssion like the following:

<td tal:content="python:DateTime.Date(here.end())">

there is no problem, however:

<td tal:content="python:DateTime.Date(
here.end()
)">

causes an exception, which doesn't cause a red exclamation mark in the ZMI, but on looking in the ZPT in question the error is indeed reported in the normal way:

<!-- Page Template Diagnostics
 Compilation failed
 TAL.TALDefs.TALError: Python expression error:
invalid syntax (line 1) in expression 'python:DateTime.Date(\r\nhere.end()\r\n)', at line 106, column 21
-->

Since the \r\n is in no way syntactically important in this case, I'd suggest that this is a bug.

==============================================================