Hi Kris, that was my concern as well. Afaik there are a few frameworks out there that are able to deal with that. We would need to attach that "requirement" to the actual action, not to one of the many aliases the action might have.
I would need to digg this out, but afaik Tapestry in Java has this. you have a handler that is invoked when a page is requested and that populates certain stuff. similar to what we do with getRequestparm, but its able to get objects identified by PK and other more complicated stuff besides basic params. I tried to enhance the routing requirements for this once and did not succeed due to the issue you are refering to. But combining the routing requirements and the input filtering still seems like a sensible thing to do. otherwise its getting WET. err not DRY :-) requirement: id=d* getAsInt($id) .: Fabian On Tue, Jul 8, 2008 at 8:59 AM, Kris Wallsmith <[EMAIL PROTECTED]> wrote: > > But don't routing rules by definition only deal with GET parameters? > > - Kris > > On Jul 7, 2008, at 11:57 PM, Francois Zaninotto wrote: > > > > > I agree with Fabian, maybe it would be a good idea to enhance the > > routing requirements rather than add a new component. > > > > François > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
