- authohandlers and inheritance make for easy modularization in layouts
- excellent support for caching: you can cache the whole output, or only the tiniest of components for as long as you want
- attributes, methods and dhandlers: you won't fall in love at first sight, but those cuties will make any other templating scheme look dull after a while
- very helpful if you're into using active widgets; HTML::Mason will let you build components that can take care of all their data needs: for example, just build a calendar widget, have it 'use' whatever classes it needs, call it where you need it, optionally pass it some parameters to help it be a bit more useful, and you can forget about what is inside until you need to change it.
- the templating syntax is perl syntax with a couple of HTML-looking tags; that the designers should not need to learn/should be shielded from a programming language is a superstition, I think: it's impossible to have a useful templating scheme without some syntax that the designers will have to learn and deal with, and if they are going to learn a syntax, it could as well be basic perl.
- I am not certain that this was planned, but because it does not integrate with DB abstraction classes or session handling classes etc. and does not deal with anything else but with Controller and View tasks, it helps you _a lot_ to deal with obsolescence, since you can simply use your old Model/DB classes without any problem and replace them in time, and still have an application to run your business on
- for simple applications is very easy to switch from cgi to mod_perl and back; for more complex application it's possible to switch from cgi to mod_perl and back without rewriting the whole application; the same for switching from mod_perl to mod_perl2
- you can use it as a templating engine or as an application framework
- good documentation and helpful (and polite, too: have not been witness to any flame fest in the mailing lists until now) community;
extra pro arguments:
- if your team lead is in love with a particular DB abstraction scheme, s/he cannot use the argument that "HTML::Mason has support for the xyz::class"
- since the dispatch is filesystem based, you can keep the code in small files and if you bork a merge most of the application will still work
- no support for mixing SQL in the template files, so if you manage a project, you don't have to carry a baseball bat with you all the time
- used by Amazon.com: this means it will be actively supported for a some time
- it's not exactly trivial to extend, and the documentation could be a bit more detailed as to what is appropriate to extend
- it is not exactly trivial to share information between arbitrary components; there is $m->notes(), and you can store even objects in that, but I am not yet certain that's a good idea: maybe the documentation should state if it's fine to do it or not
extra con arguments:
- you still have to carry a big baseball bat with you in case some team member is tempted to pass the Apache request object or the Mason request object to some code that's not in the <%init> part of the component and argues that "it's much simpler this way"
- it's not very hyped: in my experience, having HTML::Mason in your CV won't bring you points unless the job description contains "HTML::Mason"