[TurboGears] Re: Breaking change coming for those using other template engines!
christian wrote: Leandro Lucarella wrote: Kevin Dangoor, el viernes 6 de enero a las 12:27 me escribiste: Christian Wyglendowski and I have been talking about the overlap between Buffet (his CherryPy template filter) and TurboGears' template plugin support. What we've ended up with is a slightly modified interface that allows Buffet and TurboGears to use the same plugins for rendering templates. Even better, these plugins have no ties at all to TurboGears, Buffet or CherryPy. They can be used by anyone who wants to support multiple template engine rendering based on a dict. That's just amazing. I love the work TG puts on interoperability and reuse! I really appreciate that too! Kevin obviously gets open source and he and the TG community (all of you) have really moved a number Python projects forward. Thanks for being willing to come together on this templating plugin system and hopefully CherryPy, TG and other projects will benefit from it. I updated Buffet to support the new plugin format and moved the Python string Template and Myghty templating support into plugins (BuffetString, BuffetMyghty). If someone running TurboGears could try them out and let me know if they work, I'd appreciate it. You can get both of them through easy_install or at projects.dowski.com. Christian http://www.dowski.com
[TurboGears] Re: Breaking change coming for those using other template engines!
E.X.C.E.L.L.E.N.T. I mean it. Last days I sent a mail to cherrypy-users ML with a link to TurboStan and a bare CP+Stan sample. I somehow hacked a bit on extending Buffet with Stan but it choked on a eval() call (seems eval() doesn't work the same inside a simple def method as inside a class method...) Then I saw fast pace upgrades to TurboStan. Good but more work to keep in sync with Buffet. You solved the PB by keeping everybody in sync :-) Kevin Dangoor wrote: Christian Wyglendowski and I have been talking about the overlap between Buffet (his CherryPy template filter) and TurboGears' template plugin support. What we've ended up with is a slightly modified interface that allows Buffet and TurboGears to use the same plugins for rendering templates. Even better, these plugins have no ties at all to TurboGears, Buffet or CherryPy. They can be used by anyone who wants to support multiple template engine rendering based on a dict. The next commit I do (it looks like 459) is going to: 1) break out Kid into a plugin that is listed in install_requires 2) break existing template plugins 3) include a revision to TurboCheetah to fix it The authors of the Stan and ZPT plugins are aware that this change is coming. If you're currently using one of these plugins, you'll want to hold off on updating past 458 until there is an update. (I'm sure the authors of those plugins would be happy to have a patch to fix the plugin... it's a fairly minor change that mostly revolves around breaking the ties to turbogears and cherrypy.) Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com signature.asc Description: OpenPGP digital signature
[TurboGears] Re: Breaking change coming for those using other template engines!
Leandro Lucarella wrote: Kevin Dangoor, el viernes 6 de enero a las 12:27 me escribiste: Christian Wyglendowski and I have been talking about the overlap between Buffet (his CherryPy template filter) and TurboGears' template plugin support. What we've ended up with is a slightly modified interface that allows Buffet and TurboGears to use the same plugins for rendering templates. Even better, these plugins have no ties at all to TurboGears, Buffet or CherryPy. They can be used by anyone who wants to support multiple template engine rendering based on a dict. That's just amazing. I love the work TG puts on interoperability and reuse! I really appreciate that too! Kevin obviously gets open source and he and the TG community (all of you) have really moved a number Python projects forward. Thanks for being willing to come together on this templating plugin system and hopefully CherryPy, TG and other projects will benefit from it. Christian http://www.dowski.com
[TurboGears] Re: Breaking change coming for those using other template engines!
TurboStan 0.8 is released to support this change. Cliff Kevin Dangoor wrote: Christian Wyglendowski and I have been talking about the overlap between Buffet (his CherryPy template filter) and TurboGears' template plugin support. What we've ended up with is a slightly modified interface that allows Buffet and TurboGears to use the same plugins for rendering templates. Even better, these plugins have no ties at all to TurboGears, Buffet or CherryPy. They can be used by anyone who wants to support multiple template engine rendering based on a dict. The next commit I do (it looks like 459) is going to: 1) break out Kid into a plugin that is listed in install_requires 2) break existing template plugins 3) include a revision to TurboCheetah to fix it The authors of the Stan and ZPT plugins are aware that this change is coming. If you're currently using one of these plugins, you'll want to hold off on updating past 458 until there is an update. (I'm sure the authors of those plugins would be happy to have a patch to fix the plugin... it's a fairly minor change that mostly revolves around breaking the ties to turbogears and cherrypy.) Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
[TurboGears] Re: Breaking change coming for those using other template engines!
On 1/6/06, Cliff Wells [EMAIL PROTECTED] wrote: TurboStan 0.8 is released to support this change. That was quick! Thanks! Kevin
[TurboGears] Re: Breaking change coming for those using other template engines!
Kevin Dangoor wrote: On 1/6/06, Cliff Wells [EMAIL PROTECTED] wrote: TurboStan 0.8 is released to support this change. That was quick! Thanks! If we don't quit thanking each other so much, we're going to have to hug. xoxo, Cliff
[TurboGears] Re: Breaking change coming for those using other template engines!
Thanks for pointing that out Cliff =) On Jan 6, 2006, at 9:44 PM, Cliff Wells wrote: Kevin Dangoor wrote: On 1/6/06, Cliff Wells [EMAIL PROTECTED] wrote: TurboStan 0.8 is released to support this change. That was quick! Thanks! If we don't quit thanking each other so much, we're going to have to hug. xoxo, Cliff Ronald Jaramillo mail: ronald AT checkandshare DOT com blog: http://www.checkandshare.com/blog
[TurboGears] Re: Breaking change coming for those using other template engines!
Ronald Jaramillo wrote: Thanks for pointing that out Cliff =) Deliberate fishing is grounds for disqualification. Cliff
[TurboGears] Re: Breaking change coming for those using other template engines!
On 1/6/06, Cliff Wells [EMAIL PROTECTED] wrote: Ronald Jaramillo wrote: Thanks for pointing that out Cliff =) Deliberate fishing is grounds for disqualification. Good job, Cliff. We can't let Ronald get away with that. Thanks, Kevin :)
[TurboGears] Re: Breaking change coming for those using other template engines!
Olivier Favre-Simon wrote: I somehow hacked a bit on extending Buffet with Stan but it choked on a eval() call (seems eval() doesn't work the same inside a simple def method as inside a class method...) Olivier, Was this breakage in TurboStan or Buffet? TurboStan uses eval() but it should be self-contained (it's only used to evaluate the Stan expression, and then within its own namespace). If you do use TurboStan with Buffet/CP, I'd like to hear about your experiences and any issues you may run into. I'd also be interested in feedback and suggestions/criticisms from people actually using Stan to help steer development on it. Some of the things I'm going to be considering next are caching of compiled templates, using widgets from Stan, and maybe even implementing a widget or two in Stan, just as a proof-of-concept if nothing else. Cliff
[TurboGears] Re: Breaking change coming for those using other template engines!
Hi Cliff, Not a real breakage, rather an issue with eval() itself. I hacked a quick and dirty prototype based on Buffet-0.4 and TurboStan-0.7. eval() was crying on the CRs in the template file but: - The exact same template data coming from heredoc string rather than read() from file() works fine - The exact same line of code works when used in a class (like TurboStan code or my simple cherrypy example) (See attachement are the 3 modified files.) Due to more urgent issues I lacked time to dig further... And today I saw new versions of TurboStan incoming... Then the ueber-cool announcement of the collaborative attitude between TurboGears+TurboStan and CherryPy+Buffet :-) Olivier. Cliff Wells wrote: Olivier Favre-Simon wrote: I somehow hacked a bit on extending Buffet with Stan but it choked on a eval() call (seems eval() doesn't work the same inside a simple def method as inside a class method...) Olivier, Was this breakage in TurboStan or Buffet? TurboStan uses eval() but it should be self-contained (it's only used to evaluate the Stan expression, and then within its own namespace). If you do use TurboStan with Buffet/CP, I'd like to hear about your experiences and any issues you may run into. I'd also be interested in feedback and suggestions/criticisms from people actually using Stan to help steer development on it. Some of the things I'm going to be considering next are caching of compiled templates, using widgets from Stan, and maybe even implementing a widget or two in Stan, just as a proof-of-concept if nothing else. Cliff Buffet-0.4-Stan-tmp.tar.bz2 Description: application/bzip signature.asc Description: OpenPGP digital signature
[TurboGears] Re: Breaking change coming for those using other template engines!
BTW do you have benchmark results, to compare Stan against say Kid or Cheetah ? Kid is excellent for complex or document-structure-aware pages (py:match and alike) but often overkill for simple templates. I would happily use TurboStan from now for less complex templates if the rendering speed is really here (which I suspect because the template is a python DOM by itself) And yes, caching would be great _with_docs_ I've always been reluctant to use caching with Cheetah because when I started with it the docs were sparse, and now I can't detach from my bad habits :-/ Regards. Cliff Wells wrote: Olivier Favre-Simon wrote: I somehow hacked a bit on extending Buffet with Stan but it choked on a eval() call (seems eval() doesn't work the same inside a simple def method as inside a class method...) Olivier, Was this breakage in TurboStan or Buffet? TurboStan uses eval() but it should be self-contained (it's only used to evaluate the Stan expression, and then within its own namespace). If you do use TurboStan with Buffet/CP, I'd like to hear about your experiences and any issues you may run into. I'd also be interested in feedback and suggestions/criticisms from people actually using Stan to help steer development on it. Some of the things I'm going to be considering next are caching of compiled templates, using widgets from Stan, and maybe even implementing a widget or two in Stan, just as a proof-of-concept if nothing else. Cliff signature.asc Description: OpenPGP digital signature
[TurboGears] Re: Breaking change coming for those using other template engines!
Olivier Favre-Simon wrote: BTW do you have benchmark results, to compare Stan against say Kid or Cheetah ? I have no benchmarks nor really any interest in generating any (and given the wildly different way that Stan works from traditional template systems, it's pretty much apples to oranges anyway; technically Stan isn't a template language, although it makes a great one). Stan is quite fast and I'm certain it compares favorably against the others. Kid is excellent for complex or document-structure-aware pages (py:match and alike) but often overkill for simple templates. I would happily use TurboStan from now for less complex templates if the rendering speed is really here (which I suspect because the template is a python DOM by itself) I don't think Stan is only appropriate for simple things. In fact, I think complex things is where it *really* shines because it's able to so easily push the complexity back into the controller (where it usually belongs) or even express concepts in pure Python without a lot of syntactical compromises. I'm going to get some better examples in the tarball to demonstrate a few of the cool things that can be done to reduce complexity using Stan. Speaking for myself, I don't plan to write another line of XML-based markup again ;-) And yes, caching would be great _with_docs_ I've always been reluctant to use caching with Cheetah because when I started with it the docs were sparse, and now I can't detach from my bad habits :-/ Yes, docs is something I need to address with TurboStan. There's already docs on Stan, but they aren't always easily found, up-to-date nor absolutely clear to someone not familiar with the Nevow way of doing things. Also I've added a couple features that need some more docs. If/when I do the caching, I'll make sure it's covered. Cliff
[TurboGears] Re: Breaking change coming for those using other template engines!
Olivier Favre-Simon wrote:
Hi Cliff,
Not a real breakage, rather an issue with eval() itself.
I hacked a quick and dirty prototype based on Buffet-0.4 and TurboStan-0.7.
eval() was crying on the CRs in the template file but:
Actually I've seen the same thing and never had an explanation for it.
I found myself having to run unix2dos on a file with fragments
copy/pasted from the web (getting a syntax error on blank lines, for
instance). I don't think this should happen, although the idea of an
actual bug in Python is a bit startling to me. AFAIK, Python is
supposed to handle newline translation transparently and I'm not aware
that eval() is an exception to that (although it seems possible that the
type of translation happening is global, at least within the scope of
the current module and that fragments of code within that module must be
of the same line-ending type... but that's just speculation).
One thing I will note about your adapters.py is that from foo import
* doesn't work in the context of a function definition. That is why,
along with the avoidance of namespace pollution, I use __import__ in
TurboStan for getting nevow.tags into the template namespace:
Python 2.4.2 (#1, Oct 16 2005, 16:00:21)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2
Type help, copyright, credits or license for more information.
def foo():
... from stan.tags import *
...
stdin:1: SyntaxWarning: import * only allowed at module level
def foo():
... ns = {}
... __import__('stan.tags', '__all__', ns, ns)
...
This effectively creates a namespace that the Stan template can be
eval()'d in that provides easy access to all the Stan predefined tags
and doesn't stick things like a and p into the outer module's
namespace where they might cause... confusion ;-)
Regards,
Cliff
[TurboGears] Re: Breaking change coming for those using other template engines!
Yes __import__ is much more clean.
other option is importing as T and having T.html, T.body etc. (many
nevow/stan docs use this style)
As I said this was just quickdirty hack to prototype, but now that we
gonna have a super-flexible setup with _real_ template plugins (I mean
really independant of TG / CP / whatever, just relying on the template
engine + entry_points), my code is thing of the past :-)
Cliff Wells wrote:
Olivier Favre-Simon wrote:
Hi Cliff,
Not a real breakage, rather an issue with eval() itself.
I hacked a quick and dirty prototype based on Buffet-0.4 and
TurboStan-0.7.
eval() was crying on the CRs in the template file but:
Actually I've seen the same thing and never had an explanation for
it. I found myself having to run unix2dos on a file with fragments
copy/pasted from the web (getting a syntax error on blank lines, for
instance). I don't think this should happen, although the idea of an
actual bug in Python is a bit startling to me. AFAIK, Python is
supposed to handle newline translation transparently and I'm not aware
that eval() is an exception to that (although it seems possible that
the type of translation happening is global, at least within the scope
of the current module and that fragments of code within that module
must be of the same line-ending type... but that's just speculation).
One thing I will note about your adapters.py is that from foo import
* doesn't work in the context of a function definition. That is why,
along with the avoidance of namespace pollution, I use __import__ in
TurboStan for getting nevow.tags into the template namespace:
Python 2.4.2 (#1, Oct 16 2005, 16:00:21)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2
Type help, copyright, credits or license for more information.
def foo():
... from stan.tags import *
...
stdin:1: SyntaxWarning: import * only allowed at module level
def foo():
... ns = {}
... __import__('stan.tags', '__all__', ns, ns)
...
This effectively creates a namespace that the Stan template can be
eval()'d in that provides easy access to all the Stan predefined tags
and doesn't stick things like a and p into the outer module's
namespace where they might cause... confusion ;-)
Regards,
Cliff
signature.asc
Description: OpenPGP digital signature
[TurboGears] Re: Breaking change coming for those using other template engines!
Olivier Favre-Simon wrote: Yes __import__ is much more clean. other option is importing as T and having T.html, T.body etc. (many nevow/stan docs use this style) Yes, I opted against this as I felt it was unneeded typing and clutter in the templates, especially when I could transparently remove the need for a tag namespace by using a little __import__ trickery. The usage of Stan in TG is somewhat different than for a typical Nevow application, and I felt this more appropriate in this case. That's also the reason I added the inheritance tag: it helps Stan fit better into the TG way of doing things (although I've never been fond of the term template inheritance as I feel it's a bit misleading). As I said this was just quickdirty hack to prototype, but now that we gonna have a super-flexible setup with _real_ template plugins (I mean really independant of TG / CP / whatever, just relying on the template engine + entry_points), my code is thing of the past :-) As it all will be... someday. Cackling evil'ly yours, Cliff
[TurboGears] Re: Breaking change coming for those using other template engines!
On 1/6/06, Cliff Wells [EMAIL PROTECTED] wrote: Actually I've seen the same thing and never had an explanation for it. I found myself having to run unix2dos on a file with fragments copy/pasted from the web (getting a syntax error on blank lines, for instance). I don't think this should happen, although the idea of an actual bug in Python is a bit startling to me. AFAIK, Python is supposed to handle newline translation transparently and I'm not aware that eval() is an exception to that (although it seems possible that the type of translation happening is global, at least within the scope of the current module and that fragments of code within that module must be of the same line-ending type... but that's just speculation). If a text file is going to be evaluated/compiled by Python, the file should be opened with mode 'rU' and not just 'r'. The 'U' turns on the universal newline translation. eval expects input with only \n newlines for line endings. If it encounters a \r (as a result of reading a file in binary mode on Windows, or reading a Windows-created file on a non-Windows system) it will get confused. So in summary, one place you'll get the universal newline support you want is by appending 'U' to the mode of a call to file(). :) -- Matthew R. Scott
