Both inefficient and a waste of time....And for your knowledge all my _GET, _POST, _SESSION and _COOKIE, etc. data is wrapped in a nice object and then unset.
| SitePoint Sponsor |
Both inefficient and a waste of time....And for your knowledge all my _GET, _POST, _SESSION and _COOKIE, etc. data is wrapped in a nice object and then unset.
Not realy, as the objects in question sanitize the variables and make sure they contain no invalild data, etc. And I'll have complete controll over what parts of my application that need the session/etc. data.Originally Posted by Snaily
And "inefficient", that's like what 0.0000001 of total execution time or 0.00001% of a sql query. If you're going to critizise the way someone else does something, atleast give a valid argument... ignorance.. *sigh*
I think there are distinct advantages to wrapping the superglobals into an object.
- Testing, can mock the object, and thus test everything that uses them.
- Have to deal with configuration/enviroment issues, things like magic_quotes, and perhaps perform some normalization of $_SERVER across web server software (IIS/Apache/etc).
The kids like to throw out words like "your ignorant" blah blah... I wasn't making an argument rather a statement. Futhermore your response is silly. This is a clear case of over-design..and what you are doing does not add a trivial amount of over head. Its a lot of work on EACH request to..allocate 4+ objects, populate them and unset the original source. One can give this sort of argument for every ineffiency "oh its just a coupe of milliseconds"...and by the time you're done your code is a bloated piece of junk.And "inefficient", that's like what 0.0000001 of total execution time or 0.00001% of a sql query. If you're going to critizise the way someone else does something, atleast give a valid argument... ignorance.. *sigh*
You have complete controll regardless...after you are the one writing the code.And I'll have complete controll over what parts of my application that need the session/etc. data.
Anyhow most of PHP's core is not object based....creating wrappers around it is pointless and highly inefficient and another language should be used if that is what is desired.
It certainly makes it easier...I dont' think its worth the performance cost.Testing, can mock the object, and thus test everything that uses them.
Snaily, POITROAE...
??????Snaily, POITROAE...
I'd say it's only a kid who says someone else is a kid
(God, I shouldn't feed the trolls =/)
Your birthday is in your profile...you ARE a kid. This is a fact.I'd say it's only a kid who says someone else is a kid
Please do ignore my posts in the future.God, I shouldn't feed the trolls =/
> Futhermore your response is silly. This is a clear case of over-design..
No it's not... It's called encapsulation
> creating wrappers around it is pointless and highly inefficient and another language should be used
> if that is what is desired.
As I said above, you gain encapsulation, also you gain a few other benifits; I think Ren spelled them out to you?
If you are going to come to the PAD forum and pick an arguement with someone then at least make sure you are well versed in the current methodologies, etc that we all practice in the forum, before you do so, as yes - you do come across as being ignorant.
Unlike yours... Should this tell us something?
God, I shouldn't even dignify that post with an answer... starting to ***** about age now? sigh...
I think he meant: Premature Optimization Is The Root Of All Evil??????
100% serious I thought he was cursing in his own language(I noticed it says Zagreb, Croatia next to his name/pic ;p)
Well I could maybe see doing that if you come from another language and are more comfortable with its user input model, and wish to emulate it.
But in practice, I really fail to see how it is really any different than the idea of magic quotes. Both capture user input and perform some mass transformation on the captured user input. The idea on its surface is not too bad, but in practice it ends up creating more problems than it solves.
Real though, I think you're just being a bit too schizophrenic. [God I hope not, but no offense meant to anyone who actually suffers from schizophrenia]
Encapsulation without benefit is a waste. Even the authors of PHP have warned against wrapping existing PHP libraries. People that try to make everything in PHP OO fail to see its stengths and should really be using another language.No it's not... It's called encapsulation
Oh boy this is classic. Yes....if one doesn't adhere to the PAD group-think one is ignorant! Its disgusting and makes posting on sitepoint undesirable when a small group of self-gratifying weinies feel the need to treat anybody that disagrees with them like crap. I have no interset in the PAD group-think, and I will continue to post what I feel (report my posts if you feel they violate some policy) otherwise if you don't like it...IGNORE IT.If you are going to come to the PAD forum and pick an arguement with someone then at least make sure you are well versed in the current methodologies, etc that we all practice in the forum, before you do so, as yes - you do come across as being ignorant.
I don't want to emluate any type of user input model but I want to be sure that the input I get is clean and sanitized.
What? To mention some things I use the wrappers for(which me and Ren already said):
- I have complete controll over what parts of my application that gets access to input data.
- Strip magic_quotes_gpc automaticly
These are by far the two most important ones, others are such as Ren said for testing purposes and I can also apply input filters on the objects if I want to apply specific regexp/other rules on the data.
Now tell me how's this anything like mq_gpc which just quotes everything?
That was uncalled for, realy stupid comment tbh...
Then tell me oh so aged god, how should it be done in your bible? Just leave the input data as it is, run "some_func_that_cleanas_them()" before I use them every time? Enlighten me/us, please.
How about staying on topic and cutting down on the insults.
This is actually a simple problem.
If you have only data, with no behavior (methods) except for getting and setting, leave it in arrays. If there is some behavior, put it into objects.
In other words, thr has a point to move the superglobal data into objects if he does something with it (specifically, he validates it); now, whether all of this data warrant such treatment is a separate issue.
> Then tell me oh so aged god, how should it be done in your bible?
Oh mighty one... I want to be enlightened too.
The Zend guys think wrapping $_POST into an object isn't a bad idea either:
From the manual:
An example usage:"Zend_InputFilter sets the array that is passed ($_POST) to NULL, so direct access is no longer possible. (The raw data is only available through the getRaw() method, which is much easier to monitor and/or avoid altogether.)"
PHP Code:$filterPost = new Zend_InputFilter($_POST);
$alphaName = $filterPost->isAlpha('name');
if ($alphaName !== FALSE) {
/* $alphaName contains only alphabetic characters. */
} else {
/* $alphaName === FALSE */
}
Firstly you aren't doing a good job at ignoring my posts... Secondly I never suggested there is one way this should be done...rather I disagreed with:Then tell me oh so aged god, how should it be done in your bible? Just leave the input data as it is, run "some_func_that_cleanas_them()" before I use them every time? Enlighten me/us, please.
Ahem...key word all. In some application this may make the most sense...but a lot (if not the majority) of applications there is absolutely no reason to do this, other than some silly aesthetically reasons. There are mutliple alternative ways of dealing with input validation...that don't involve OO bloat etc, I really don't feel the need to go over them in this thread.And for your knowledge all my _GET, _POST, _SESSION and _COOKIE, etc. data is wrapped in a nice object and then unset.
The comment was about wrapping all superglobals not just post data, but $_POST is the one case where it more often than not makes sense to wrap it, as you usually need to validate it all anyways.The Zend guys think wrapping $_POST into an object isn't a bad idea either
I think this is an emerging best practice in PHP. The benefit of encapsulating access to the request input is improved security and easier security auditing, not to mention the potential for eliminating duplicate code.
I never said I would ignore your posts, you said that... anyways...
Thanks, you supplied an argument instead of saying "that sucks" - Ok I'd agree not all applications need this, but if you're using some type of framework(ZF,m4,CI,Cake,Symfony, etc.) it usually helps alot as you can restrict access to the input - so not every action, command and module can go nuts(as in change them, etc.) on the input data.
A bit presumptuous, perhaps?Zend_InputFilter sets the array that is passed ($_POST) to NULL
Posting Permissions
Bookmarks