Afternoon, Have you taken a look at Veikko's CMS application? He uses a pretty unique method to determine whether some object is valid. What he's done is set up a routing callback that checks the id parameter of the request data and grabs the correct item from the DB and sends it to Request or returns false if it doesn't exist.
I'm not sure how 'correct' this is (it'd have to be in your global namespace, and if you have to do any manipulation/validation of request data besides checking to see if it exists in the database, this probably isn't the way to go), but it might be worth a try. The major upside to this is that you can specify the same routing callback to check/validate multiple routes -- plus it forwards to the 404 action by default upon returning false in the method. I definitely like the idea of setting the proper view in handleError() too (obviously Veikko's idea is only for the 404 part :). +1 for that as well. Regards, Noah On Wednesday 27 June 2007 07:25:59 Van Daele, Koen wrote: > Ok, thx for the feedback. > > Returning the global 404 view does seem better than having a 404View per > action (since almost every action could have a itemNotFound error. > > Koen > > > -----Oorspronkelijk bericht----- > > Van: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] Namens David Zülke > > Verzonden: woensdag 27 juni 2007 12:43 > > Aan: Agavi Users Mailing List > > Onderwerp: Re: [Agavi-Users] Handling errors > > > > Hi Koen, > > > > I think multiple Views are the way to go here. Your > > NotFoundErrorView could then forward to the 404 action, for > > example, so you don't have too much duplicate code. If your > > 404 action is empty, i.e. just a view (which it should be), > > then you could also return array > > (AgaviConfig::get('actions.404_module'), AgaviConfig::get('actions. > > 404_action')) from the action to make agavi use that view > > instead of one related to the action itself. You can talk to > > the validation manager (available from the container) inside > > handleError() to find out which validator failed, and then > > return the appropriate view name. > > > > > > Hope that helps, > > > > David > > > > Am 27.06.2007 um 12:18 schrieb Van Daele, Koen: > > > Hi all, > > > > > > I'm trying to decide how to go about handling crud errors. From the > > > IRC logs I've gathered that the best approach would be to have: > > > - An InputView > > > - An ErrorView that uses the InputTemplate > > > - A SuccessView that redirects to > > > > > > The problem I'm having is that there are different types of > > > > errors. > > > > > E.g > > > take a simple Book.Edit action. The first possible error is a user > > > trying to edit a book that doesn't exist (should return a 404 or a > > > 'sorry, this book doesn't exist' page. The second type of > > > > error is a > > > > > user entering incorrect data (a validation error) that show > > > > the input > > > > > template again. A third possible error might be that there's a > > > concurreny issue (should e.g. tell the user to re-edit the > > > > record or > > > > > should ask them if they're sure they want to overwrite user > > > > z's edit). > > > > > Do you use different Error views (eg. InputErrorView, > > > NotFoundErrorView, ConcurrencyErrorView)? Or do you set an > > > > attribute > > > > > in the action and then let the error view decide what to > > > > do? Are there > > > > > other options? > > > > > > Greetings, > > > Koen > > > > > > _______________________________________________ > > > users mailing list > > > [email protected] > > > http://lists.agavi.org/mailman/listinfo/users > > > > _______________________________________________ > > users mailing list > > [email protected] > > http://lists.agavi.org/mailman/listinfo/users > > _______________________________________________ > users mailing list > [email protected] > http://lists.agavi.org/mailman/listinfo/users -- Noah Fontes Cynigram Network Administrator [EMAIL PROTECTED] _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
