Mason advantages

[sono-io-2]

        I've been playing around with Mason/Poet for a couple of days and I have to say I'm impressed.  I'm still relatively new to frameworks and the like, so I don't know the differences between the choices out there.  Is there a write-up somewhere that talks about the differences and/or advantages of M/P over Dancer, or any of the others?  Being that Mason 2 is relatively new, I haven't found anything in my searches.

        I almost hate to ask this because I'm not trying to stir anything up.  I'm truly curious as to what the advantages are with the Mason/Poet combo over the others.

Thanks,
Marc
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mason-users mailing list
Mason-users@...
https://lists.sourceforge.net/lists/listinfo/mason-users

[sono-io-2]

On May 7, 2012, at 12:30 PM, sono-io@... wrote:

> I've been playing around with Mason/Poet for a couple of days and I have to say I'm impressed.  I'm still relatively new to frameworks and the like, so I don't know the differences between the choices out there.  Is there a write-up somewhere that talks about the differences and/or advantages of M/P over Dancer, or any of the others?  Being that Mason 2 is relatively new, I haven't found anything in my searches.

        I'm still very interested in reading something that shows the advantages and/or differences between Mason/Poet and Dancer.  Does anyone know of a writeup online?

        I found a "Comparison of web application frameworks" here:

http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

but the Mason line under the "Comparison of Features" section has only a bunch of question marks.

Thanks,
Marc
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mason-users mailing list
Mason-users@...
https://lists.sourceforge.net/lists/listinfo/mason-users

[Nic Wolff-2]

On 14 May 2012, at 8:09 PM, sono-io@... wrote:
> I'm still very interested in reading something that shows the advantages and/or differences between Mason/Poet and Dancer.  Does anyone know of a writeup online?

On this list in February Jon and I each posted a contrast between Mason and MVC-style frameworks:

From: Nic Wolff <nic@an...> - 2012-02-11 16:22

> Can't speak for Jon but for me, Mason's filesystem-based routing is much more naturally modular, transparent, and expressive than parsing paths in a controller, certainly for organizing dynamic content and often for REST applications as well. URIs map to the directory tree in an obvious hierarchical manner and auto- and dhandlers live next to the content they augment – when you're not working on a directory, you can forget about it. The filesystem is the controller, views are in their natural places in the directory tree, and models are in business-object modules – isn't that the Mason Way?

From: Jonathan Swartz <swartz@po...> - 2012-02-13 13:55

> In Catalyst, URLs are handled by controller classes. A controller gathers data from appropriate model(s), then constructs a hash of data and passes it to a template to render the page.
>
> In theory the controller method and template are decoupled, so that you could create multiple templates for a single controller method (one for browser, one for mobile, etc.).
>
> In practice, there is almost always a one-to-one correspondence between controller method and template, and the two *are* quite coupled. If you want to figure out how a page is rendered, you have to look at both the controller and view. If you want to change how the page is rendered in any meaningful way, you have to modify both the controller and the view. So I find that with Catalyst development I'm constantly having to look in, and edit, two places at once. I also have more decisions to make about which code goes where.
>
> In Mason, URLs are handled by components. A component gathers data from appropriate model(s), then renders the page itself. You only have to look in one place and modify things in one place.
>
> Now with Mason 1 one could make a case that it's better to put logic in real OO classes whenever possible. With Mason 2, components *are* Moose classes; you get just as much OO power and goodness in a component as you do in a class. For example, a component can have a BUILD method that sets up attributes based on URL, params etc., and a number of render methods that refer to those attributes. This is a much richer controller-view interaction than passing a hash between two completely separate pieces of code.


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mason-users mailing list
Mason-users@...
https://lists.sourceforge.net/lists/listinfo/mason-users

[Jonathan Swartz]

Hi Marc,

As the author I'm obviously biased, but I'll give you my take on the three key differences between Poet+Mason and analagous combos, e.g. Catalyst+TT, Dancer+TT, and Mojolicious.

1) Builds upon the best of CPAN

Poet+Mason depends proudly on Moose and Plack/PSGI (as well as a few other best-of-breed CPAN distributions). Being able to depend on the presence of these powerful modules means that we get quite a lot for free, and can focus on interesting features instead of reinventing the wheel. Mason components compile down to Moose classes. Mason and Poet plugins are Moose roles. Poet freely takes advantage of PSGI middleware and uses the Plack::Request/Plack::Response objects as a base request/response API.  There aren't separate branches of code or feature sets or documentation for Moose/non-Moose users or for PSGI/non-PSGI users.

In contrast, Dancer and Mojolicious are proud of their lack of dependencies, because it makes installation easier; true enough. But this means a lot of wheel reinvention and divergent usage patterns depending on what is present. Dancer, for example, invents its own before/after hooks and its own base request/response API. Mojolicious, with its zero dependency promise, has to reinvent everything for its baseline behavior.

Some people do seem afraid of the cost of Moose installation and of largish installation chains in general. So for them, the lack of dependencies is an advantage. My feeling is that tools like local::lib and perlbrew and cpanm and Pinto and Carton make it increasingly easy to control the Perl and CPAN environment that your application uses (with or without root access), so why not depend on the best?

2) Perl-based template language

Mason does not attempt to invent a new programming language syntax for templates.  It is just Perl, wrapped with just enough extra syntax and features to facilitiate templating. Mason components compile into Moose classes in an obvious way.

This gives Mason templates enormous power (whatever Perl can do, Mason can do) and just as importantly, predictability - if you know Perl and Moose then you know how your components will behave, and if you forget how a piece of Mason syntax translates, you can just look at the compiled class or walk through with the Perl debugger.

In contrast, TT is really is a separate language that you have to learn and understand.  It is well-designed in some aspects, but is undeniably (and intentionally) weak compared with Perl and has a number of well-known quirks (e.g. with variable scoping).

One purported advantage of TT over Mason is that it is friendlier for non-programmers (e.g. designers). Another is that its weakness as a programming language is actually a strength, in that it encourages you to put complex code into Perl classes.

The paragraphs above apply equally to HTML::Template, except it is even further along the intetionally-weak/quirky/designer-friendly spectrum.

3) Combined controller and view

In most frameworks the controllers and views are strictly separated. A controller gathers data from appropriate model(s), then constructs a hash of data and passes it to a template to render the page.

In theory the controller method and template are decoupled, so that you could create multiple templates for a single controller method (one for browser, one for mobile, etc.).

In practice, you almost never do this; there is one template per controller method, and the two *are* quite coupled. If you want to figure out how a page is rendered, you have to look at both the controller and view. If you want to change how the page is rendered in any meaningful way, you have to modify both the controller and the view. So with Catalyst development you constantly having to look in, and edit, two places at once. You also have more decisions to make about which code goes where.

In Poet+Mason, it's very clear which component handles a URL, and that component contains both the controller and the view. You only have to look in one place and modify things in one place, and you aren't wasting time packing and unpacking a stash in between two coupled pieces of code.

Catalyst and MVC devotees would say that the separation between C and V is valuable, to ensure you aren't "doing too much" in templates. Whether this applies when said templates compile to full OO classes is less clear.

Hope that helps!

Jon

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mason-users mailing list
Mason-users@...
https://lists.sourceforge.net/lists/listinfo/mason-users