Cheetah: Python-Powered Template Engine

On Wed, Jul 31, 2002 at 08:39:24PM -0700, Greg Czajkowski wrote:
> I wanted to know why locals() are never added to the
> searchlist for block directives?

Because they're local variables.  We never specifically decided against
doing this, but it does violate the separation of data rule of
procedural and OO programming.  A function should know nothing about its
environment (and the environment should know nothing about the function)
except the arguments passed in and the result passed out.  Although
of course both have access to "global" data (the searchList, 'self' and
global variables).  

> In the following code shouldn't I be able to use $i
> without declaring it global?
> 
> from Cheetah.Template import Template
> print Template(source="""
> #for $i in range(10)
> #block testblock
> testing $i
> #end block
> #end for
>     """)

That would work for a Python program in that structure, provided it were
run on a recent version of Python that does nested scoping.  But the
Cheetah compiler pulls the #block out and puts it in a method at the
same level as the main method (not nested inside the main method), so
nested scoping does not apply.

> BTW. I understand the implementation behind #block, 
> can *my* local implementation be changed to
> temporarily add the locals() to the called testblock
> function's searchList? And then they would be removed
> right after?? something like
> 
> self._searchList.addToSearchList(locals())
> self.blockName() # Calls the created functions
> self._searchList.pop()

You can do that if you want.  You'd have to remember to redo it every
time you recompile the template though.  Or write a script that does all
the search and replace in one step.

But the "proper" answer would be to pass the needed values as
arguments.

Perhaps if you describe more where the variables come from,
how many there are per method, and how dynamic they are (both the
values and the variable names), we can come up with another way
of doing it.

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

On Wed, Jul 31, 2002 at 09:33:05PM -0700, Mike Orr wrote:
> On Wed, Jul 31, 2002 at 08:39:24PM -0700, Greg Czajkowski wrote:
> > In the following code shouldn't I be able to use $i
> > without declaring it global?
> > 
> > from Cheetah.Template import Template
> > print Template(source="""
> > #for $i in range(10)
> > #block testblock
> > testing $i
> > #end block
> > #end for
> >     """)
> 
> That would work for a Python program in that structure, provided it were
> run on a recent version of Python that does nested scoping.  But the
> Cheetah compiler pulls the #block out and puts it in a method at the
> same level as the main method (not nested inside the main method), so
> nested scoping does not apply.

In case it isn't clear, there are several kinds of scoping.

"nested lexical scoping" means that if a function is defined inside
another block of code, it can see the variables in that block.  That's
what Python's nested scoping is, and what Perl's "my" variables are.

"nested dynamic scoping" means that when a function is called, it
can see the variables in its caller, no matter where the calling
code is physically defined.  Python does not have this.  Perl
variables defined without "my" do this, but their use is depreciated.

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

On July 31, 2002 08:39 pm, Greg Czajkowski wrote:
> Hi all,
>
> I wanted to know why locals() are never added to the
> searchlist for block directives?
> In the following code shouldn't I be able to use $i
> without declaring it global?
>
> from Cheetah.Template import Template
> print Template(source=3D"""
> #for $i in range(10)
> #block testblock
> testing $i
> #end block
> #end for
>     """)
>
> BTW. I understand the implementation behind #block,
> can *my* local implementation be changed to
> temporarily add the locals() to the called testblock
> function's searchList? And then they would be removed
> right after?? something like
>
> self._searchList.addToSearchList(locals())
> self.blockName() # Calls the created functions
> self._searchList.pop()

I'm not sure why you would want to do that.  It's simpler and cleaner to =
do=20
something like this:

from Cheetah.Template import T
print T("""
#def testBlock($i)
testing $i
#end def
#for $i in $range(10)
$testBlock($i)
#end for
""")

Tavis

I have a vanilla cgi template in which I want to access the cgi parameters
and I am stumbling on scoping.

At the top of the template (after importing cgi) I have:
#set global $form = $cgi.FieldStorage()

and then in the body of my template I have
$form.getFirst("foobar")

At run time I get NameMapper.NotFound: form

Now even if there is something that is predefined to help me with CGI
headers (I haven't been able to make the docs from the tex source yet - but
feel free to set me straight) I would still like to understand the scope of
"#set" and "#set global"

sosman

Hi All,

Is there a recommended way of internationalizing templates.

The easiest way I've come up with is to set internationlized strings
using #set then
Using the $string.

Eg. #set $aString = _("This will be translated")

Thanks

Huy

This works.  Note that You should run pygettext on the Cheetah-generated =
=2Epy=20
files rather than on the .tmpl files.
Tavis

On August 6, 2002 10:35 pm, Huy Do wrote:
> Hi All,
>
> Is there a recommended way of internationalizing templates.
>
> The easiest way I've come up with is to set internationlized strings
> using #set then
> Using the $string.
>
> Eg. #set $aString =3D _("This will be translated")
>
> Thanks
>
> Huy
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Cheetahtemplate-discuss mailing list
> Cheetahtemplate-discuss@...
> https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss

Is there not a better way ?

Tavis Rudd wrote:

>This works.  Note that You should run pygettext on the Cheetah-generated .py 
>files rather than on the .tmpl files.
>Tavis
>
>On August 6, 2002 10:35 pm, Huy Do wrote:
>  
>
>>Hi All,
>>
>>Is there a recommended way of internationalizing templates.
>>
>>The easiest way I've come up with is to set internationlized strings
>>using #set then
>>Using the $string.
>>
>>Eg. #set $aString = _("This will be translated")
>>
>>Thanks
>>
>>Huy
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>Cheetahtemplate-discuss mailing list
>>Cheetahtemplate-discuss@...
>>https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
>>    
>>
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>Cheetahtemplate-discuss mailing list
>Cheetahtemplate-discuss@...
>https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
>  
>

On August 6, 2002 11:53 pm, Huy Do wrote:
> Is there not a better way ?

Not that I can think off.  The pygettext tool is built to parse Python fi=
les=20
not Cheetah files, although it might scrape by if you stick with single l=
ine=20
strings.

> Tavis Rudd wrote:
> >This works.  Note that You should run pygettext on the Cheetah-generat=
ed
> > .py files rather than on the .tmpl files.
> >Tavis
> >
> >On August 6, 2002 10:35 pm, Huy Do wrote:
> >>Hi All,
> >>
> >>Is there a recommended way of internationalizing templates.
> >>
> >>The easiest way I've come up with is to set internationlized strings
> >>using #set then
> >>Using the $string.
> >>
> >>Eg. #set $aString =3D _("This will be translated")
> >>
> >>Thanks
> >>
> >>Huy
> >>
> >>
> >>
> >>-------------------------------------------------------
> >>This sf.net email is sponsored by:ThinkGeek
> >>Welcome to geek heaven.
> >>http://thinkgeek.com/sf
> >>_______________________________________________
> >>Cheetahtemplate-discuss mailing list
> >>Cheetahtemplate-discuss@...
> >>https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss
> >
> >-------------------------------------------------------
> >This sf.net email is sponsored by:ThinkGeek
> >Welcome to geek heaven.
> >http://thinkgeek.com/sf
> >_______________________________________________
> >Cheetahtemplate-discuss mailing list
> >Cheetahtemplate-discuss@...
> >https://lists.sourceforge.net/lists/listinfo/cheetahtemplate-discuss

On August 6, 2002 04:28 am, Paul Sorenson wrote:
> I have a vanilla cgi template in which I want to access the cgi paramet=
ers
> and I am stumbling on scoping.
>
> At the top of the template (after importing cgi) I have:
> #set global $form =3D $cgi.FieldStorage()
>
> and then in the body of my template I have
> $form.getFirst("foobar")
>
> At run time I get NameMapper.NotFound: form

That should work.  Is it possible that the #set global line isn't being=20
executed before the $form.getFirst line?  If you're still stuck on it sen=
d me=20
your .tmpl files and I'll take a closer look.

> Now even if there is something that is predefined to help me with CGI
> headers (I haven't been able to make the docs from the tex source yet -=
 but
> feel free to set me straight) I would still like to understand the scop=
e of
> "#set" and "#set global"

There's little bit on it at:
http://cheetahtemplate.org/docs/users_guide_html/users_guide.html#SECTION=
000840000000000000000

Tavis

On Tue, Aug 06, 2002 at 11:58:10PM -0700, Tavis Rudd wrote:
> On August 6, 2002 11:53 pm, Huy Do wrote:
> > Is there not a better way ?
> 
> Not that I can think off.  The pygettext tool is built to parse Python files 
> not Cheetah files, although it might scrape by if you stick with single line 
> strings.

We've tried to think of better ways to handle multilingual documents
but haven't come up with any.

Some documents may work best with parallel templates, one for each
language.  Others may be able to get by with #block methods and
subclasses for the different languages.

Beyond that, we'd need somebody who uses multilingual documents to
tell us what would make their life easier.  

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

I usually use the 'containment' method to integrate into Webware, but I would like to try
'inheritance'.

It seems to me that the tmpl files need to be in the same directory as the compiled files.
Currently I have a template directory w/ just tmpl files in it.  I was playing with
editing the __CHEETAH_src__ to something like
__CHEETAH_src__ = '../templates/login.tmpl'
but that would get changed every time I cheetah compile.

so I would like a Directory Structure of
www/                         # Web root directory.
    site1.example.com/       # Site subdirectory.
        apache/              # Web server document root (for non-servlets).
        www/                 # WebKit document root.
           index.py          # http://site1.example.com/
           servlet2.py       # http://site1.example.com/servlet2
        lib/                 # Directory for helper classes.
           Site.py           # Site superclass ("#extends Site").
           Site.tmpl         # Source for above.
           Logic.py          # Logic class inherited by some template.
        tmplates/
->           index.tmpl        # Source for www/index.py above.
->           servlet2.tmpl     # Source for www/servlet2.py above.
        webkit.config        # Configuration file (for WebwareExperimental).
        Webware/             # Standard Webware's MakeAppWorkDir directory.
           AppServer         # Startup program (for standard Webware).
           Configs/          # Configuration directory (for standard Webware).
               Application.config
                             # Configuration file (for standard Webware).
My client is hiring a full time "junior" webmaster to maintain my site and I would like to
restrict his access to just the tmpl files.

Thank You,
-Aaron Held

On Wed, Aug 07, 2002 at 09:24:42AM -0400, Aaron Held wrote:
> It seems to me that the tmpl files need to be in the same directory as
> the compiled files.

... only because the 'cheetah' command assumes that's what you want.
If you compile the templates one at a time, you can compile to stdout and
place it anywhere.  E.g., in a Makefile:
	cheetah compile templates/index.tmpl >| www/index.py

I'm working on a revamp of the 'cheetah' command this month.
One enhancement is to add -i EXT and -o EXT for the input and output
extensions respectively.  We could also have -idir DIR and -odir DIR
for the input and output directories.  The tradeoff is it's more
complicated to explain the options.  On the other hand, I have 
sometimes wished for better support for having the templates out of
the way in another directory.  I just didn't think anybody else cared.

> Currently I have a template directory w/ just tmpl files in it.  I was
> playing with
> editing the __CHEETAH_src__ to something like
> __CHEETAH_src__ = '../templates/login.tmpl'

Where is __CHEETAH_src__?

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

From: "Mike Orr" <iron@...>
> place it anywhere.  E.g., in a Makefile:
> cheetah compile templates/index.tmpl >| www/index.py

If I do this then I get an error since the template class cannot check the tmpl file to
see if it has been edited.

> I'm working on a revamp of the 'cheetah' command this month.
> One enhancement is to add -i EXT and -o EXT for the input and output
> extensions respectively.  We could also have -idir DIR and -odir DIR
> for the input and output directories.  The tradeoff is it's more
> complicated to explain the options.  On the other hand, I have
> sometimes wished for better support for having the templates out of
> the way in another directory.  I just didn't think anybody else cared.

This would be excellet!

For now I am using 'containment' w/ precompiled templates and its working out OK

Thanks,
-Aaron Held

On Thu, Aug 08, 2002 at 11:42:26AM -0400, Aaron Held wrote:
> From: "Mike Orr" <iron@...>
> > place it anywhere.  E.g., in a Makefile:
> > cheetah compile templates/index.tmpl >| www/index.py
> 
> If I do this then I get an error since the template class cannot check
> the tmpl file to see if it has been edited.

That sounds like some automatic recompilation voodoo is getting in the
way.  Tavis?  Would this affect all cases of the .tmpl file not being
in the same directory?  Should we store the location of the .tmpl file
in the .py file (perilous)?  Or should we skip updating if the .tmpl
file is not in the same directory?

-- 
-Mike (Iron) Orr, iron@...  (if mail problems: mso@...)
   http://iron.cx/     English * Esperanto * Russkiy * Deutsch * Espan~ol

On August 8, 2002 11:01 am, Mike Orr wrote:
> On Thu, Aug 08, 2002 at 11:42:26AM -0400, Aaron Held wrote:
> > From: "Mike Orr" <iron@...>
> >
> > > place it anywhere.  E.g., in a Makefile:
> > > cheetah compile templates/index.tmpl >| www/index.py
> >
> > If I do this then I get an error since the template class cannot chec=
k
> > the tmpl file to see if it has been edited.
>
> That sounds like some automatic recompilation voodoo is getting in the
> way.  Tavis?  Would this affect all cases of the .tmpl file not being
> in the same directory?  Should we store the location of the .tmpl file
> in the .py file (perilous)?  Or should we skip updating if the .tmpl
> file is not in the same directory?

Let's remove the automatic recompilation stuff completely.  I was doing s=
ome=20
testing last week and realized that regenerating a superclass template wi=
ll=20
overwrite the subclass overrided methods.  This isn't desirable!!  I've=20
disabled it by default for the time being (in the cvs).  It also lead to =
some=20
odd race conditions when used in combination with the ImportHooks I'm wor=
king=20
on.

The ImportHooks and ServletFactory will make the auto-recompile code obso=
lete=20
anyway.

> Let's remove the automatic recompilation stuff completely.

Thanks!  During testing I stay in my webkit directory and every time I
change a .tmpl file I do a Ctrl-C to kill AppServer and then run
"cheetah -c ../www ; ./AppServer".  If cheetah notices that I updated a
.tmpl before I get a chance to re-compile and restart, it tries to
recompile but doesn't know where the .tmpl file came from, even though
it's in the same directory as the .py file (../www).

It also really made me nervous that since webkit doesn't pickup changes
to super classes, automatically re-compiling a sub-class may break the
page until I get a chance to restart webkit.

Just my two coppers.