1) CLI (Command line interface) input isn't HTTP data, it's environment data...so the classname with HTTP in it wouldn't make sense...besides I think that's going over board as PHP as a web application engine, wouldn't typeically be called that way...
Plus it would be tricky to build into an overall class hierarchy
2) Something of a factory method which cranked out custom *cleaned* objects with direct access to property names (albeit - going against OOP tradition) would make a lot of sense here - IMHO anyways.
So you call a method and it returns objects with no methods, just public properties...to emulate an OO approach to HTTP input.
Code: Select all
static HTTP_Request::getObject($_POST);
$ret = HTTP_Request::getObject($_POST];
$ret->first_name; // $_POST['first_name'];Perhaps including a HTTP_Filter object as a plugin would be interesting as well. Admittedly this needs more thought, I have a few ideas, but would like the rest of the community to through in some ideas on the subject - Out of context or plugin approach???
The factory method need only be a factory, unless PHP supports expando properties like javascript?
My stipulations for continuing support...
1) phpDocumentor comments
2) Zend framework coding conventions & license are followed
Other than that, I'm not sure I would ever use a class like this, as I don't find using $GLOBALS dangerous, but if it did more than act as a registry, I could be pursuaded into using it and contributing my thoughts, sure...
Cheers