On 14 May 2012, at 8:09 PM, sono...@fannullone.us 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mason-users
