[Petal] Re: Petal: proposed patch

Jean-Michel Hiver jhiver at mkdoc.com
Mon May 19 14:36:04 BST 2003


> Hi Jean-Michel
> 
> Thanks for writing Petal.  I read an article on Zope's TAL and
> thought the concept was pretty cool.

You're welcome... TAL is way too cool, someone had to do it :)


> I am adding support for Petal templates into one of my projects, but
> have hit a snag with the way Petal options work.  My project runs
> under mod_perl and has a number of modules, each mapped to a different
> directory.  Each module requires a different value for BASE_DIR and
> it's quite possible that each module might need different values for
> INPUT, OUTPUT and possibly other options too.  I know I can use
> local() to isolate the effect of changing globals but that doesn't
> really fit well with my existing design (the options are set in a
> different routine to the one that processes the template).

I see...


> I'm happy to put together a patch to 'fix' Petal, but I thought I'd
> check first whether you approved of the approach and whether you'd
> accept a patch.
> 
> My thinking is that the existing globals would remain and be used as
> default values but the documentation would note that changing the
> globals is a deprecated API.  The new way to set options would be to
> pass them to the constructor like this:
> 
>   my $template = Petal->new( file     => 'products.html', base_dir =>
>   '/var/www/petshop', input    => 'HTML', output   => 'HTML', taint
>   => 1)

I can see a problem with includes. The way Petal handles includes is by
creating a new Petal object on the included file. Look at the _include
subroutine in Petal/lib/Petal/CodeGenerator.pm

Basically I don't think it's impossible to do, but there might be a few
catches here and there.


> These option values would be stored directly in the object hashref at
> the time the object was constructed.  Later, when an option value was
> required, the code would do this:
> 
>   $self->{base_dir}
> 
> Instead of this:
> 
>   $Petal::BASE_DIR

I think it would be even better if you had a method rather than
accessing values directly...

Anyway feel free to hack Petal so that it matches your needs, as long as
it doesn't break backwards compatibility and passes the test suite there
is a strong chance that I'll apply it or at least make it an option :)


> I hope you'll agree that the change is not too elaborate.  If you're
> happy with the proposal as I've outlined it, let me know and I'll put
> togther a patch.

I've CC'ed this message on the Petal mailing list just to know what
everybody else thinks.


Thanks for your interest in Petal,
-- 
Building a better web - http://www.mkdoc.com/
---------------------------------------------
Jean-Michel Hiver
jhiver at mkdoc.com  - +44 (0)114 255 8097
Homepage: http://www.webmatrix.net/


More information about the Petal mailing list