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
_______________________________________________
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
