[Zope3-dev] Re: tal:define=... considered harmful?
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. -- Balazs Ree ___ 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] Pluggins vs Application Definition
Rob Jeschofnik wrote: Jim Fulton wrote: In summary, I think we need *both* approaches, as they serve different needs. I'd have to agree... so +1 .. but I'd suggest that the application/plugin should have a way of defining which ways it can (or prefers, if it can't be enforced) to be included, so it is clear that Package-X is really a plugin for Product-Y, rather than a whole new stand-alone product. Maybe. I'm not sure it will always be clear that a package can only be used a particular way. But your point is well taken and deserves more though. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Pluggins vs Application Definition
Philipp von Weitershausen wrote: Jim Fulton wrote: Some recent discussions on the distutils-sig mailing list have helped me to understand some issues related to the ways we extend the Zope application server. Traditionally, in Zope 2, you extended Zope by dropping product packages into a special Products package. This was very convenient in many ways, but doesn't always provide enough control or visibiity to what's going on. In Zope 3, we went with a more explicit installation mechanism, in which people had to explicitly cause a package's ZCML files to be loaded for it to be used. We added a mechanism to make this easier, by simply dropping a file into a special directory, package-includes, so an installer wouldn't have to fool with pointy brackets. I've noticed that at Zope Corporation, for our customer projects, we tend not to use package-includes. We prefer to explicitly include packages we use directly oin our application ZCML files. (As applications, may be composed of several layers, we may include things at multiple levels.) In thinking about this, I realized that there are two different users here with different concerns: - Application developers need to build an application. They will generally want fairly tight control over what goes into the application. For them, it's valuable to say in an explicit way what they want. - If the application is extensible, then application users will want to be able to extend the application by adding pluggins. If application users are not technically sophisticated, or, more importantly, not technically interested, they peobably would prefer to just drop something into a special directory and be done with it. In summary, I think we need *both* approaches, as they serve different needs. I agree with all of the above, but fail to see what your implication is. Mostly thinking out loud and to lazy to bother blogging. :) Well, more than that. I think it's helpful to identify user's goals and problems to be solved rather than argue about solutions in isolation, as is commonly done. I think we have all that now. In Zope 3, we don't have anything like plugins. Zope 2 does and, thanks to *also* adopting ZCML *is* getting the best of both worlds, sort of. In neither case, IMO, to we really *separately* consider the separate needs of the application developer and the high-level user. Sure, we're not dropping Zope 3 plug-ins into a special directory but really anywhere in PYTHONPATH. Whether that additional freedom makes it easier is debatable, but I'd say we're still burned from Zope 2 wrt fixed drop-in locations. I'm not sure what you are saying here. Did you mean to say burned from Zope 2? (probably not) Frankly, I think something like ez_install zope.reallycoolstuff is even easier than manually dropping stuff. As for the package-includes slug, a simple ez_install-like tool could help there as well. I sketched it out once on a blog post: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_01_11_mata-los-productos I agree. In fact, on the distutils-sig mailing list, they are contemplating a plugin mechanism strikingly similar to Zope 2's for applications such as Chandler and I recommended a more explicit aproach, where plugins should be added under explicit user control. I think we need to consider both use cases and have stories (documentation, tools, etc.) for both and when designing these, we should consider the separate needs of the application developers and high-level users who don't need or *want* the same level of control. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[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 On another note, I think that tal:define= is the ugliest part of zpt. If only it was possible to define which attributes could be set by a tal expression, and then put the tal into the attribute itself, I would be happier. So instead if this: 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 All that would be needed for this syntax, is if an attribute in tal:attributes didn't have a definition, it would look in the attribute itself for the tal. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science ___ 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
