Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

autarch (914)

autarch
  (email not shown publicly)
http://www.vegguide.org/

Journal of autarch (914)

Saturday May 12, 2007
10:43 AM

State of the Trowel

[ #33260 ]

Wow, the last time I wrote about what's up with Mason was almost two years ago.

So here's the "latest" news ...

Soon after my last update, we released Mason 1.30, which was the culmination of development work that had been going on for about a year or so. The big focus of that release was incorporating various speed enhancements from Amazon.

Since then, the 1.3x series has seen a few more releases, with 1.36 coming any day now. This series has been entirely bug fixes or minor features, and that's not likely to change.

The main reason for this is that Mason is a pretty mature product. It works well for what it's designed to do, and as a templating system it has enough features that we're not scrambling to add a lot more. There are improvements that are worth making, but we're also concerned about backwards compatibility, so we're limited in terms of what we can change.

Historically, Mason has always been more than a templating system. A few years ago, I thought this was great, and I even extended it further with modules like Mason::WebApp.

Recently, Jon Swartz and I have both been trying out Catalyst for new apps. I like it pretty well, and I think Jon does too. We discussed the future of Mason and we both agreed that there's not much point in making Mason a better framework. Catalyst and Jifty just do a better job of this, and there's no point in trying to compete with them, especially since if you like Mason you can use it with either of them (and other frameworks as well).

However, we both still like Mason as a templating language. We talked about what a Mason 2.0 might look like, and agreed that one primary goal would be to separate the templating portion of the system from the framework portion.

I put some notes about this on the Mason HQ site at Mason20Notes. My personal preference would be to simply focus on the templating language portion, and build something suitable for use with Catalyst or Jifty. I'd also like to take this as a chance to break some backwards compatibility. However, there's still no firm plans on whether Mason 2.0 will happen, or exactly what will change.

I think that though Mason is "old" it's still pretty darn good. I haven't seen a new templating system come by that I think looks better, though I am intrigued by Jesse Vincent's Template::Declare. The Mason community is still active, primarily on the mason-users mailing list. It's also still showing up as a desired skill in jobs posted to the Perl jobs site. One interesting thing I've noticed is several UK jobs mentioning Mason, whereas a few years ago it seemed like TT2 had a lock on the UK. I don't think the total # of Mason jobs has changed greatly, but maybe they're moving around.

Ok, see you in two years or so ;)


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

State of the Trowel 17 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I'd really like a "templating only" Mason, which is basically how I use Mason in my web app framework today. It's quite a bother to work-around/deactivate all the framework-like features of Mason that I don't want to use. I do, however, like and use the resolver and the caching, so please keep those features.

    (A final wish for Mason 2.0: more mutable objects: fewer classes that only accept certain values on construction. That drives me nuts :)
  • i am also a big fan of catalyst + mason. but catalyst aside, one feature i implemented that i think would be useful for making mason itself a little more frameworkish is a preamble that checks for a "mycomp.init" component, and if found runs that first, and merges the returned hash with @_. this allowed us to get the %init section out of the .html file, so a index.init could

    <%args> $id </%args>
    <%init>
    my $thing = Thing->new(id=>$id)->load;
    return (thing => $thing);

  • Isn't that the template only portion of Mason? I am not the author nor have I used it.
    • It's a subset of the core Mason syntax, but none of the other nice features like autohandlers, component methods/inheritance, and probably none of the many speed optimization features in Mason.

      Mason 2.0 would be more than just a syntax, it'd also include things like autohandlers, component compilation, etc.

    • Ugh, no. That thing is the worst. Its error detection/recovery/reporting is utterly atrocious. Malformed templates lead to malformed generated Perl – in the best case, you get to read and debug the generated Perl, in the worst cases I’ve had, perl flat-out segfaults. A nightmare.

  • What is the timeframe you are looking at getting it out there into the wild?
    • Hmm, any time between now and never ;)

      My round tuit supply is already quite low. I can't speak for Jon. At this point, it's more of an idea, and I don't Jon and I even agree on the exact details of the plan, so I don't see implementation starting any time real soon.
  • As a long time fan of Mason (I used it at Amazon and now on some personal projects like Free Calorie Tracker [freecalorietracker.com]) trust me when I say you've got far more to gain by moving forward than staying put out of fear of breaking backwards compatibility. Rails breaks stuff constantly, and while people grumble it really only takes a day or two to fix and then you enjoy the enhanced productivity of the new version. Mason is hands down my favorite templating language, handily stomping ASP, JSP and (blech) RHTML or (gag,

  • I'm a big fan of backward compatibility, conservative code changes. When it comes to any interface that other people are relying on, it's not right to jerk them around.

    But I wouldn't be too worried about breaking a few things, as long as there's a good motivation for it, like someone else wrote, and as long as you try to make the transition as smooth as possible and give people plenty of notice.

    We had the big changes in version 1.10, where the Compiler, Interp, etc. objects seemed to come into existence.

    • We definitely will not be putting massively incompatible changes into the HTML::Mason namespace.

      We've long talked about moving the namespace to just Mason, and this seems like a good chance to do so.

      Jon has talked about making a 2.0 version of the framework piece of Mason to go with the Mason 2.0 templating piece. This might be released under the HTML::Mason namespace, but the goal would be to keep the framework 100% backwards compatible. I'm not sure that doing this is even necessary. HTML::Mason 1.x will
  • An idea I had was that the different template languages could collaborate on an ultra-fast templating system that they could all build on. Something like Text::Template, where the object creator gets to choose the delimiter tags. Then HTML::Mason, Text::Template, Template toolkit, and any others could build on top of it. It could have two versions, one in C for speed, and one in Perl for portability (with compatible interfaces, of course).

    Anyway, that's my idea.
    As an additional feature to the above, it'd
    • Mason is more than just a set of start and end tags. It provides certain features that are unique to Mason, just like TT provides unique features, as do other systems. Swapping out Mason's tag syntax for TT-like syntax is easy, and there is an ASP-like syntax provided by a CPAN module, MasonX::Lexer::MSP [cpan.org].
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.