Request object checklist

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Request object checklist

Post by alex.barylski »

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:

Code: Select all

Request::getValue('value');
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:

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;
}
The call would looks something like:

Code: Select all

$email = Request::getValue($email, '', RE_EMAIL)
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:

Code: Select all

define('RE_EMAIL', '[^a-z@a-z.(com|ca)]');
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 :)
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

I think other than prep sanitization like removal of magic quotes gpc I dont' think any sort of sanitization/validation belongs in your dispatcher/front. Validation belongs in the model. But maybe I'm not following you 100%.
User avatar
John Cartwright
Site Admin
Posts: 11470
Joined: Tue Dec 23, 2003 2:10 am
Location: Toronto
Contact:

Post by John Cartwright »

What neophyte said.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Thanks for the replies...

I personally don't consider removal of magic quotes sanitization. It's added to the REQUEST data and it's detectable and applied unanimously(sp) to all variables. As for removing other characters...perhaps it's best left to a santization function. Although I disagree that sanitization belongs in the model, that also depends on how you setup and use your MVC components.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

neophyte wrote:Validation belongs in the model.
Well there is validation and there is validation, and there are models and there models. PHP scripts often have multiple model-like things -- the Request being one of the common 'other' models.
(#10850)
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

If you're on PHP5 - ArrayAccess. And use composition whenever possible.

I think the above will offer some light weight entertainment without having to convert entirely to an object access model if you don't need it.
User avatar
neophyte
DevNet Resident
Posts: 1537
Joined: Tue Jan 20, 2004 4:58 pm
Location: Minnesota

Post by neophyte »

Object access model? New term for me.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Sorry if this is off-topic, I didn't read your thread since I was just passing by but calling something like getValue() statically on a request class seems odd for some reason. You lose all ability to mock a Request object.
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

Wording on the fly ;). I was referring to $object->member vs $object['member'] (object vs array access).

Static calling should be avoided for the usual reasons - tight binding to a single class name, inability to mock statics, requires global-like public access, etc. Using a Registry would be cleaner since you can then switch in different Request objects so long as they obey the agreed interface.
Post Reply