We have a similar situation in our project. We need to validate whether the logged in user can edit/delete a record. I am thinking that a callback in the routing containing the id of the record ( www.example.org/edit/123) would be the best place to validate whether the user can actually mess with the record.
Is there a better way? Peace, Shoan. On 28-Jun-07, at 3:26 AM, David Zülke wrote: > 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 _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
