*My personal vote is for #2 being the default behavior since it follows
Python importing semantics closely (we also have updated our templates
at Slide to avoid the issue Martin Skott describes).=20
*
How do u do this? ie ensure all your 300 templates dont have this issue
cuz we have tons of templates but we havent figured out how to test all the
templates for such corner cases
On Thu, Apr 16, 2009 at 2:34 PM, R. Tyler Ballance <[email protected]> wrote:
> Since this issue has come up (see thread started by Martin Skott) with
> regards to how newer versions of Cheetah are handling the #import
> statement.
>
> In CVS versions of Cheetah (i.e. v2.0.1 and earlier), all #import
> directives were collected and *moved* to the top of the generated Python
> code for the template. This means things like this:
>
> #import sys
> ## This is a crazy template
> #set $foo = 'bar'
> #import cjson
>
> #def method()
> #import simplejson
> #return simplejson.dumps({'foo' : 'bar'})
> #end def
>
> Generates code like this:
>
> import sys
> import cjson
> import simplejson
>
> class test(Template):
> def writeBody(self):
> ## This is a crazy template
> foo = 'bar'
>
> def method(self):
> return simplejson.dumps({'foo' : 'bar'})
>
>
> In Cheetah v2.1.xx this behavior has been changed to support proper
> inline imports (I think the "magic global import namespace" is a bad
> idea and restricts the power of what you can do within Cheetah)
>
> The code above would generate something like this instead:
>
> import sys
>
> class test(Template):
> def writeBody(self):
> ## This is a crazy template
> foo = 'bar'
> import cjson
>
> def method(self):
> import simplejson
> return simplejson.dumps({'foo' : 'bar'})
>
>
>
> There are a couple things at play here, firstly anything outside of a
> defined function, effectively falls into the "default method" which is
> writeBody(). Secondly I think it's important to support inline imports
> the same way Cheetah supports generate scoping of variables.
>
>
> I think the only solution we have is to use a compile-time setting for
> this, it's quite the "damned if you do, damned if you don't" scenario.
>
> The decision to be made between "us" as the community is which we want
> to be the *default* behavior:
> 1: Non-scoping import behavior (2.0.1 and earlier)
> 2: Scoping/inline import behavior.(2.1.0 and later)
>
>
> My personal vote is for #2 being the default behavior since it follows
> Python importing semantics closely (we also have updated our templates
> at Slide to avoid the issue Martin Skott describes).
>
>
> What say ye all? :)
>
> --
> -R. Tyler Ballance
> Slide, Inc.
>
>
> ------------------------------------------------------------------------------
> Stay on top of everything new and different, both inside and
> around Java (TM) technology - register by April 22, and save
> $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
> 300 plus technical and hands-on sessions. Register today.
> Use priority code J9JMT32. http://p.sf.net/sfu/p
> _______________________________________________
> Cheetahtemplate-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
>
>
--
Bidegg worlds best auction site
http://bidegg.com
------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
Cheetahtemplate-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.