On Sun, May 2, 2010 at 7:28 AM, Bill Moseley <mose...@hank.org> wrote: > > > On Sat, May 1, 2010 at 6:17 PM, Tomas Doran <bobtf...@bobtfish.net> wrote: >> >>> >>> So, what would you recommend? Have a separate /user/$id/debug method that >>> does a separate step-by-step of the business logic? Scrap all that really >>> handy chaining of resultsets that works so well with Catalyst's chained >>> actions? >> >> Given that 'a tiny, tiny percent a request might fail', why not do the >> step by step for the tiny failed set and then present the reason to the user >> for those? >> >> (Or am I missing something obvious here?) > > You are not missing anything if that's your recommendation. I assume lots > of people here are creating real web applications with Catalyst so was > inquiring how others handle this situation in the design of their > applications. > I have a CRUD controller base class to help generate a RESTful-like API that > is used by both API users and with an AJAX-based application, which I assume > is not that uncommon with Catalyst apps. For example, when a PUT > /thingy/52113 fails (which means the query used to fetch the item failed), > how do you reported to the user? A 404 with a text description? Some kind > of error code in the response body? > I my case, I'm added a method explain_not_found() to the base class that can > be overridden in the controller to provide specific details in textual > format. That method would be used to break the query into parts to test > each join and condition, for example. > > As a side note: Frankly, I enjoy the discussions of real problems and > solutions on this list. I try not to find it discouraging that old topics > like benchmarking methods calls and the few inflammatory remarks seem to get > so much traction. :) > >
My method is simply to use chained, and on the _REST action defer to a not_found... but this is using base classes (and a conversion to roles). So, if I want to specialize thingy's not found action I just drop a method in there... otherwise the base controller not_found is called, which sets a template for any browser (and the entity/message stuff works as expected). If it's not a browser they only get a formatted message via C::C::REST->status_not_found, if they are I also set a template that tries to find a not_found.tt in that action namespace (same as what you expect w/ Catalyst::View::TT), and if that doesn't exist it goes to the shared not_found.tt. That template is pretty easy: TRY; PROCESS "$c.action.namespace/not_found.tt"; CATCH file; PROCESS "errors/not_found.tt"; END; What's next on my list is to tie in status helpers into my Message::Stack work (not yet released) that applies scope knowledge to the error messages. Thanks, -J _______________________________________________ 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/