Beefy Boxes and Bandwidth Generously Provided by pair Networks DiBona
We don't bite newbies here... much

rant on = qw(HTML::Mason Embperl Template etc) ;

by princepawn (Parson)
on Nov 09, 2001 at 06:39 UTC ( #124275=perlmeditation: print w/ replies, xml ) Need Help??

praise to => qw(HTML::Seamstress) ;

HTML::Mason is a feature-packed web application development framework. Because it has been around for so long, it has had a long time to stamp out bugs and beef up the feature set. Everyone knows how great Mason is. This post assesses the things I don't like about it. But the goal is not to step on anyone's toes, just air my perception of it.

My personal experience with website design is that you generally have two groups of people working on the site. The first group are HTML experts who are experienced in creating attractive looking HTML pages in a quality program such as Dreamweaver or GoLive. The second are Perl Programmerswho have a strong grasp of the Perl language and good at creating re-useable unit-tested scalable Perl code.

My caveat is that all I know about HTML::Mason comes from Chapter 13 of the excellent text "Writing CGI Applications with Perl" and though every other chapter before this one and every other chapter after this one had me shaking my head in awe of their grip of the subject matter. My reading of this chapter had me shaking my head in pity. Note well, that the comments here will apply equally to HTML::Embperl and Template.

Invalid HTML is a Valid Mason Component

On p. 361, we see the following "body_end" component. This is not a typo, and I am leaving NOTHING out:
</center> </td> </tr>

Now, when it is time to tell your HTML designer to edit the look and feel of the page, can he load this into Dreamweaver and do it? No. Instead I guess you would have to:

cat body_head body_end.mason > body_edit.mason
and then when he is done, do a manual edit of the the thing the designer fixed to split it back into two pieces. And the obvious question is: how much independence of operation does this offer your HTML and Perl camps? What if he wants to come in on the weekend and work on the design of the site by himself? Oh ok, I guess you could write a bunch of scripts to demarcate the join points of the files for him so that he can go do his thing and then write something else to split them. And you could do this for every set of things you have splintered into two (or more) files simply because the basic unit of abstraction, abstraction meaning separation of concerns until they need be coupled, is actually a basic unit of Perl-HTML entanglement. And yes, without any further adieu, this last sentence has spurred me into yet another paragraph of rant....

The Perl-HTML Mix is Wrecking WYSIWYG Design for Your Designer

I was nice with that last component. I didn't even start with all the

% if ($x->{rss}->{header}) { <B> $x->{rss}->{header} </b> % }
What if the HTML designer comes in on the weekend and accidentally messes up Perl code and since none of this can be viewed WYSIWIG until it gets loaded into a webserver somewhere and since none of this will now run thanks to an innocent little deletion and since HTML is not separated from Perl, we can't do HTML all by itself our poor little designer is screwed until tech-heavy Ted comes in on Monday morning to fix things up.

Things you get to learn in Mason you already knew in Perl

  • %shared allows variables in a component to be seen by sub-components.... this sounds an awful lot like my's lexical scoping. Any good HTML design program has programmatic re-use and support for cascading information flow. And Perl certainly can use my variables to achieve what this does. So what is boils down to is instead of me doing  my $data I get to learn something new to do the same thing. And worry that he implemented it right because it not Pure Perl. Cool! Wonderful! As if I don't have enough worries after September 11 already. Heap on a few more there, buddy!
  • %cleanup is used when a component exits. Again, HTML does not need cleanup and DESTROY { } has always worked just fine for me thanks.
  • %once is something which makes sure that certain code only gets executed once. Again use has always worked well as nothing is ever used twice in Perl.

    I will stop here but the more you read the Mason/Embperl/Template manual, the more you keep thinking "I can do that in Perl." Why is he creating directives for things I can do in Perl? Why do I need to learn another set of names whose control flow and semantics is somewhat similar to what I already know? Does it make things more powerful to give them new names with  <% around it? It doesn't help the design process because you can't really WYSIWYG anymore. It doesn't help the Perl programmer until he comes up with isomorphisms between these new commands and Pure Perl.

    Components with no namespace control

    Mason components don't have namespaces. That means they are not as reuseable as they could be... or should be! They are simple flat names and nothing more.


    An autohandler is a file which is Mason's version of Apache::Sandwich. It is a way to give a set of pages under a certain directory a consistent look and feel.

    Well, actually, I hired my HTML expert who knows Dreamweaver inside and out to give my pages a consistent look and feel. And they can do it in a snap with it's support for re-usable HTML.

    So thanks, but no thanks. And the dhandler . When a component isn't found, you can create a cool error message. I think I will opt for an Apache ErrorHandler thanks. Reading the Mason docs is almost like reading about the 50th new Linux distribution on slashdot or something.


    I find it interesting that we dont have an XML::Mason or an XML::Embperl or anything like that. It is fascinating that no one from those camps got the idea that it would be neat to mix XML and Perl but instead in all cases Perl code processes XML and generates new XML.

    I find most of Mason to be a cloak for the same things I could do in Perl. I find that Mason prohibits independant design, and more importanly redesign by HTML experts. I also find that it makes the HTML harder to read.

    I have my own HTML generation framework, HTML::Seamstress which is quite unique in it's approach to coupling HTML and Perl while allowing each to maintain their necessary integrities - unit testable, isolated object-oriented Perl and WYSIWIG, unadulterated HTML which leverages the re-use capabilities of HTML design programs instead of manually picking apart HTML to force it into Mason component libraries.

    Now, I don't support everything that Mason supports yet. And I never intend to support with anything other than pure calls to other major CPAN modules.

  • Comment on rant on = qw(HTML::Mason Embperl Template etc) ;
    Select or Download Code
    Re: rant on = qw(HTML::Mason Embperl Template etc) ;
    by Masem (Monsignor) on Nov 09, 2001 at 07:20 UTC
      It's neigh impossible to separate perl and HTML completely cleanly, where the HTML designer never has to consider what is coming from perl, nor the perl programmer has to consider what he needs to provide to the designer. At some point, you have to make a concession in the HTML template that you have something coming from perl.

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

    HTML and Perl need not commingle in the least bit
    by princepawn (Parson) on Nov 09, 2001 at 07:59 UTC
      Every once in a while someone proposes yet another solution that tries to separate them,
      One I am not sitting on my ass and proposing. I have a viable (yet alpha-stage) HTML templating framework, HTML::Seamstress up for comparision on the very criticisms I raised again Mason in this post. Download it and see for yourself

      but at SOME point there's got to be a comingling of the code.
      Two This is not a true statement. Please see this node for data to the contrary.
        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"> @
        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 - || "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.

    Re: rant on = qw(HTML::Mason Embperl Template etc) ;
    by lachoy (Parson) on Nov 09, 2001 at 08:49 UTC

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

      M-x auto-bs-mode

    Re: rant on = qw(HTML::Mason Embperl Template etc) ;
    by Maclir (Curate) on Nov 09, 2001 at 09:31 UTC
      While I have yet to digest your complete "rant", I must take exception to your assertion:
      in a quality program such as Dreamweaver or Frontpage
      I am sorry, but the words "quality" and "Frontpage" are mutually exclusive. Dreamweaver (and most WYSIWYG HTML tools) add so much cruft and overhead to pages it is beyond a joke.
        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?

        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.

        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.
    Re: rant on = qw(HTML::Mason Embperl Template etc) ;
    by ajt (Prior) on Nov 09, 2001 at 14:01 UTC
      ++ to you!

      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

    Re: rant on = qw(HTML::Mason Embperl Template etc) ;
    by brother ab (Scribe) on Nov 09, 2001 at 15:03 UTC

      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.

      -- brother ab
    Re: rant on = qw(HTML::Mason Embperl Template etc) ;
    by count0 (Friar) on Nov 09, 2001 at 23:41 UTC
      What about HTML::Template? Of all these types of modules for separating HTML from Perl, this seems to be the most successful at it (IMO).

      HTML::Template templates even work with WYSIWYG editors. (when wrapped in html comments: <!-- <TMPL_VAR NAME="foo"> --> for example)
      The html designer only has to worry about a small number of extra tags, which can be easily documented. These tags are even very non-Perl'ish, and eye-friendly to your average HTML guy/gal.

      So, what is it about HTML::Template that isn't bringing it to the horizon?
        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();

        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>

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

        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 );
          And you'll be good to go.

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

    Log In?

    What's my password?
    Create A New User
    Node Status?
    node history
    Node Type: perlmeditation [id://124275]
    Approved by root
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others making s'mores by the fire in the courtyard of the Monastery: (13)
    As of 2014-04-16 20:29 GMT
    Find Nodes?
      Voting Booth?

      April first is:

      Results (434 votes), past polls