Hey David and Jesse, I like the concept of what you're proposing, David.
In the Jifty world, Jifty::Dispatcher typically provides most of the features for which autohandlers are used. I don't Catalyst well enough to know its analogue, but surely it must have one (or more). In looking through the RT code, we use autohandlers for a number of reasons. All of these features are solved quite well by Jifty::Dispatcher: * abort if the user does not have permission to use the given template (such as everything under /Admin if you do not have a specific right) * abort if some other arbitrary condition is not met (such as misconfiguration, as in the case of Shredder) * perform some nonstandard action besides "execute this file as a mason template" (such as optimizing the common case of serving a binary file) * redirect the user if some condition is met (such as being in "install mode", which sends the user somewhere else) * send extra HTTP headers (as in the REST interface) Only in one place do we actually inject additional HTML. In the global /autohandler we add a footer to each page. (In RT this is asymmetrical only because calling the header template is how each page specifies its title, tabs, etc) That our real-world use of autohandler is almost entirely controller-level rather than view-level suggests that we should come up with a better metaphor than autohandler for what we want in TD here. I think this is what Jesse was saying here: On Thu, Nov 12, 2009 at 01:11:18PM -0500, Jesse Vincent wrote: > Hrm. I think I'd be a lot happier separating the "autohandler" concept from > a more generic "wrapper" concept. Now, skipping down to the latest post.. :) On Tue, Dec 01, 2009 at 03:16:06PM -0500, Jesse Vincent wrote: > On Tue 1.Dec'09 at 11:48:49 -0800, David E. Wheeler wrote: > > So how would you resolve them if there were two on the same path level in th e same dispatch class? > > I don't have a good answer for that, short of "declaration order" or > some similar insanity. Your argument was pushing me toward "no names" > rather than "multiple per package and level" I definitely prefer getting rid of wrapper names; don't see a real need for them. For multiple wrappers, declaration order works. Or, for now, defer the decision by making it an error to declare more than one. That affords us forward-compat. On Tue, Dec 01, 2009 at 03:16:06PM -0500, Jesse Vincent wrote: > When we're doing template resolution, "/" still means at the root, not "the > current package", right? That would lead me to want to use relative > pathing syntax here. '.' or './' or _something_, since '/' means something > fairly specific already. Ew. This makes me want to get rid of specifying paths for wrappers entirely. On Tue, Dec 01, 2009 at 03:16:06PM -0500, Jesse Vincent wrote: > Really, when we start specifying paths and subpaths, for these wrappers > to wrap, I start reaching for a path based dispatcher with globbing > and/or regexes, ala Path::Dispatcher or Jifty::Dispatcher, but I know > that's not the hammer you're looking for. Maybe we really do just want > one wrapper per package scope. Yeah, agreed. I'll detail my counterproposal.. proposals! in a followup mail. Shawn _______________________________________________ jifty-devel mailing list jifty-devel@lists.jifty.org http://lists.jifty.org/cgi-bin/mailman/listinfo/jifty-devel
