On 28/02/2013, at 8:25 PM, Nick Anderson wrote:
> > Hi Trevor, > > Many thanks for clarifying that. I guess I was hoping for some reliable and > predictable outcome for ambiguous requests but it seems the statement "Don't > do this" in the URL Path handling section does indeed sum it up! And although > it does not explicitly mention chained actions, I presume any URL path > ambiguity should/must be avoided. > I think making it clear(er?) in the docs that if you're using Chained in a controller you shouldn't use any other dispatch type would be useful. Where is the correct place for that to go? > What I was trying to achieve was a catch-all facility for requests other than > application defined actions, up to root level (i.e. for user-specified URLs > which are then looked up in a database). For the life of me I can't remember > why I avoided using the "default" action to achieve this, probably because I > thought being more specific (even just by using a wildcard chain) was the > most appropriate way to approach it and more structured. My preference is to keep Controller::Root very bare, but keep a default (i.e. 404) handler in there, and an index type action. > > I presume then, that having a /*/... wildcard action to catch everything else > is not advisable? Is using the default action the preferred method then to > allow for unknown/dynamic URLs where an application defined action is > unavailable? The usual thing to do with default is to catch 404 errors. _______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
