Re: HTML and Perl need not commingle in the least bit

[Masem]

I understand what you are trying to do: you want a templating system that is SGML happy, so that most HTML jockies don't have to worry about any code; this is certainly a reasonable consideration.

But I believe that while SGML-compliant HTML templates are great, I still think you cannot completely severe some aspects of the code from the HTML. As an example, I took a look at HTML::TreeBuilder node (the second link above), and see stuff like this:

<td builder="_text::iterator.weight"> @0.1.0.0.5

or going to the docs for HTML::Seamstress, I see this:

<td worker="$s->_text($s->{iterator}->{weight})">  </td>

Great, I could pass these segments to W3C and it will be happy, since there's nothing wrong with extraneous tags. In addition, I would suspect that the HTML writer can build and test their page without processing anything to at least judge what the page will look like before the perl programmer gets their hands on it, particularly in HTML::S's case. But if I was the HTML jockey, I would *still* need to know what the "builder" tag system is and what it implies to design of the page. And if I'm the perl programmer, I've got to make sure that I stick to what I tell that HTML person. Those extra tags and their values, IMO, are still programming code not associated with HTML, and thus there is still comingling going on, but certainly much much less than, say, using CGI's HTML generator functions, or strictly writing the perl app in the templating language of TT2 or HTML::Mason. But even if you look at a simple loop that you'd need to generate a table:

<table supply="$s->_aref($s->load_data)">     
  <tr>  <th>name<th>age<th>weight</th> </tr> 
  <tr iterator="$s->{supply}->Next">
    <td worker="$s->_text($s->{iterator}->{name})">    </td>
    <td worker="$s->_text($s->{iterator}->{age})">     </td>
    <td worker=&quot;$s->_text($s->{iterator}->{weight})">  </td>     
  </tr>   
</table>

You will still need to instruct the HTML person on what, in particular, "$s->{supply}->Next" means. So while you have hidden as much possible perl code from them, it's still there implicitly.

In other words, there's numerous little tricks you can to to continually further split the HTML and the perl (or whatever) coding, however, there always will be a connection between those parts that cannot be severed. And the key to making sure that the HTML and the perl work together along that connection is to make some sort of 'contract' that tells the HTML what to be expecting, no more no less, and what the perl programmers must provide, no more no less. Without this 'contract', then you fall back into the mess of tightly connected perl and HTML code. The contract issue can be easily resolved, certainly, with enough pre-planning and in-progress audits to make sure that the perl programming is prepping what is needed, and the HTML writer is inclued what is given to him. But simply chosing the best template system out there, putting no planning into it, and expecting separate perl and HTML to drop out of it is very naive.

(The same implicit problem exists in any MVC system; in this case, it's the GUI toolkit's API that is the contract that connects all parts with thin, nearly-completely seperable parts, but still connected.)

Now, I will say again that I think using SGML-like markup to embed what you what as indicated by the H::S docs is a good step; again, this should allow HTML developers to wrangle layout without concern for the back end as much as with a system like Mason. And this can be easily applied to XML (also a SGML language), so there's yet another extention. As a suggestion, I would suggest trying to convert the perl-ish code in the tags into something that can be convert back to perl code, but looking more like VBasic. EG: instead of

<td worker="$s->_text($s->{iterator}->{weight})">  </td>

I'd aim for something like:

<td worker="s.text(s.iterator.weight)">  </td>
<!-- or -->
<td worker="s.iterator.weight:text">  </td>

or at least something that mimics JavaScript than perl, because realistically, HTML designers will be more familar with that than perl.

-----------------------------------------------------
Dr. Michael K. Neylon - [e-mail] || "You've left the lens cap of your mind on again, Pinky" - The Brain
"I can see my house from here!"
It's not what you know, but knowing how to find it if you don't know that's important

[princepawn]

You will still need to instruct the HTML person on what, in particular, "$s->{supply}->Next" means.

Mmm, sorta but not really. The process is, the designer creates the dummy page and then I mark it up with tihs Perl code... actually. lachoy's link to XMLC is solid gold... that's the right way to do this. HTML::Seamstress sucks... it's time to do XMLC for Perl...

Now, I will say again that I think using SGML-like markup to embed what you what as indicated by the H::S docs is a good step;

Thanks Masem, I appreciate your word of approval. It makes me feel good that someone sees where I'm coming from on this.

As a suggestion, I would suggest trying to convert the perl-ish code in the tags into something that can be convert back to perl code, but looking more like VBasic.

Yeah, an earlier version of my HTML::TreeBuilder parser did in fact do that via Data::Dref... but just as Dominus states in the pre-amble to his module Text::Template... when people design mini-languages, they are happy with it and then thye realize they need this. Then that. Then the other. Pretty soon they've reinvented Perl with new syntax (paraphrase). And that was what I found out with my dot-dref syntax. It was really cute and it made a lot of the stuff you saw in the SYNOPSIS a lot more clean-looking but lateron it made doing harder things in Perl very awkward.

Again, thanks for your comments.

[perrin]

HTML_Tree == XMLC for Perl, doesn't it?