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
>
> 2008/7/8 Sid Bachtiar <[EMAIL PROTECTED]>:
>>
>> Oh and there should be a way to check based on the field type in
>> schema.yml/xml.
>>
>> Most parameters/fields are going to be based on an actual field in
>> the
>> database anyway.
>>
>> On Jul 8, 2:59 pm, Sid Bachtiar <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> I'm new to this devs mailing list so take it easy if my comment is
>>> slightly off.
>>>
>>> IMHO, whatever it is, user should be able to just use YML file
>>> rather
>>> than code. One of the reasons is that it is non-intrusive.
>>>
>>> Ideally, the underlying code would be a complete framework like
>>> sfForm. Because it is more future proof and reusable.
>>>
>>> Solution 1 and 2 are OK and would [kinda] work, but not good enough.
>>> It is easier to implement but a bit of a short term solution/patch.
>>>
>>> Also there should be a way to configure the filter to get field
>>> size/
>>> length from the schema.yml/xml ...
>>>
>>> Regards,
>>>
>>> Sid
>>>
>>> On Jul 5, 8:09 am, "Tristan Rivoallan" <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>> hi,
>>>
>>>> as you may know, i'm responsible for implementing input filtering
>>>> in
>>>> the forthcoming symfony-1.2.
>>>
>>>> before starting to code anything, i would like to get some
>>>> community
>>>> feedback about the different solutions i've came up with :
>>>
>>>> (in any case, the underlying filtering framework will be ext/
>>>> filter[1])
>>>
>>>> * first solution : extend the sfRequest::getParameter() semantics,
>>>> adding a simple ext/filter wrapper. eg. :
>>>
>>>> // Signature
>>>> public function getParameter($name, $default_value, $filter_name,
>>>> array $filter_options)
>>>
>>>> // Usage
>>>> $request->getParameter('foo', 'bar', FILTER_VALIDATE_INT,
>>>> array('min_range' => 5, 'max_range' => 10, 'flags' =>
>>>> FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX));
>>>
>>>> * second solution : extend the sfRequest::getParameter() semantics,
>>>> abstracting the filtering logic. eg. :
>>>
>>>> // Signature
>>>> public function getParameter($name, $default_value, sfInputFilter
>>>> $filter_instance)
>>>
>>>> // Usage
>>>> $request->getParameter('foo', 'bar', new
>>>> sfExtFilterInputFilter(array('id' => FILTER_VALIDATE_INT,
>>>> 'options' =>
>>>> array('min_range' => 5, 'max_range' => 10, 'flags' =>
>>>> FILTER_FLAG_ALLOW_OCTAL | FILTER_FLAG_ALLOW_HEX)));
>>>
>>>> * third solution : implement a complete input filtering framework
>>>> similar to what can be found in the zend framework[2]
>>>> * fourth solution : something better that i've not thought about :)
>>>
>>>> looking forward to your insights.
>>>
>>>> ++
>>>> tristan
>>>
>>>> [1]http://php.net/filter
>>>> [2]http://framework.zend.com/manual/en/zend.filter.input.html
>>>
>>>> --
>>>> Tristan Rivoallanhttp://www.clever-age.com
>>>> Clever Age - conseil en architecture technique
>>>> GSM: +33 6 219 219 33 Tél: +33 1 53 34 66 10
>>>
>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
