Re: [Cheetahtemplate-discuss] Fwd: $self?

[Mike M. <mwm...@mi...>]

In <6e9...@ma...>, Mike Orr <slu...@gm...> typed:
> On 10/25/06, Tavis Rudd <ta...@re...> wrote:
> > Case 2: I needed class variables. Not just attributes, but real live
> > variables; basically I needed a value that changed for each instance
> > of the class. I forget exactly what I tried, but I wound up doing:
> >
> > #set $self.instance_counter[0] += 1
> >
> > to get things to change properly.
> 
> Not "class variables"; this is a template instance attribute.

I think I may have left out an important part:

#attr $instance_counter = [0]

I.e. - instance_counter is an attribute of the class the template
compiles to, not of an instance of that class. Or maybe that's what
"template instance attribute" means.

> The value will leak from one template fill to the next, so you'll have
> to intialize it to 0 at the beginning of every fill.  Also, modifying
> template attributes is thread unsafe.

And here's why I said I wanted "class variables" - I *want* the value
to change between fills.  I have nine hosts each running two copies of
the same program with different config files. The programs are
extracting data from something to turn it into rows in a
database. They need to attach an id to each row, with the ids coming
from a different range for each process. The range for a process is
determined by the value of $self.instance_counter[0] at the time the
configuration file is filled.

In fact, that's why I used a one-element list. If I just used
$self.instance_counter, then the #set that increments it would create
a new attribute for the instance instead of incrementing the class
variable. So the next time I filled the class, instance_counter would
start over - not what I wanted.

Thanks for the warning about thread safety. Not an issue for me,
though.

> > One alternative would seem to be #set global, but the scope for that
> > isn't clearly defined. In particular, they don't seem to be inherited,
> What do you mean they aren't inherited?  I tried different
> combinations of setting and printing a 'set global' variable in a
> superclass and subclass, an in superclass and subclass methods, and in
> an #include file, and they all shared the same dict.  '#set global'
> sounds like an ideal solution to your problem.

I checked again, and yup, they are. I'm not sure what I was doing that
created that impression, but I can't recreate it now. Sorry.

	<mike
-- 
Mike Meyer <mw...@mi...>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.