On Sat, 12 May 2007, Matt S Trout wrote:
In my opinion, the dhandler portion of Mason is entirely superfluous when
using Catalyst. Catalyst already provides many dispatch options to do
similar things, including default() methods in your controller, which act
more or less exactly like dhandlers. I always kind of assumed default()
and auto() had been inspired by Mason, because they work so much like
Mason does.
The autohandler stuff is still really useful, but I just use it for
wrapping header/footers or path-specific menus around the called
component.
dhandlers largely yes, autohandlers maybe not
plus the component inheritence stuff could be useful.
Sure, I just didn't follow your comment about Chained controllers and
integrating that with Mason's internal component dispatching.
FWIW, Jon Swartz and I have been talking about what Mason 2.0 would look
like. We both agreed that we'd want to make the templating piece
standalone, without the framework bits. We'd still support autohandlers,
but probably not dhandlers. Component inheritance I'm on the fence with.
It can be really useful, but it's so fantasticaly easy to abuse and make a
mess with. I guess that's Perl for you ;)
I guess my take on it is that you do the dispatching part in your
controller, and as part of that, you should also decide what component to
call for the view. The default for this in the Mason view seems to be the
same as that in the TT2 view, which is to use $c->req->match. That seems
reasonable to me.
That's one of the things that needs to change, the standard for views is
now $c->action.
Easy enough to fix.
-dave
/*===================================================
VegGuide.Org www.BookIRead.com
Your guide to all that's veg. My book blog
===================================================*/
_______________________________________________
List: [email protected]
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
