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. :) -- Bill Moseley mose...@hank.org
_______________________________________________ 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/