in reply to Experiences With Mason
My experiences with Mason (which I like quite a bit):
If you're careful with your coding style, it's not too hard to achieve a separation of perl and html with Mason. You can write Mason components that seem like html to the html monkeys, so they don't feel disenfranchised. As other people have mentioned, keeping as much of your code as possible in modules is key -- for one thing, it makes it very easy to write stand-alone tests of the code.
Just working on projects on my own, I feel the strong temptation to move all the content into the database, so I end up writing very few mason components -- you can do a lot with an autohandler and a dhandler and a header and footer component.
Of course, the down side of working this way is you're also going to need some CMS-features to edit the content in the database, and how much time do you want to put into reinventing Bricolage? Bundle::Bricolage
Some technical hints:
Take a few minutes to wrap your brain around the "autohandler" and "dhandler" concepts. A "dhandler" is called if the request doesn't find what it's looking for, an "autohandler" is called after something is found, but before evaluating it. A typical request cycle for me is a request comes in for something that's not on the filesystem, so the dhandler takes it, then Mason backs-up and finds the autohandler, which calls my header component, then does a "call_next" to insert the material returned from the dhandler, after which the autohandler calls my footer component to finish the generated page.
By the way, getting Mason to deal with empty directories correctly is a minor headache. I strongly suggest reading this page from the wiki: HandlingDirectoriesWithDhandlers
|
|---|