Re: [Zope3-dev] Re: tal:define=... considered harmful?
Balazs Ree wrote: On Mon, 13 Feb 2006 18:59:32 +0100 Martijn Faassen wrote: Jean-Marc Orliaguet wrote: I've being working on integrating Balazs Ree's CTAL interpreter recently (added tests, fixes, etc.). CTAL is the equivalent of TAL but for javascript. I just googled around for this, and couldn't find it, but I'm intrigued. Any link? I made it some time ago just as an experiment, I was interested in having the equivalent of TAL on the client side. The implementation is far from complete but it's actually usable. If you are interested, best to check it out from the link Jean-Marc gave in the other mail (and I indeed might put it up somewhere in svn on its own). A separate svn project would be nice. I'm sure z3lab is open; it's also welcome under the z3 base on codespeak. I think the main advantage is that if someone already knows TAL can generate html from a template and raw data on the client side (which is one of the tipical AJAX usage patterns) without the need to learn another method or write dom manipulation in javascript. Right, that was my motivation too - I googled around for javascript-based templating languages but realized there wasn't really anything. Of course XSLT can be used this way too, but TAL is kinda neat too. Still, I couldn't think of much practical use for this. Perhaps in this AJAXy world this has changed. Are you interested in recovering some of there Zope TAL based regex stuff from Sapling? I'd be happy to merge it in. ctal doesn't appear to have this yet. 'ctal' is a somewhat confusing name by the way, you'd think it was TAL implemented in C, another interesting project I've dabbled with on and off in the past. We had an CVS to SVN conversion earlier this week, so sapling's source code is now here: https://infrae.com/viewvc/sapling/trunk/ (check it out with: svn co https://infrae.com/svn/sapling/trunk sapling) It has tests and everything. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Martijn Faassen wrote: Right, that was my motivation too - I googled around for javascript-based templating languages but realized there wasn't really anything. Of course XSLT can be used this way too, but TAL is kinda neat too. Still, I couldn't think of much practical use for this. Perhaps in this AJAXy world this has changed. Personally I'm very excited about ctal (and like the name too). Getting data objects from the server and feeding them to templates on the client seems like a nice way to do AJAXy things. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Benji York wrote:
Martijn Faassen wrote:
Right, that was my motivation too - I googled around for
javascript-based templating languages but realized there wasn't
really anything. Of course XSLT can be used this way too, but TAL is
kinda neat too. Still, I couldn't think of much practical use for
this. Perhaps in this AJAXy world this has changed.
Personally I'm very excited about ctal (and like the name too).
Getting data objects from the server and feeding them to templates on
the client seems like a nice way to do AJAXy things.
yep, you can also use TAL (ZPT) to create CTAL templates; that's the
reason why I think the namespace is ctal:... and not tal:..., otherwise
it could as well have been called tal:... and the template be stored in
a string.
then there are different usage patterns,
personally I download the template from the server when the page is
getting initialized (using asynchronous Ajax.request) and I store the
source in a javascript variable in a widget class. To render the
template I apply the transformation whenever the data changes. It makes
it possible to refresh widgets, otherwise you'd have to refresh the page
or redo an Ajax.request.
here is the part of the code that does the rendering:
render: function(data) {
if (this.source) {
var node = document.createElement(div);
node.innerHTML = this.source;
ctal.process_ctal(node, data);
var old_html = this.widget.innerHTML;
var new_html = node.innerHTML;
if (new_html != old_html) {
this.widget.innerHTML = node.innerHTML;
}
}
}
the performance is quite fine actually, but since this is event-driven I
should first check that the data really has been changed before firing a
modified event, to avoid rendering the template for nothing.
I think 'ctal' is fine too. (client tal)
/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Jean-Marc Orliaguet wrote: [snip description of cross-template communication] that's an anti-pattern Agreed. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Tonico Strasser wrote: (Again with the right quote, sorry.) Jean-Marc Orliaguet wrote: That's exactly what I'm saying: if templates did not try to create their own data layer, the 'li_repeat' macro could get the data from the model (instead it has to rely on cross-template communication) that's an anti-pattern which is the consequence of having introduced tal:define. :-) Hm. How else would you use the _same_ macro with different names in the same template? Tonico tal:define is used here to pass parameters to the macro. In ZPT this is done implicitly, which is why macros specify a list a variables that must be defined. In other language this is done explictly. (cf. XSLT xsl:with-param ...) If it was done explicitly in ZPT it could look like: li metal:use-macro=macros/li_repeat metal:with-params=items1 / li metal:use-macro=macros/li_repeat metal:with-params=items2 / best /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
On 2/13/06, Tonico Strasser [EMAIL PROTECTED] wrote: Looking forward to see explicit ZPTs soon :) Me too. I'd also like the macros to be called rather than expanded, so that any error messages report the error in the macro rather than in an expanded main template. This should be possible if we have explicit macro parameters. In fact, this would not only solve the two biggest problems with macros, it would make the macros functions, which is much better. If we don't want to break backwards compatibility, calling them functions would be a good idea. Slots are however highly useful, and I'm not sure what to do about them. I'd also like to remove the python: prefix completely. No tal:define, no python:, no macros, but functions. Then I'd be happy. Question is: Is it still ZPTs? ;-) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tonico Strasser wrote:
I'm interested in your opinion about parameters for macros.
Do you think this is explicit enough?:
ul tal:define=list main_navigation
li metal:use-macro=macros/li_repeat/
/ul
Or do you think explicit parameters would make things clearer?:
ul
li metal:use-macro=macros/li_repeat
metal:with-params=list main_navigation/
/ul
I don't favor explict arguments for macros, becaued I don't think they
are functions. I normally document the expected names in a comment in
the supplying template (outside the macro itself).
Tres.
except that this is not about physically passing data to the macro as if
it was a function (or updating some stack), this is about telling the
macro from where to pull the data.
for instance if you have a data structure:
data = {
'items1': [...]
'items2': [...]
}
you'd write:
li metal:use-macro=macros/li_repeat metal:with-params=items1 /
provided that the 'li_repeat' macro needs a data structure of the same
type as 'items1'.
in the current implementation one template provides data for another
template acting as some sort of proxy for the model (which translates
into complicated dependency chains since there is no reason to proxy
data only once).
regards
/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
In 'normal' tal we often refactor our defines to improve efficiency. When something is called more than once in a template, we define it at the beginning, and then use it multiple times. This improves performance dramatically of course. kit -- kit BLAKE Infrae · infrae.com · +31 10 243 7051 Hoevestraat 10 · 3033GC · Rotterdam · The Netherlands ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
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
Re: [Zope3-dev] Re: tal:define=... considered harmful?
kit BLAKE wrote: In 'normal' tal we often refactor our defines to improve efficiency. When something is called more than once in a template, we define it at the beginning, and then use it multiple times. This improves performance dramatically of course. kit -- kit BLAKE Infrae · infrae.com · +31 10 243 7051 Hoevestraat 10 · 3033GC · Rotterdam · The Netherlands ___ In that case it's fine because the modifications of the data structure are local inside the template. The data structure rendered by the view does not get modified. Ideally you can always prepare the data structure so that it already contains inside a dictionary the results you want to display , it is always possible to do it. however it is not OK when things start looking like: tal:define=dummy python: context['item'] == sometool.getNewData() and the context or the request gets overridden. Templates are not supposed to exchange data directly with one another. I reckon that if tal:define is used, then the template should not have write-access to the data model at all. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
--On 12. Februar 2006 19:18:51 +0100 Max M [EMAIL PROTECTED] wrote: a href=# tal:attributes=href here/absolute_url; title here/title; id here/getId tal:content=here/TitleTitle/a I could write this: a href=here/absolute_url id=here/getId title=here/Title tal:attributes=href; id; title tal:content=here/TitleTitle/a That's really syntactical sugar. The purpose of the tal: names is clearly to tell the parser to do _something_ with the value of an attribute. Now should a parser guess if the value of an attribute is something to be processed or not? -1 for such ideas. -aj pgpfoecidL4qX.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: tal:define=... considered harmful?
Andreas Jung wrote:
--On 12. Februar 2006 19:18:51 +0100 Max M [EMAIL PROTECTED] wrote:
a href=#
tal:attributes=href here/absolute_url;
title here/title;
id here/getId
tal:content=here/TitleTitle/a
I could write this:
a href=here/absolute_url id=here/getId title=here/Title
tal:attributes=href; id; title
tal:content=here/TitleTitle/a
That's really syntactical sugar. The purpose of the tal: names is clearly
to tell the parser to do _something_ with the value of an attribute. Now
should a parser guess if the value of an attribute is something to be
processed or not? -1 for such ideas.
-aj
That's more or less what i18n:attributes=attr1 attr2 ... does already.
We continued the discussioned off-list earlier, and one idea that came
up was:
what do we need to carry along the context, here, request, view
variables ... instead of having a single namespace, i.e. if I pass
{'title': 'some title'} to the template, it is tempting to be able to write:
div tal:content=titletitle comes here/div
instead of:
div tal:content=here/titletitle comes here/div
one of the reasons for adding the 'here' namespace is that 'title' could
as well be a local variable. But if tal:define is not implemented that
is not an issue anymore since there are no local variables. That's what
other template languages do by the way, I guess that CTAL will simplify
things too by exposing a single data structure to the user where
everything is merged already.
/JM
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
