[Petal] Problems with HTML Parser

[Jean-Michel Hiver]

On Thu 08-Aug-2002 at 10:58:03AM -0400, William McKee wrote:
> On 8 Aug 2002 at 12:28, Jean-Michel Hiver wrote:
> > I think in the near future Petal is going to feature pluggable
> > canonicalizers... The current one is going to be renamed
> > Petal::Canonicalizer::XML and I'll write a Petal::Canonicalizer::XHTML.
> 
> Hmm, I guess I don't understand very well the role of the canonicalizer. I 
> thought the canonicalizer rewrote the petal tags just before the template 
> was parsed. Do I have the order reversed?

The role of the canonicalizer is to rewrite Petal templates using
exclusively the <?petal:var name="..."?> syntax. It also outputs the
HTML tags.


> I did a bit more investigating of the HTMLWrapper library after my email 
> and it looks like the problem with the closing tags and the quoted CSS 
> properties is due to not enough intelligence in that library. How is 
> creating a canonicalizer for each input type going to fix the problems 
> we're seeing?

It won't fix the CSS properties bugs, but I can tell that canonicalizer
to output a <br /> rather than a <br></br>.

You have to understand that XHTML is a kind of hackish HTML that has
been designed to be backwards compatible with web browsers. <br></br> is
perfectly valid XML, however it's not valid XHTML because most browsers
would interpret it as two <br>'s.

In other words, XHTML is a very narrow subset of XML, with plenty of
special cases for backwards compatibilty. The problem currently is that
Petal is treating as generic XML. Hence the <link ...></link> problem
for instance.


> > There will be an extra global variable for the output.
> 
> This is an interesting idea. I wonder if adding this ability to a template 
> library is the appropriate place.... In a sense, Petal is becoming an 
> application instead of a template library. I've been meaning to look into 
> AxKit because I think it provides this kind of capability that I've been 
> wanting to have available to my web apps. I'm not trying to discourage the 
> idea, just trying to flesh out the big picture.

Yeah, you have to draw a line... AxKit is about pipelines, Petal is
about templating. At some point I want Petal to become a nice
alternative to XSLT, albeit less powerful. Petal handlers could then be
inserted in the AxKit pipeline.

But before, the only thing I want is to get something functional and
squash as many bugs as I can.


> > Because by default Petal should be able to template all kinds of XML
> > (Voice XML, RDF, RSS, SVG...) and not just HTML.
> 
> At present, it just outputs HTML, right? This would indeed be a valuable 
> library when you add these capabilities! It's easy to use (unlike Template 
> Toolkit and AxKit), does not embed logic into the templates (unlike Mason, 
> PHP, *SP, etc) and does not lock you into any specific application 
> environment.

Petal has been designed from the ground up to process any kind of XML.
Therefore if you want to write SVG templates with Petal, you can.
Adding the HTML parsing / output capability is just a hack! I thought it
was better to implement a somewhat acceptable, generic behavior and then
be more specific... 

Anyway, as I started to use the library myself I have seen bugs stacking
up in my petal list folder and I need to do something about it, so I
guess I'm not going to wait until tomorrow :-)

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