Feb 21

I’m pleased to announce Mason 2, the first major version of Mason in ten years.

For those not familiar with it, Mason is a templating framework for generating web pages and other dynamic content. Mason 2 has been rearchitected and reimplemented from the ground up, to take advantage of modern Perl techniques (Moose, Plack/PSGI) and to correct long-standing feature and syntax inadequacies. Its new foundations should allow its performance and flexibility to far exceed Mason 1.

Though little original code or documentation remains, Mason’s core philosophy is intact; it should still “feel like Mason” to existing users.

I’ve talked about plans for Mason 2 here before, but as things have changed in the past year and a half, here’s an updated summary:

  • Name. The name is now Mason, instead of HTML::Mason.

  • Component classes. Each component is represented by its own (Moose) class, rather than just an instance of a common class. This means that components have their own namespaces, subroutines, methods, and attributes, and can truly inherit from one other. See Mason::Manual::Components.

  • Filters. A single powerful filter syntax and mechanism consolidates three separate filter mechanisms from Mason 1 (filter blocks, components with content, and escape flags). See Mason::Manual::Filters.

  • Plugins. Moose roles are utilized to create a flexible plugin system that can modify nearly every aspect of Mason’s operation. Previously core features such as caching can now be implemented in plugins. See Mason::Manual::Plugins.

  • Web integration. Mason 1′s bulky custom web handling code (ApacheHandler, CGIHandler) has been replaced with a simple PSGI handler and with plugins for web frameworks like Catalyst and Dancer. The core Mason distribution is now completely web-agnostic. See Mason::Plugin::PSGIHandler.

  • File naming. Mason now facilitates and enforces (in a customizable way) standard file extensions for components: .m (top-level components), .mi (internal components), and .pm (pure-perl components).

See Mason::Manual::UpgradingFromMason1 for a more detailed list of changes.

Mason 2 is obviously still in alpha status, but it has a fair sized test suite and I’m eager to start building web projects with it. I hope you’ll give it a try too! Post feedback here or on the Mason user’s list.

14 Responses to “Announcing Mason 2”

  1. sitemap Says:

    Great news Jonathan,
    I was waiting for this update for a long time.

    Thank you!

  2. Sawyer Says:

    Great work on Mason 2!
    I think you’ve made all the right decisions: Moose, roles, renaming to “Mason”, etc.

    I’m happy Dancer has template backends for both Mason 1 and Mason 2.

  3. Tweets that mention Announcing Mason 2 -- Topsy.com Says:

    [...] This post was mentioned on Twitter by Ian Burrell and RtestR, perlironman. perlironman said: Jonathan Swartz: Announcing Mason 2 http://bit.ly/i7Pa42 [...]

  4. Steven Haryanto Says:

    I’m not sure about choosing Moose being a right decision. Yet another framework unusable in CGI mode. Moo, on the other hand… :-)

    Anyhow, I did use Mason back in the 199x days. As I remember it, one of the main frustrations we had was that Mason translated components to Perl code, but the line numbers were all jumbled. Whenever there’s an error, it was not clear at all at which line on the component it was. Does Mason still have this problem?

  5. Jay Says:

    It may be web agnostic, but it would be a hardship to use it in a non-persistent environment thanks to the the heavy Moose tax.

  6. Jay Says:

    Oh and Devel::Declare too? Thanks, but no thanks.

  7. Matthias Dietrich Says:

    Jon, thank you very much for your effort! I just installed it and will try it in a first project.

  8. Jonathan Swartz Says:

    Steven: There are plenty of minimalist frameworks out there, I wasn’t interested in competing in that space. I’m optimizing for power and flexibility and am willing to rule out CGI.

    I’ll take your word for it that people still have to use CGI. I don’t quite understand why, though — I know there’s shared hosting, but you can rent a virtual host w/root control so cheaply. Even the default plackup server is persistent.

    Re error line numbers: No, line numbers are reported in terms of the source component. This has been fixed since Mason 1.1 (April 2002).

  9. Jonathan Swartz Says:

    Jay: Well, “hardship” is relative. On my several years old macbook it takes 3/4 second to start up Mason:

    swartz> time bin/mason -e “2 + 2 = < % 2 + 2 %>”
    2 + 2 = 4

    real 0m0.714s
    user 0m0.641s
    sys 0m0.041s

    That’s obviously not instant, but unless you’re running the script many times per minute, it hardly seems like a showstopper.

    But yes, if quick startup in a non-persistent environment is a high priority, there are clearly better choices.

  10. jomo Says:

    Cool, thanx! :) Already trying it.

    The only thing: the default extensions “.m” are a bad choice in an Mac OS X environment. .m are the ObjectiveC files. It is really annoying opening all files mason with “open with” right click, because don’t want change the default association from Xcode.

    Yes, i know than it is possible change with “top_level_extensions” and so on, but this will work only for my own components, not for components what comes from another source (e.g. the demo blog) :D

    Would be much better the “.mc” (Mason Component) and “imc” (or im) for internal mason component” – or soo.. ;(

  11. Danny Hembree Says:

    when I run the mason -e above I get .9 seconds on a YDL powerstation perl 5.10.1 . Probably, due to the lengthy error dump:

    The old Moose::Util::MetaRole API (before version 0.94) has been deprecated at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 20
    Mason::Moose::init_meta(‘Mason::Moose’, ‘for_class’, ‘Mason::CodeCache’, ‘metaclass’, undef, ‘meta_name’, ‘meta’) called at /usr/lib/perl5/site_perl/5.10.1/ppc64-linux/Moose/Exporter.pm line 423
    Moose::Exporter::__ANON__(‘Mason::Moose’) called at /usr/lib/perl5/site_perl/5.10.1/Mason/CodeCache.pm line 6
    Mason::CodeCache::BEGIN() called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    eval {…} called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    require Mason/CodeCache.pm called at /usr/lib/perl5/site_perl/5.10.1/Mason/Interp.pm line 12
    Mason::Interp::BEGIN() called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    eval {…} called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    require Mason/Interp.pm called at /usr/lib/perl5/site_perl/5.10.1/Mason.pm line 5
    Mason::BEGIN() called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    eval {…} called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    require Mason.pm called at /usr/lib/perl5/site_perl/5.10.1/Mason/App.pm line 9
    Mason::App::BEGIN() called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    eval {…} called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    require Mason/App.pm called at /usr/bin/mason line 11
    main::BEGIN() called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6
    eval {…} called at /usr/lib/perl5/site_perl/5.10.1/Mason/Moose.pm line 6

    however:
    Moose::Util::MetaRole is up to date (1.24)

    hope this isn’t a trail of tears…

  12. Jonathan Swartz Says:

    Danny: Line 20 of Mason/Moose.pm is

    MooseX::StrictConstructor->init_meta(@_);

    Can you see what version of MooseX::StrictConstructor you have, and try upgrading it? I probably have to require the latest.

  13. Jonathan Swartz Says:

    jomo: D’oh! Should have researched this beforehand. I had never heard of .m, but that’s a pretty common use-case and will grow ever more so in our inevitable iFuture. :(

    I guess I will change to .mc and .mi. Neither of these seem to be taken according to http://www.fileinfo.com/. Thanks for the heads up.

  14. Jerry Says:

    Great news!

    Thanks for your effort to update Mason!

Leave a Reply

preload preload preload