Balazs Ree wrote:

Sat, 11 Feb 2006 21:03:21 +0100 keltezéssel Jean-Marc Orliaguet azt
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.


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.



Zope3-dev mailing list

Reply via email to