Tavis Rudd <tavis@...> wrote:
> #block and #set / #data are fundamentally different in the
> respect that #block's can contain Cheetah syntax to be
> parsed. The values assigned with #set and #data won't be
Well, you can do "#set $x = $y", yes? That means #set's are parsed.
If #data isn't parsed, it become increasly less useful to me, because
not only is the syntax unappealing, but it's no longer able to express
anything interesting -- i.e., dynamic relationships among attributes.
> On Saturday 25 August 2001 11:14, Ian Bicking wrote:
> > Tavis Rudd <tavis@...> wrote:
> > > * The #set, #data and Ian's #define proposal:
> > I'm unclear about the scope of #set as it relates to
> > inheriting templates. Clarification on this would be
> > nice. My natural intuition would be that #set is just
> > like #data, only a different syntax. However this is not
> > so.
> No, they're different. Think of #data being like the C
> pre-processor's #define. It only happens at compile-time.
> All the #data directives are processed once only at
> compile-time! #set directives are processed per-request at
> run-time. Their analogue is a variable assignment at
> run-time in C.
Oh, I don't know if compile-time seems so good then.
What I'd like is for Cheetah templates to compile to something like a
nice class definition, like maybe:
#define title = 'default title'
#end define htTitle
title = 'default title'
return '<title>' + self.placeholder('title') + '</title>'
return '<title>' + self.placeholder('title') + \
'</title>\n<body>\n' + self.placeholder('htTitle') + \
'\n' + self.placeholder('content') + '</body>\n\n'
Then the structure of the document is exposed very naturally to the
Python side just like the Cheetah side, and subclassing works (I
think) very nicely. Or maybe something like:
#end define htTitle
return 'start' + self.define('htTitle', '<h1>' + \
self.placeholder('title' + '</h1>') + 'end'
def define(self, var, value):
setattr(self, var, value)
I.e., the contents get parsed, and the attribute gets set on the run.
Or, #define htTitle could be implied to be #define htTitle().
Otherwise, I'm not sure how I can do the title/htTitle thing *at all*
through Cheetah. If you see a different way, *please tell me*.
Also, while this doesn't show the most optimal compiling, the overall
performance of this method should be perfectly fine for 99% of all
cases. The only difference from #block, as far as I can see, is one
method call and a little string concatenation, i.e., nothing
> > > ======================================
> > > * The #block directive and its usefulness:
> > >
> > > Ian, I think you're confusing the #block directive as a
> > > means of defining data for template. That's not its
> > > purpose.
> > It's not #block I dislike so much, as much as I felt it
> > was deficient for the pattern I saw in the example sites.
> That's just my way of doing things. It's much more
> efficient computationally and syntactically than using lots
> of methods. Ultimately it's a matter of personal style.
> Cheetah allows you to use #blocks, to do it the way you
> like using #data / #define, or to use #macros if you want
> to do something really weird ;-)
Aren't #macros also compile-time? I really want something that is
runtime. The compile-time/run-time thing is just confusing me. I'm
starting to agree with Chuck about compile-time anything -- I can't
really tell what's what, and it makes things unpredictable (i.e.,
surprising, i.e., bad).
> > Can't you just reuse #block? I.e., like in python, when
> > you override something you just redeclare it.
> Not really, they serve different tasks. #block's must be
> done a particular location in the template definition, whel
> #redefine is location agnostic. And #blocks can be nested,
> while #redefine cannot. Which of those names do you think
> makes most sense?
Maybe #changeBlock, but I'm not sure. "block" doesn't fit into normal
programming terminology, so there's no normal analog. Maybe
#redefine block. #setBlock. Or maybe #redefine becomes #block, and
#block becomes #defineBlock. I think I like something like that