Feb 25

For those using Mason 2′s request dispatching features, I just released Mason::Plugin::RouterSimple, which adds basic route support courtesy of Router::Simple.

Let’s say we want to support URLs like

    /archives/2010/05

where the second and third part of the path are year and month parameters respectively.

Using the new plugin:

    %% route "{year:[0-9]{4}}/{month:[0-9]{2}}";

    Archives for the month of <% $.month %>/<% $.year %>:
    ...

    <%init>
    # Use $.month and $.year to fetch the archives
    </%init>

The route command adds a route indicating how the path_info (the remainder of the path beyond /archives) should be parsed.

Any named captured arguments are placed in component attributes, which are declared automatically if you don’t do so manually. So above, we get auto-declared attributes $.year and $.month that are then set to ’2010′ and ’05′ for that URL.

You can add multiple routes and they’ll each be tried in turn. If the URL does not match any route, the component will decline, which generally results in a 404.

Other examples of Router::Simple routes:

    route "wiki/:page";     # sets $.page
    route "download/*.*";   # sets $.splat to a 2-element arrayref

I chose Router::Simple because I liked the compact declaration syntax, but one could create similar plugins (with some shared common code) to support other routers like Path::Dispatcher and Path::Router.

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.

preload preload preload