You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Jean-Michel Hiver <jh...@mkdoc.com> on 2002/07/16 11:41:46 UTC
[ANNOUNCE] Petal 0.1
Hi list,
I am glad to announce the first release of Petal, the Perl Template
Attribute Language module. You will find a rather copious
documentation here:
http://search.cpan.org/doc/JHIVER/Petal-0.1/lib/Petal.pm
It should be pretty stable, however the more people have a play with
it the more likely I am to be aware of potential bugs :-) Tell me what
you think!
Cheers,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
Jean-Michel Hiver - Software Director
jhiver@mkdoc.com
+44 (0)114 255 8097
================================================================
VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
Posted by Robin Berjon <ro...@knowscape.com>.
On Wednesday 17 July 2002 22:06, Rob Nagler wrote:
> Apologies to those who are tired of the *ML vs. Perl debate.
We might get tired if the "vs" in there made any sense.
--
Robin Berjon <ro...@knowscape.com> -- for hire: http://robin.berjon.com/
"Windows may be pretty. And easy. But it has no depth or soul. It's
like the one-night stand of operating systems. You feel cheap after
using it."
-- Steph, in User Friendly
Re: [ANNOUNCE] Petal 0.1
Posted by Perrin Harkins <pe...@elem.com>.
Rob Nagler wrote:
> Apologies to those who are tired of the *ML vs. Perl debate.
I think you're confusing the issue. You're not talking about in-line
Perl vs. templating languages, but rather templating vs. a whole
different concept.
Jean-Michel clearly wants to use HTML-based templates, and wrote his
module specifically for that purpose. When most people talk about
templates for web pages, this is what they have in mind: HTML (or XML or
PDF or whatever) bristled with processing instructions in Perl or a
templating language. It's an easy transition for people who already
know HTML, and provides what most people want from a templating solution.
What Bivio uses could reasonably be called a template, but it's a
completely different animal from the sort of "fill-in-the-blank"
templates that most people mean, and maybe deserves a different name.
It's more like a declarative program, or a configuration file, or CGI.pm
widgets. It is an alternative to traditional templating, but suggesting
that this will fix issues with XML parsing is kind of like saying "you
wouldn't need that winter coat if you lived in Hawaii" -- true, but not
very helpful to someone who lives in Montreal and likes it.
- Perrin
[OT] bOP (was: Re: [ANNOUNCE] Petal 0.1)
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
> > and on top of that I want people to be able to edit
> > templates easily in dreamweaver, frontpage, etc
> > and send templates thru
> > HTML tidy to be able to always output valid XHTML.
>
> If you are an OO-advocate, you would hide the presentation format in
> objects, e.g. Table, String, and Link. This ensures the output is
> valid through the (re)use of independently tested objects. Objects
> also provide a mechanism for overriding behavior.
Well, there is an interesting example on this page:
<input type="text" name="username" size="25">
And the question which is raised is: "How does the graphic designer know
that the display size of a username is 25?".
Here is what you'd write with Petal:
<input type="text" name="username" size="25"
petal:attributes="size user.login_preferred_length;
maxsize user.login_maxlength" />
Then no matter what, the display size of a username would be OK. And the
graphic designer could still move this tag around or change the 'size'
attribute. Better, you could do the following:
<span style="border-style:solid; border-color: blue"
petal:attributes="style default_style">
<input type="text" name="username" size="25"
petal:attributes="size user.login_preferred_length;
maxsize user.login_maxlength" />
</span>
And then the dynamic component would have a blue border when it is
edited (so that the graphic designers knows that this bit of the page is
subject to change) but which would be set to default_style when the page
is processed...
I find it really really horrible to mix HTML and Perl code. So let's say
that some different kind of HTML is needed, it means that I have to
create a new object, subclass an existing widget, etc...
With a templating system, this can all be done by someone who has
knowledge of HTML. Better, with Petal, all the presentational stuff can
be done with a WYSIWYG editor a la frontpage. No need to go and tweak
some strange declarative language.
Actually I don't think these two things are incompatible. After all you
could have 'independently tested objects' which would themselves use
templates... Then you could organize your templates into two kinds:
'system / admin' templates which are related to the 'web application',
you the programmer, would be in charge of maintaining these templates.
'presentational' templates which would just delegate method calls to
your template driven widget library. You'd give these templates for your
graphic designers to play with...
> And here is the HTML-less source:
> http://petshop.bivio.biz/src?s=View.items
Well, sorry, I find it really, really horrible :-)
For example:
image => 'add_to_cart',
field => 'add_to_cart',
alt => 'Add Item to Your Shopping Cart',
or:
cellpadding => 2,
cellspacing => 2,
You are definitely tying your objects with HTML. 'cellpadding' or 'alt'
are _definitely_ HTML-specific, and I don't see why they should be
polluting your business logic.
I see that all the code which you output is html 4.0 transitional. What
if you want to make everything XHTML 1.1 strict? Or if you want to get
rid of all the 'font face' tags?
You want to rewrite all your widget library? Wouldn't it be easier to
have templates which you can send through some kind of HTML fixed /
validator such as tidy?
> Apologies to those who are tired of the *ML vs. Perl debate.
Well, as long as we don't start trolling and that we agree to disagree
we'll be fine :-)
Best regards,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
Jean-Michel Hiver - Software Director
jhiver@mkdoc.com
+44 (0)114 255 8097
================================================================
VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
Posted by Dave Rolsky <au...@urth.org>.
On Wed, 17 Jul 2002, Rob Nagler wrote:
> > Petal lets me do that. If that's not of any use to you, fine. The world
> > is full of excellent 'inline style' modules such as HTML::Mason,
> > HTML::Embperl and other Apache::ASP.
>
> These all work on the assumption that the template is written in HTML.
Actually, neither Mason nor Embperl are HTML-specific these days. Mason
never really was, and Embperl has become much more generic with version 2,
which is in fact now simply called Embperl. Mason will probably changes
its name eventually as well.
-dave
/*==================
www.urth.org
we await the New Sun
==================*/
Re: [ANNOUNCE] Petal 0.1
Posted by Rob Nagler <na...@bivio.biz>.
Jean-Michel Hiver writes:
> > I wonder how much code you would save if you wrote the templates in
> > Perl and let the Perl interpreter do the above.
>
> I recommend that you read this Page:
> http://www.perl.com/pub/a/2001/08/21/templating.html?page=2
Please read the Application Servers section of:
http://www.bivio.biz/hm/why-bOP
> I'm an OO-advocate, I believe in proper separation of logic, content and
> presentation
Moi aussi. What does this have to do with using Perl for business
logic and presentation logic?
> and on top of that I want people to be able to edit
> templates easily in dreamweaver, frontpage, etc
> and send templates thru
> HTML tidy to be able to always output valid XHTML.
If you are an OO-advocate, you would hide the presentation format in
objects, e.g. Table, String, and Link. This ensures the output is
valid through the (re)use of independently tested objects. Objects
also provide a mechanism for overriding behavior.
> Petal lets me do that. If that's not of any use to you, fine. The world
> is full of excellent 'inline style' modules such as HTML::Mason,
> HTML::Embperl and other Apache::ASP.
These all work on the assumption that the template is written in HTML.
If you start with OO Perl, you do not "inline anything", not even
the HTML. Here is an example page:
http://petshop.bivio.biz/items?p=RP-LI-02
And here is the HTML-less source:
http://petshop.bivio.biz/src?s=View.items
Apologies to those who are tired of the *ML vs. Perl debate.
Rob
Re: [ANNOUNCE] Petal 0.1
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
> I wonder how much code you would save if you wrote the templates in
> Perl and let the Perl interpreter do the above.
I recommend that you read this Page:
http://www.perl.com/pub/a/2001/08/21/templating.html?page=2
I'm an OO-advocate, I believe in proper separation of logic, content and
presentation and on top of that I want people to be able to edit
templates easily in dreamweaver, frontpage, etc and send templates thru
HTML tidy to be able to always output valid XHTML.
Petal lets me do that. If that's not of any use to you, fine. The world
is full of excellent 'inline style' modules such as HTML::Mason,
HTML::Embperl and other Apache::ASP.
After all, TIMTOWDI :-)
Regards,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
Jean-Michel Hiver - Software Director
jhiver@mkdoc.com
+44 (0)114 255 8097
================================================================
VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
Posted by Rob Nagler <na...@bivio.biz>.
Jean-Michel Hiver writes:
> My only problem deals with template caching. Currently Petal does the
> following:
>
> * Generate events to build a 'canonical' template file
> * Convert that template file to Perl code
> ** Cache the Perl code onto disk
> * Compiles the Perl code as a subroutine
> ** Caches the subroutine in memory
I wonder how much code you would save if you wrote the templates in
Perl and let the Perl interpreter do the above.
Sorry, I know this doesn't help you answer your question, but by
eliminating XML from the design, the debate about SAX vs XML::Parser
would be irrelevant. Your code would run faster, and you would need
fewer 3rd party APIs.
Rob
Request object availability in .htaccess
Posted by Rodney Broom <mo...@rbroom.com>.
Hi all,
I've got some Perl code in an htaccess file to choose some configuration based on client IP. The code starts with $r = Apache->request. The first request that gets handled by a server instance fails to get the request object (the call succeeds but returns undef). Subsequent requests to that server instance work properly. Any thoughts?
---
Rodney Broom
President, R.Broom Consulting
Re: [ANNOUNCE] Petal 0.1
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 17 Jul 2002, Jean-Michel Hiver wrote:
> My only problem deals with template caching. Currently Petal does the
> following:
>
> * Generate events to build a 'canonical' template file
> * Convert that template file to Perl code
> ** Cache the Perl code onto disk
> * Compiles the Perl code as a subroutine
> ** Caches the subroutine in memory
>
> Cache is kept fresh using the template file mtime() information.
>
> If I had a SAX event parser, then maybe caching could be a bit
> troublesome?
If you could skip the whole "perl code" part you could use
XML::Filter::Cache (a SAX caching filter) as a cache rather than worrying
about a built in one.
Sorry for getting off topic for this list though. Just trying to pass
around the SAX kool aid ;-)
--
<!-- Matt -->
<:->Get a smart net</:->
Re: [ANNOUNCE] Petal 0.1
Posted by Jean-Michel Hiver <jh...@mkdoc.com>.
> I'm curious though, why you've chosen to implement it as a handler for
> XML::Parser rather than as a SAX Handler (or even better, a Filter)? What
> SAX buys (among other things) is the ability for folks to invisibly use
> whatever XML parser is installed, including a pure Perl implementation.
>
> Doing Petal as a SAX Filter would mean that it would be totally easy to add
> it to the mix in things like AxKit and custom SAX pipeline publishing
> systems. So, doing complex, multi-stage transformations like
> My::NonXML::SAXGenerator -> Petal -> SomeXSLT -> SomeOtherXSLT come for
> free.
Interesting stuff... And I think it would be quite easy to implement!
At the moment Petal features two XML event generators:
Petal::Parser::XMLWrapper (based on XML::Parser)
Petal::Parser::HTMLWrapper (based on HTML::TreeBuilder)
I suppose I could write a
Petal::Parser::SAXWrapper... it would be quite trivial to generate the
XML::Parser events from that :-)
My only problem deals with template caching. Currently Petal does the
following:
* Generate events to build a 'canonical' template file
* Convert that template file to Perl code
** Cache the Perl code onto disk
* Compiles the Perl code as a subroutine
** Caches the subroutine in memory
Cache is kept fresh using the template file mtime() information.
If I had a SAX event parser, then maybe caching could be a bit
troublesome?
Maybe what I really need would be to write something a bit more generic,
i.e.
my $template = new Petal (
event_generator => $event_generator,
cache_key => $cache_key,
cache_expires => \&coderef
);
I do not have much experience with SAX and pipelines or things, but if
you feel like looking at the code and make sensible architectural suggestions to
make Petal as generic and modular as possible then I'll be quite happy
to implement them :-)
> Anyway, just random thoughts, really. Petal seems nice and it seems a shame
> to lock it in the XML::Parser-based-one-off jail.
Well, it's not *really*. Take a look at Petal::Parser::HTMLWrapper,
you'll see it's pretty straightforward :-)
Oh by the way, Petal 0.2 is out, it fixes a stupid critical bug and a
couple of documentation bugs...
http://search.cpan.org/doc/JHIVER/Petal.0.2/lib/Petal.pm
Best regards,
--
IT'S TIME FOR A DIFFERENT KIND OF WEB
================================================================
Jean-Michel Hiver - Software Director
jhiver@mkdoc.com
+44 (0)114 255 8097
================================================================
VISIT HTTP://WWW.MKDOC.COM
Re: [ANNOUNCE] Petal 0.1
Posted by Kip Hampton <kh...@totalcinema.com>.
At 10:41 AM 07/16/2002 +0100, Jean-Michel Hiver wrote:
>Hi list,
>
> I am glad to announce the first release of Petal, the Perl Template
> Attribute Language module. You will find a rather copious
> documentation here:
>
> http://search.cpan.org/doc/JHIVER/Petal-0.1/lib/Petal.pm
>
> It should be pretty stable, however the more people have a play with
> it the more likely I am to be aware of potential bugs :-) Tell me what
> you think!
Interesting work, cheers.
I'm curious though, why you've chosen to implement it as a handler for
XML::Parser rather than as a SAX Handler (or even better, a Filter)? What
SAX buys (among other things) is the ability for folks to invisibly use
whatever XML parser is installed, including a pure Perl implementation.
Doing Petal as a SAX Filter would mean that it would be totally easy to add
it to the mix in things like AxKit and custom SAX pipeline publishing
systems. So, doing complex, multi-stage transformations like
My::NonXML::SAXGenerator -> Petal -> SomeXSLT -> SomeOtherXSLT come for free.
Anyway, just random thoughts, really. Petal seems nice and it seems a shame
to lock it in the XML::Parser-based-one-off jail.
-kip
Kip Hampton
Perl and XML: http://xml.com/pub/q/perlxml
AxKit: http://axkit.org/
Join Us In San Diego!
http://conferences.oreillynet.com/os2002/
http://conferences.oreillynet.com/cs/os2002/view/e_sess/2533