[Zope3-dev] Re: Inline code

Tue Feb 10 14:36:20 EST 2004

On Feb 10, 2004, at 8:41 AM, Casey Duncan wrote:

> On Tue, 10 Feb 2004 10:27:37 -0500 (EST)
> Shane Hathaway <shane at zope.com> wrote:
>
>> On Mon, 9 Feb 2004, Shane Hathaway wrote:
>>
>>> Further, one way to make inline code portable is to treat inline
>>> code as a module, rather than as a collection of anonymous code
>>> blocks.  For example:
>>>
>>> <html>
>>> <head><title>Shane's Example</title>
>>> <script type="text/server-python">
>>> import time
>>> def showtime():
>>>     return time.asctime()
>>> </script>
>>> </head>
>>> <body>
>>> Date and time: <span tal:content="code/showtime">(time)</span>.
>>> </body>
>>> </html>
>>
> [..]
>> Hmm, I can't think of any more cons. :-)  This seems like a big win
>> overall.  Maybe we could try this in Zope 2 first.
>
> I personally would prefer the "python library" approach. My templates
> are already ugly enough as it is.
>
> And just to let it be known again, I would really prefer a world where
> one wrote python and html (or xml) and the former transformed the
> latter. The latter would not have any scripting or additional markup in
> it what so ever. So that makes me naturally oppose anything that mixes
> more logic into the template.

I've had nightmarishly bad experiences with such systems.  The 
transformation code for anything beyond basics became very difficult to 
maintain in a matter similar to inline.  I think ZPT are about as close 
to perfect as one gets.

I prefer building good data structures in Python code, and then trying 
to keep the TAL/TALES statements in my templates as clean as possible 
(not always possible, but often enough).

Which is why I'd prefer the Python Library approach.  Although I do 
like Shane's proposal, as it's easier to refactor/restructure inline 
script code (which sometimes is a benefit) into such a library.  That's 
been my problem with many HTML + inline_scripting engines - they're 
very very difficult to restructure into a more general purpose library.