"Rob Dixon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Todd W. wrote:
> >
> > "Rob Dixon" <[EMAIL PROTECTED]> wrote in message
> > news:[EMAIL PROTECTED]
> > > Todd wrote:
> > > >
> > > > Perl is so slick:
> > > >
> > > > if ( $self->{code} ) {
> > > > $string = $self->{code};
> > > > } else {
> > > > $self->{class}{file}{generator}{tt2}->process(
> > > >
> > $self->{class}{file}{generator}{fmgr}{templates}{CollectionProperty},
> > > > $self,
> > > > \$string
> > > > ) || die $self->{class}{file}{generator}{tt2}->error(), "\n";
> > > > }
> > > >
> > > > Objects created by other objects in the same class heirarchy get a
> > property
> > > > set to a reference to the object that created it. This piece of code
is
> > from
> > > > a code generator that uses Template::Toolkit. $string is returned,
being
> > > > called for in the first place by another method call placed in a
> > > > Template::Toolkit template.
> > > >
> > > > Vive OO.
> > > >
> > > > Todd W.
> > >
> > > Maybe. But I would take at least a couple of minutes
> > > to understand what you've written.
> >
> > I wote that code years ago. I did explain it above. The code above is
part
> > of a source code generator. $string contains programming source code.
The
> > language of the source code depends on a flag being set in an XML file.
I
> > understand it completely. I wrote it.
> >
> > > That's not why Perl is slick.
> >
> > You must have missed the point. ( There was no point to posting it, I
was
> > just rereading some code and thought it looked neat enough to post. But
if I
> > post it and you counter with "That's not why Perl is slick." then you
still
> > missed the point. )
> >
> > You can do what it says above in any language. What I've coded is a
> > high-level implementation of a tree. In JavaScript, for instance,
instead of
> > seperating the properties with "}{" you could just use ".". What makes
perl
> > so cool is the amount of code that I did NOT wite being executed in the
> > above snippet. The ->process() method of a Template::Toolkit object does
> > some serious work.
>
> I'm /still/ missing the point Todd. And because you may be saying
something
> interesting I'm asking again :)
Notice the call to ->process(). The method is called through a property (
read: hash value ) of an object somewhere in the object tree. When each
object in my application is created, it gets a property set to the object
( read: reference ) that created it. This means that not only do objects
have access to child methods and properties, but also ancestral ones.
The actual value of the first argument to ->process() in my snippet is found
by a memory lookup ( read: hash value ) that is set during a well defined
initialization phase. What it stores is the filesystem path of a
Template::Toolkit template. The logic that sets that property looks like
this:
# determine templates dynamically. This is so we dont have to hard code
# template names in the program each time a new one is made
opendir(TEMPLATE_DIR, $self->{include_path}) or die("open tmpl dir: $!");
while ( my $file = readdir( TEMPLATE_DIR ) ) {
if ( $file =~ /\.tt2$/ ) {
my($name, $lang) = split( /\./, $file );
$seen{$name}++; # for a sanity check to verify language has a template
if ( $lang eq $self->{generator}{language} ) {
$self->{templates}{$name} = $file;
}
}
}
closedir( TEMPLATE_DIR );
The second argument to ->process() in the snippet is the same object I used
to get to the ->process() method. This means that, if needed, my template
could call the same method being executed right now. Its a simple recursion
interface. An assurance that any given statement of code has access to any
method or property the application layer provides.
The third argument is tells Template::Toolkit where to stick the result of
the ->process() method.
>
> It now looks like you were saying that 'Template::Toolkit' is slick?
>
Among other things. References to hashes and hash objects ( blessed hash
references ) are basically the same thing so you can use both transparently.
This isnt anything particular to perl either though.
>
> At least you've encouraged me to play with the module!
_That_ was my point =0)
Todd W.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
