Imx Fix in my experience
 
« prev next »

September 25, 2002 7:48 AM


Hey you, learn Mason. MasonHQI'm going to fail in doing justice to Mason here today. It's that great, really. However, it's not for everyone (sane people) and requires some knowledge of Perl. So, are you insane, and know some Perl? After all, one begets the other.

Why is Mason so great? First, if you do know some Perl, Mason can make your web application (or web site) development a lot easier by abstracting out the interface to arbitrary amounts of components. The Perl logic and database advantages should be obvious to anyone reading this here bit rag. The true value (imho, because I am a UI designer/developer) is the UI abstraction. But it's not complete abstraction, and I think that's a good thing.

Here's the description from the developer site...

Mason is a powerful Perl-based web site development and delivery engine. With Mason you can embed Perl code in your HTML and construct pages from shared, reusable components.
It's true! And like I said, not full abstraction is a good thing. Most of the components I work with have Perl at the bottom of the file declaring stuff, referencing a database and making nice and tidy objects for me to reference. We load up an object called "$user" which has all sorts of goodies inside of it such as phone numbers, addresses and titles. Being a JavaScript writer (another job for insane people) I'm used to object hierarchies and extracting values from them to do sleight-of-hand UI tricks. No new concepts to learn!

Another Mason nicety: We have a suite of form element components with other UI elements wrapped around them for formatting in a standardized way. Those components can have data passed into them from other components to populate up the form elements. As in, we pass in the "name" of the element, it's "value" and any onclick/onsubmit handlers. The component that passes in these variables is written in pure Perl/Mason. So, if I have done my job as a Mason and UI developer, I can prevent the Perl coders them from writing ANY UI code. That's good.

I've only scratched the surface here so I'll mention one of the other great things, "dhandlers". The documentation says...

What happens when a user requests a component that doesn't exist? In this case Mason scans backward through the URI, checking each directory for a component named dhandler (``default handler''). If found, the dhandler is invoked and is expected to use $m->dhandler_arg as the parameter to some access function, perhaps a database look up or location in another file system.
The part I really like is the recursion, using the URI, to figure things out. This allows you to create URLs that don't actually exist, but are bookmarkable and will cause Mason to use the dhandler to execute whatever Perl code you want to return whatever you want (be it HTML< XML or even CSV). Bookmarkable resources = web services. mmmmmmmmmmmm, web services...