MasonX::Request::HTMLTemplate have been released on CPAN and .. I fail to see the point.
I can understand why somebody may want to use Perl as a templating language - if you are in this camp you may like HTML::Mason (I used to like it but I switched to TT2 now). But using HTML::Mason as a framework to maintain Perl code for anything other than templating tasks is just nonsence. I just don't undestand why. Code in Mason components is harder to unit test than Perl modules, it takes more effort to structure your code - in ordinary Perl you have packages and subroutines, in Mason you can emulate something like this with components and subcomponents but it takes more effort and finally Mason has quite confusing OOP model which may be ok for templates but is not really up to task for anything complex. How can it be easier to put your Perl code in Mason components instead of Perl modules?
I asked myself the exact same thing reading through the Mason book, but this stuff is used plenty by people way more experienced than I am -- there have to be good reasons, even if I don't understand them quite yet. I don't quite have a complete answer in my mind yet concerning the modules question, but the start of it is something like this: If you've got lots and lots and lots of Perl modules, it might be really handy to have a real obvious set that are Mason components to set them off from the rest of any other Perl you do.How can it be easier to put your Perl code in Mason components instead of Perl modules?
I don't think Mason's really about separation from other Perl code so much as it is meant to be a flexible system, but that could be a reason that makes sense.
Re:The Possibilities Boggle The Mind
IlyaM on 2003-07-31T13:02:38
I've used HTML::Mason a lot. In fact I'm still mainting quite complex web site powered by HTML::Mason which I started working on about two years ago. My experience is that putting Perl code for anithing other than HTML generation in Mason components is reciept for disaster. Maintaing Perl modules is much easier than Perl code in Mason components.I think HTML::Mason crowd fails a prey of coolness factor. I cannot explain it why but when I discovered HTML::Mason for first time (it must be around 0.6x version) I though something like that it must be extremely cool to be able to put Perl code in web pages. When you start hack HTML::Mason apps it fills fun because it fills like a very different way. Unfortunally neither I find it to be fun nor I find it be faster to develop than "traditional" way anymore. It fills that Mason is more flexiable system than "ordinary" Perl but it is not. On evidence for this fact I discovered myself is that HTML::Mason is not suited very well for projects where you want to use MVC pattern and it is pain in the butt to unit test HTML::Mason based apps.
Typos
IlyaM on 2003-07-31T14:48:21
s/fill/feel/g:) Re:The Possibilities Boggle The Mind
autarch on 2003-07-31T16:15:07
So put your code in Perl modules. A Mason app with most of it's code in Perl modules will look more or less like a TT app with most of it's code in Perl modules.
The difference, of course, is that you can break the MVC model when you want to. If you want to all the time, then you'll probably have a mess. But I think 100% MVC is pretty bogus. You jump through ridiculous hoops just to generate the data structures that you pass to your templates, which then iterate through the data structure. You end up coding the same loop/conditional logic twice, once in the controller, and once in the template. This hardly seems like an improvement.
As to unit testing, testing web apps in general is tricky. I'm not sure how this is easier with TT than Mason.
But whatever you like best is fine. Everyone's brain works differently, and different things click for different developers. But to suggest that Mason is inherently going to lead to more of a mess than any other system is ridiculous. What leads to a mess is bad development, and that can be done with any tool or language.Re:The Possibilities Boggle The Mind
IlyaM on 2003-07-31T16:50:19
Sorry If I was not clear enough: I was objecting in putting Perl code in Mason components for purposes other than templating.If you strickly put all other Perl code in Perl modules then yes, it is almost same as with TT2 (though personally I think it provides much better syntax but it is another story).
Me too... but, somebody had an itch... and this seems to fix it for them.
Who knows, it may help someone else too.
How can it be easier to put your Perl code in Mason components instead of Perl modules?This is a control issue.
You don't always want to give a web developer the ability to install modules into the "official" web server path... so, putting all of your Perl code into modules becomes non-trivial.
Code in Mason components is harder to unit test than Perl modules...I personally don't think you should be doing unit tests on Mason components.
The parts that need the kind of testing you are talking about should be put in a (Perl) module... and tested in the traditional manner.
The primary purpose of a Mason module (IMHO) should be to output HTML... and that output testing is done via integration testing instead of component testing.
The OOP model is confusing. As far as being up to task for anything complex... all I can really say is that Mason extends Perl.
A lot of people seem to think that MVC is the holy grail of web development... it may be. But, I think that the stateless nature of the HTTP protocol works against that.
Mason is another tool in the web developer's arsenal... and, like many things in an arsenal... it can be very dangerous when mis-used.
The trick is not to mis-use it.
