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

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

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

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.

(auto|d)handler

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.

Conclusion

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.

In reply to rant on = qw(HTML::Mason Embperl Template etc) ; by princepawn

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.


Syntactic Confectionery Delight
	PerlMonks