[Petal] Problems with HTML Parser

[William McKee]

On 9 Aug 2002 at 12:50, Jean-Michel Hiver wrote:
> The role of the canonicalizer is to rewrite Petal templates using
> exclusively the <?petal:var name="..."?> syntax. It also outputs the
> HTML tags.

So does this happen before or after the template is parsed? A simple 
diagram in the docs would be helpful.
 
> > 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>.

Ohh, so it's the canonicalizer code that rebuilds the html. I thought it 
was HTML::TreeBuilder. If the role of the canonicalizer is to rewrite 
Petal template code, why is it rewriting tags? Is its role also to create 
valid XML output?
 
> 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.

Ok, I see your point here.


> 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.

I'm all for alternatives to XSLT. That's a bloody awful language to use 
and seems to me to take us back to the old problem of overlapping logic 
and design. Of course, my experience with XSLT has been minimal, so I may 
not have all the facts correct. It was enough to turn me off.
 

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

Hear! Hear!
 

> 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... 

So really, you're outputting valid xml right now which is what is causing 
the problem with the browsers that don't understand <link></link> tagsets? 
I can see the benefit of adding INPUT and OUTPUT settings which would help 
clear up the confusion while adding the possibility for lots more bugs 
<g>. But if you could provide a flowchart of how Petal processes a 
template and outputs the results, you may improve the chances of getting 
bug smashers helping you out. It seems that the Parser and the 
Canonicalizer may now be doing the INPUT/OUTPUT handling although I'm 
still confused as to which each is doing. It seems to me that the  
Canonicalizer handles the INPUT part right now. Ahhh, that's why you would 
add the Petal::Canonicalizer::XHTML, P::C::XML, etc. modules. Am I getting 
warm? In that case, what module would handle the OUTPUT? 
 
> 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 :-)

Great! I'm ready to have some of the outstanding bugs smashed.

Cheers!
William

-- 
 Lead Developer
 Knowmad Services Inc. || Internet Applications & Database Integration
 http://www.knowmad.com