Request object checklist
Posted: Fri Oct 19, 2007 7:11 pm
I have struggled with whether or not I should use a Request object in my applications for a while instead opf just accessing the GPC globals.
Last night I put some thought into it and looked over my code where I thought a Request object would make a difference and I came up with the following reasons to use a Request - although I not *totally* convinced it should be a part of the front controller like in Zend.
1) It prevents a "Undefined Index Error" like when you access a GLOBAL GET value which hasn't been supplied. I hate those annoying errors and potentially using a error supression operator.
Using a simple API such as this:
Would prevent those errors from occuring as you could handle the empty/isste tests inside the function. I thought about taking it one step further and actually passing a second *optional* argument such as $default so you could provide the default value incase the GET value isn't provided.
2) A few days ago I stumbled upon socttayy's little code snippet for removing the quotes added by magic quotes. I thought to myself, that would be a nice convience if stored inside the Request object, otherwise I would be hard pressed to utilize the code. You could strip the code only upon accessing as well, so you avoid any time consuming traversal/iteration cleaning each.
3) Having a function which returns the method (GET-POST) may come in handy, although I cannot personally think of a situation where this would be handy. Can anyone think of one?
4) POSTBACK state is something I utilize frequently in my applications. Hitherto, I have been storing that state as a single member inside the front controller - despite arborint a while back suggesting it belonged inside Request. I agree with him now, it certainly does make more sense inside the Request.
I have looked into various frameworks and how they implement Request/Response. I am not looking to develop the end all be all framework, just one which accomplishes 99% of logical separations and most used abstractions. I prefer to keep my request object simple and only include that which I know I can use in my own applications, which is basically the list I have given above.
One more consideration I have is possibly integrating some kind of validation service into the Request object as well.
Something as simple as:
The call would looks something like:
I like the idea of calling Request methods as static - but I am also considering possibly including it as an object of Front via composition.
Anyways, RE_EMAIL would simply be a trivial lookup table stored inside define, such as:
Obviously rudimentry but gets the point across.
Although I like the idea of a centralized database of regex filters and they blend nicely with Request data half of me thinks the sanitization would best be left outside of Request - keeping the objects more loosely coupled.
What do you think about my Request ideas? Should the santization be kept out of Request? Can you give an example - perhaps just using another global function which uses the lookup table?
More importantly, what do you think of my overall Request functionality, does it all make sense, other than the sanitzation?
Cheers
Last night I put some thought into it and looked over my code where I thought a Request object would make a difference and I came up with the following reasons to use a Request - although I not *totally* convinced it should be a part of the front controller like in Zend.
1) It prevents a "Undefined Index Error" like when you access a GLOBAL GET value which hasn't been supplied. I hate those annoying errors and potentially using a error supression operator.
Using a simple API such as this:
Code: Select all
Request::getValue('value');2) A few days ago I stumbled upon socttayy's little code snippet for removing the quotes added by magic quotes. I thought to myself, that would be a nice convience if stored inside the Request object, otherwise I would be hard pressed to utilize the code. You could strip the code only upon accessing as well, so you avoid any time consuming traversal/iteration cleaning each.
3) Having a function which returns the method (GET-POST) may come in handy, although I cannot personally think of a situation where this would be handy. Can anyone think of one?
4) POSTBACK state is something I utilize frequently in my applications. Hitherto, I have been storing that state as a single member inside the front controller - despite arborint a while back suggesting it belonged inside Request. I agree with him now, it certainly does make more sense inside the Request.
I have looked into various frameworks and how they implement Request/Response. I am not looking to develop the end all be all framework, just one which accomplishes 99% of logical separations and most used abstractions. I prefer to keep my request object simple and only include that which I know I can use in my own applications, which is basically the list I have given above.
One more consideration I have is possibly integrating some kind of validation service into the Request object as well.
Something as simple as:
Code: Select all
Request::getValue($name, $default, $pattern)
{
// ... Check for magic quotes - remove.
// ... Make sure variable is set according to value or default
// Filter any not allowed characters
$value = preg_replace($pattern, '', $value);
return $value;
}Code: Select all
$email = Request::getValue($email, '', RE_EMAIL)Anyways, RE_EMAIL would simply be a trivial lookup table stored inside define, such as:
Code: Select all
define('RE_EMAIL', '[^a-z@a-z.(com|ca)]');Although I like the idea of a centralized database of regex filters and they blend nicely with Request data half of me thinks the sanitization would best be left outside of Request - keeping the objects more loosely coupled.
What do you think about my Request ideas? Should the santization be kept out of Request? Can you give an example - perhaps just using another global function which uses the lookup table?
More importantly, what do you think of my overall Request functionality, does it all make sense, other than the sanitzation?
Cheers