The problem I see with this is that it happens too early, outside the normal validation process. OTOH, it's probably justified as every request goes to such an "object", hence a "validation" in a routing callback could very well be justified.
A good example of a situation where, in my opinion, validating something in a routing callback is okay is when you have a service that allows people to register their own subdomains: <route name="subdomain" pattern="^(userdomain:[^.]+).myservice.com$" callback="UserSubdomainRoutingCallback" /> because otherwise, you would have to validate the subdomain in every single action, and maybe even take other measures (such as store the subdomain somewhere for later use, gather info about that account, and so on). David Am 27.06.2007 um 23:44 schrieb Noah Fontes: > 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 > _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
