|Syntactic Confectionery Delight|
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 ComponentOn p. 361, we see the following "body_end" component. This is not a typo, and I am leaving NOTHING out:
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:
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 DesignerI was nice with that last component. I didn't even start with all the
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
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 controlMason 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)handlerAn 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.
ConclusionI 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.