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
[download]

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

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

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>
[download]

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>
[download]

I'd aim for something like:

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

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 - mneylon-pm@masemware.com || "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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.