[Zope3-dev] Re: tal:define="..." considered harmful?

Jean-Marc Orliaguet jmo at ita.chalmers.se
Sun Feb 12 05:44:20 EST 2006


Balazs Ree wrote:

>Sat, 11 Feb 2006 21:03:21 +0100 keltezéssel Jean-Marc Orliaguet azt
>írta:
>  
>
>>I almost felt that something was missing, because I'm so used to inserting
>>"tal:define" in page templates. But now I realize that this is a mistake.
>>
>>There was a discussion recently on the list about python expressions being
>>a bad idea, think twice I would say that "tal:define" is much worse:
>>    
>>
>
>I would also be interested on what the general opinion about this; I also
>agree that in case of AJAX if the server prepares all the data that needs
>to be inserted to the page (which is a Good Thing to do) there is not much 
>need to use defines. Also I use the same design pattern a lot when
>implementing custom widgets on the server side; that is, I try to move all
>the logic out of the template and into the view methods.
>
>However I think that the bad idea is not tal:define itself but the use (or
>abuse) of expressions. For me tal:define is mainly a way to give
>expression results a name and (re)use them in the template elsewhere. So I
>would not restrict the use of tal:define but rather discourage the use of
>expressions themselves.
>
>Personally I feel that some simple overviewable string expressions in
>a define (or directly in a content or replace) don't do much harm but then
>I would probably even try to avoid those if possible. For me it is mostly
>a matter of finding the right balance between readability and performance;
>I almost always prefer the first one and do a good design right away. But
>as far as ctal is concerned, I would consider adding "ctal:define" to
>the implementation.
>
>  
>

Hi!

I think it all depends on the model that you are implementing.

In a straightforward client / server model (the server provides data, 
the client renders data) it is pretty harmless to use tal:define, 
because the communication is like a point-to-point channel (only 2 parts 
are in relation). The extra data layer created by tal:define in the 
template is transient, it is a bit like a scaffolding, that gets removed 
after the template has been rendered.

This pattern is used and abused in zope2, zope3 page templates (just 
consider the amount of "tal:define" declarations at the beginning of 
each page template). Strangely enough zope3 seems to not use this 
functionality as much. Personally I have found that it has always been 
possible to move all presentation data to the view, which very little 
effort.

In the MVC model however (which I'm currently implementing see:  [1] [2] 
for some background info ) this would be a disaster, because the view 
would have a way of directly modifying the data model, bypassing 
everything else. I have added a test in CTAL to make sure that the data 
structure does not get modified during the rendering (it used to get 
modified by the variables in the tal:repeat loop for instance [3]) 
Anyway If two views are observing the same data, the reason that the 
views get automatically refreshed when the data is changed is because 
the model takes care of notifying the views (i.e. the observers) that 
the data has changed.

So if I modify the data from inside the template, neither the model 
machinery (storage adapters, event services) nor the controller will be 
notified that something has changed, and the MVC implementation will 
just fail. The only way to modify data is via: model.setData(data)

However I see python:... or javascript:... expressions more like a 
convenient way of writing expressions when the TAL syntax does not fix it.

best
/JM

[1] http://csis.pace.edu/~bergin/mvc/mvcgui.html
[2] http://www.socketsoftware.com/downloads/community/MVCinSwing.ppt
[3] http://svn.z3lab.org/trac/z3lab/changeset/2364



More information about the Zope3-dev mailing list