Conclusion

Now, from what I've seen, most template solutions, just like with JSP pages or the like, try to hide what's from perl in HTML comments, such that the designer can build the page without problems. There's got to be an initial session where the perl programmer and the HTML design sit down, and lay out what will go in those comments, but then they can go in their own direction, meeting again when necessary.

I read the Java literature as well, and while there's article after article on JSP and servlets and the like, each one echoes the laments you've given already; you cannot cleanly separate these. Every once in a while someone proposes yet another solution that tries to separate them, but at SOME point there's got to be a comingling of the code.

Maybe what the problem is is not that the templating tools are a problem, but that the way that large groups are designing sites are at fault. You mention that you worry that your HTML wranglers will come in at night, and wreck your template, or changes you make during the day will wreck the hard work the HTML guys have done. Maybe what is needed to have the HTML people and the perl programmers spend more time with each other during the development of pages. Maybe the HTML programmers NEED to understand that some engine is providing the data to them and how that works, and the perl programmers have to provide an API or some 'fixed' expectations of what they will be delivering to the programmers. This way, nearly any template solution will work as long as the envirnoment is working right.

As to your suggestion on an XML template solution, I point out that Template Toolkit 2 is language neutral; while the templating code doesn't merge well with HTML, it can be used to generate any text output, including XML (I believe, even, there's an XML plugin for TT2). <2>

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

This whole discussion of templating systems ranks with editors and operating systems as a matter of style. Clearly, the way Mason does things isn't for you. So it goes. It sure works for lots of other people, so its designers must be doing something right :-)

That said, you might be interested in a Java technology that does much the same thing you discuss but quite a bit cleaner. XMLC allows you to compile an XML (or HTML) document to a Java class, using items specified by 'id' tags as objects in your Java code. No intermingled Java code whatsoever.

The nifty thing about it was that more than any other solution I've seen, the web designers didn't have to know anything about what you were doing in the backend. And because the document is represented as a series of hierarchical objects, you can clone() them, query them for properties and apply those properties to other objects in the document.

For example, one of the most common display elements is a data table with alternating colors. The designer creates the table with a header row and two sample rows for mockup. You grab the colors of the two rows, axe the second row and clone the first row for as many data elements as you require. Once you're done, you can apply the colors to the rows after they've been generated, rather than while you're generating them.

In fact, one of the interesting things this does is get you out of the mindset of having to generate everything all at once in a top-to-bottom fashion as most other solutions require.

Anyway, I bring this up merely to have something else to think about and throw into the mix. As if we don't have enough solutions already :-)

Chris
M-x auto-bs-mode

in a quality program such as Dreamweaver or Frontpage

As a Perl coder, and a Dreamweaver/vim double-teamer, I must correct your assertion. The primary reason I use Dreamweaver is that it doesn't add crap to your HTML; the "RoundTrip HTML" bits in the ads for the product aren't just marketing hype.

It _will_ do some farily legit clean-up, upper-casing tags and the like, but it won't plug in stupid tags, or cram just one more javascript function, unless you tell it to. And you can, from one option screen, turn off everything, leaving your code 100% pristine. This is nigh-impossible in FrontPage, from what I hear (I won't go near THAT app with a 50-foot pole.)

It even offers an option like the HTML Tidy program to clean up Word and FrontPage HTML. For those wanting rapid dev on the HTML side, concentrating on writing Perl code, Dreamweaver works very well.

----Asim, known to some as Woodrow.

Dreamweaver (and most WYSIWYG HTML tools) add so much cruft and overhead to pages it is beyond a joke.

Preach it, brother Maclir. There are designers, and there are HTML jockies (and then there are those of us who are both :). No HTML jockey I know would be caught dead letting FrontPage or DreamWeaver near his markup.
--
man with no legs, inc.

Wow, I thought Dreamweaver was good about this. Certainly it is much better than Frontpage.

But anyway, as long as the browser can display it, I don't care how unacceptable it is to an HTML expert like you...

but tell me something: do you want your HTML split across a bunch of components so that you can no longer edit an HTML document? How would you deal with something like that?

I completely concur re Frontpage. It is a vile piece of dreck with insures that only Frontpage weenies can ever touch that web page again.

As for Dreamweaver... I completely disagree. I started writing HTML eight years ago, and have since tried an assortment of WYSIWYG HTML tools. Dreamweaver is the only one I would even consider using (and do). The level of cleanliness (at least, for the simple to medium-complexity stuff I do) is comparable to that of my own, hand-tuned code. To be sure, it does take some, minor effort of setting it up properly in the first place, and diligence in alt tags and similar Good Code, but those are mostly all things that I'd have to do in vi either. Did I mention that you can directly edit the HTML in DW and it will not second-guess you?

About the worst I'll give you is that it uses <p> and </p> tags, and probably has more whitespace/indentation than I use on my own. For the sake of clarity, I think I can stand that.

Of course, I personally find it really hard to beat the Dreamweaver-Fireworks integration. Vector-based graphics are yummy, and 'Export slices to Dreamweaver,' is totally killer. Sadly, lately it's been more about the pretty pictures than the content. Been bizzy.

About the worst I'll give you is that it uses <p> and </p> tags,

Actually, if you look at the latest XHTML standard, you need the </p> tag to terminate each paragraph, assuming you want you HTML to be compliant.

I can't agree with you enough. While the various technoloies you mention have their strengths, and work fine, the fact that they mix HTML and code like PHP or JSP makes them in my view impure, impracticle and unscaleable.

Screamer in this thread, I am about to write my very own templating module.., raises many of the same issues. I agreed then, and I agree now, that mixed code and markup is bad, and should not be done.

I have built my own application that delivers XSLT like templating, and it does separate code from HTML, you can use any XML aware HTML editor to work on the HTML. It can make calls to any scripting language - though naturally I mostly make calls to Perl. It's designed to be simple, and I'm evaluating if it's worth keeping or upgrading to AxKit which may be a more sensible long term solution.

My humble 2p

If I may add a shameless plug to my humble selfwritten programm w3make...

It takes a tree of XML documents pushes them through an XSLT engine (currently saxon) and yields a whole site of html pages, can copy things around and call more shell commands. Of course it has it's flaws but it comes close to what I feel like maintaining a small- oder midscale site

It is my expression of what I felt about all the systems I looked at when it was -once again- time to relaunch the website of my employer: none of them fitted my visions.

I wrote this small because it is one of those shameless plugs...

Regards...	Stefan
you begin bashing the string with a +42 regexp of confusion

As for HTML designers that use Dreamweaver - for my experience they feel quite comfortable about HTML::Mason. I have explained them that mason-components are like their own Dreamweaver library items, but much more powerfull and they ate this :) Your example of "bad component" could be titled "bad library item" or so because it has nothing mason or even perl specific, it is an example of ugly decomposition of a page.

Be sure, it is possible for designer to learn something about Mason or ColdFusion or ASP or JSP or what-else-those-programmers-use. Don't hide too much from them or they'll lose logic of your application. Yes, they are not just page designers, the are a part of a team that creates something bigger than these pages.

What about HTML::Template?

This is one of those questions that I would give 10 upvotes to if I could. You would think that since I wrote this node giving high praise to HTML::Template that I would have looked at iit harder before embarking on my glory run with HTML::Seamstress

What happened is I read perrin's seminal article on template system comparisons and ran across on called HTML_Tree, which at the time was on CPAN. But he removed his module from CPAN so I wrote an equivalent which was an improvement over it (as I saw it) in a number of ways.

Now, I plan to drop my HTML::Seamstress project and join the HTML::Template camp... I guess I opted for the vi of template systems even though I use Perl and Emacs, which are the swiss-army chainsaws in their respective classes... heheh.

But for the record, seamstress could compile it's template to executable perl programs. Also, seamstress methods are closer tied to HTML::TreeBuilder and HTML::Element so that HTML manipulations were programmatic and structural as opposed to string-based.

Also, I intentionally left out an include statement, so that this would be forced on HomeSite, Dreamweaver, what have you.

But you just have to do things slightly different with HTML::Template. But I feel that HTML::Template does offer what Seamstress offers albeit with a slightly different API. But given it's maturity (my god, the caching features!) and popularity it is best to join that school and continue the war again Template and Mason et al.

actually, I take this back. There is no way I am going to drop HTML::Seamstress based on what I see going on on the HTML::Template mailing list.

forget it. Seamstress or bust

One thing I didn't like about HTML::Template (maybe I just didn't understand it enough to come up with a clean solution) was the following.

I wanted to give the HTML developers a set of variables that they could use. They could pick and choose which of the set they wanted to display. It was a snippet of HTML to display the current weather, so they could show "wind speed", "wind direction", "temperature", "humidity", and so on.... I did something like:

$tmpl = HTML::Template->new('filename' => $TEMPLATE);
$tmpl->param('Temperature' => $current->{'Temperature'});
$tmpl->param('WindDirection' => current->{'WindDirection'});
$tmpl->param('WindSpeed' => $current->{'WindSpeed'});
...
print $tmpl->output();
[download]

and the HTML developers would ideally be able to select from those variables and use them like this:

<TABLE>
<TR>
<TD>
<SPAN CLASS="weather-temp">
<!--TMPL_VAR NAME="Temperature"-->&deg;F
</SPAN>
</TD>
</TR>
</TABLE>
[download]

But actually what I had to do was put ALL the variables into the template, and hide them as a comment, otherwise I would get some error:

<H3>Current weather</H3>
[insert HTML here using a selection of the variables below]

<!--DO NOT REMOVE:<!--TMPL_VAR NAME="Temperature"--><!--TMPL_VAR NAME=
+"PerceivedTemperature"--><!--TMPL_VAR NAME="R
elativeHumidity"--><!--TMPL_VAR NAME="WindDirection"--><!--TMPL_VAR NA
+ME="WindSpeed"--><!--TMPL_VAR NAME="Pressure"
--><!--TMPL_VAR NAME="Visibility"--><!--TMPL_VAR NAME="Icon"--><!--TMP
+L_VAR NAME="IconDescription"-->-->

...
[download]

and I just find that extremely ugly. What's more, if your variables are within a TMPL_LOOP (which I also did a list of news headlines, so in fact I found myself in that situation), then you have to put that blob of commented-out TMPL_VARs inside that loop.

Also I found that somehow this setup was confusing to the HTML designers, so I ended up having to edit the HTML anyway (maybe that's unique to my situation, though), thus smashing my dreams of never having to look at the HTML again.

There is an option to allow exactly what you're looking for. In fact it's one I ALWAYS have set. From the docs:

die_on_bad_params - if set to 0 the module will let you call $template->param(param_name => 'value') even if 'param_name' doesn't exist in the template body. Defaults to 1.

Change your constructor to

$tmpl = HTML::Template->new('filename' => $TEMPLATE,
                            'die_on_bad_params' => 0
                           );
[download]

And you'll be good to go.

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

Every once in a while someone proposes yet another solution that tries to separate them,

but at SOME point there's got to be a comingling of the code.

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

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.