Re: notice and warning


"Erwin Moller"
<Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in
message news:488875b8$0$49822$e4fe514c@xxxxxxxxxxxxxxxxx
Dale schreef:

<snip>

Sorry, I thought the other post was all what you had to say, but you wrote
much more in here. My bad.

So, I will answer this one too. :-)


what's wrong with $_REQUEST, erwin? i use it as standard practice. i
have the order set in the php.ini to my liking - it happens to be the
default. if i need to get fussy where my data is coming from, then i
specifically use the one i need, i.e. $_POST/GET/COOKIE et. al..
using $_REQUEST scales better also since you may change your
implementation on how the script is being called/used. being specific
when not needed means you'll have to re-write that portion of the
script...not so with $_REQUEST.

just wondering what your reasoning is.
An example:
You expect some piece of data from a post in your script, eg: userid.
So you use $_REQUEST["userid"] which works perfectly fine as long as
you get the userid in via POST.
Let's say this script deletes user the user: userdelete.php
So we have userdelete.php that expects a userid from POST.

Now suppose you leave your fine-running app for a year or so, untill
your client wants some upgrades to it.
In some unrelated part of your app you decide to store a userid in the
$_SESSION so you have it easy at hand on some other pages. The userid
contains the userid of the currently logged in user.

Now you find yourself in the situation that when you call this script
for any reason without the POST info, you will delete yourself if you
prefer $_REQUEST over $_POST.

Same can happen with get of course.
Hi Dale,

Are you the same as Barry by the way?

yes...i'm playing with jerry stuckle. he likes to plonk people who
disagree with him. i'm trying to fill up his filter(s). :)

Oh...
Don't you have anything better to do?
Like fixing $_REQUEST in all your scripts? ;-)

hee, hee, hee. :)

not really. i come here while waiting for conference calls or emails and
such. i really can't do too much else inbetween.

For the record: I have totally no problems with Jerry. He can be unriendly
at times (often as a reaction to what the other wrote), but he knows
freaking well what he is doing when he talks about PHP. This group would
be less valuable without him.
If you don't see that, that is your loss.
But let's not discuss Jerry. Too many threads did that already. ;-)

now if he'd just stick to php, that'd be fine. and, given the number of
threads about jerry, i believe you are one of a handful with 'totally no
problems'. :)

as well as cookie. i don't see the point. how you get the input in this
scenario is not going to be problematic to the script...not programming
for the scenario itself is.
I thought I just pointed out how it can be problematic.

like i said in the other post, it's just not at all a strong case to me.
i rely on objects that verify and validate things and the branching
actions that should follow. how the input arrives, in my system anyway,
has *nothing* to do with those particulars...just that i have input to
work with. it's decoupling of the interface.

Good.
Sounds good to me (seriously).
But wether a user has rights to delete somebody else has little to do with
our discussion about $_REQUEST versus the appropriate superglobals.
Of course you should program this right, in both situations.

i completely understand your approach. i just don't use it. but for you to
say request should be taken out of the language simply doesn't enhance the
language or further development endeavors.

as for not relating to the discussion, i had said that i unset variables in
certain contexts (i.e. user class) to avoid overlap/reuse. you said there
was no need to unset. the above of which you are commenting is a discussion
of oop. so: unsetting->user class->oop->verify/validate->branching
actions...it relates to me anyway.


With a simple example (the userdelete-script) that shows how you
needlessly complicate things if using $_REQUEST.

i also said how needlessly easy it is for another user to overlap
superglobals and *** up your db's data - because you rely on how the
input arrives, not by enforcing rules in the business logic that governs
your site.

What?
How did you arive to the conclusion I don't enforce any rules?
Don't assume too much, it won't help you understanding what I try to say.

i'm not trying to force a conclusion, i probably just needed to give an
example. a form can get or put. what if a developer, oblivious to your
'rules', wanted to enhance the view of the users page. if he made his form a
'post' form rather than a 'get', it would take several deleted users before
he'd stop and say, 'what happened here?'.

of course that would be on test data during the course of development, but
it's a simple example and much more subtle effect are to be had...and they
may make it to production.

whether i use request/post/get/cookie, none of your example prevents
disaster...it is merely a hope that all developers know your *hash key*
and the different meanings the input should have based on how it arrives.
that's just a new case of 'magic numbering', just with input venues. it's
not good design.

Nonsense.
I hope for nothing, I expect somebody who exentds my programs to have a
reasonable experience, and checks where data comes from.

I have nu clue what your magic numbering reference means in this
discussion.
Not sure, but are you maybe thinking I use the appropriate superglobal for
*security reasons* ???
If so: I AM NOT. THEY DON'T OFFER ANY ADDITIONAL SECURITY.
Clear enough?

yeah, that's clear. that's not what i was thinking, but it certainly means
that i'll stop myself from ever considering it now. :)



further, i may want to reuse userdelete.php in
another script...users.php. you are forcing users.php to inherit
userdelete.php's implemenations. that's bad design.
I have no clue what you are saying here.
How on Earth are you going to reuse code in another script without
checking if it fits in???

require_once, include_once, f_open, file_get_contents, etc.. there are a
number of ways to incorporate the reuse of code bases.

Pffft.
I begin to see why Jerry plonked you..

what is 'pffft' about that? they're examples of utilizing code in multiple
venues. as for 'checking if it fits', that's my point! i already told you
that something will HAVE TO BE MADE TO FIT, if you want to
include/require/etc. if script doing the inclusion is ignorant of your
get/post/cookie schema of taking input. please re-read what i said.

You refuse to answer questions seriously.

why do you think i'm not serious?!

You assume a lot of stupid things about the other (me), like I need your
help on how to include/require/etc some code.

i've answered whatever questions you've posed. what the hell are you talking
about? you didn't know what i meant by 'reusing code'...i gave examples.
further if get/post/cookie are keeping a large code base from being reused
because it doesn't 'fit in', you have a lot of work to do in order to be
able to scale.

Dave/Barry/whatever: I have over 25 years of programming experience. 15
years as a fulltime profesional. You don't have to explain to me how I
reuse code.

wow, i've obviously upset/offended you. that wasn't my intent.

I am wasting my time here because I want to help you.
If your attitude keeps like this, we are over.

we're not boyfriend and girlfriend you know. you can leave it at "i've tried
to explain, it's up to you to understand". no need to get pissy.


My example is not 'inheriting' anything.

one of my points was about scaling. the one script may best have it's
functionality included somewhere else. for your sake, say you have a
script called users.php. that script lists, edits, deletes users. it may
'get' an input to delete something, at which point, it would want to
include_once deleteuser.php. since deleteuser.php expects a 'post' for
the id of the user to delete, the action won't be performed - no
deletion. if i have edituser.php that expects 'get' inputs, it would be
able to successfully edit a user.

clear.


if i want to reuse deleteuser.php, i either have to make it accept 'get'
inputs and thereby change my previously 'magic' business rules, or, i'd
have to change users.php to either now expect 'post' instead of 'get', or
force it to copy the 'get' vars to 'post' vars so that all three scripts
would work (users.php, edituser.php, deleteuser.php).


indeed.

instead, i use REQUEST for nearly every script i write. i rely on
specifically programmed logic in the form of oop'd class objects to
enforce user input conformance and ensure they, nor other developers in
my system, *** anything up.

So this is what you call 'scaling'?

scaling is altering code to get new behaviours. an oop design is more
capable of scaling. if you have to reprogram something so it 'fits into'
your new planned behavior, it's not as 'easily' scaled. the example that i
just gave where your response was "clear" and "indeed" require
reprogramming. using a good oop design and REQUEST, for the example, means
that all i needed to do to reuse userdelete.php was to include/require it in
users.php. in this instance, it scales more 'easily'. clear?

Not paying attention to where the data comes from?

no...and i hope you read the explanation from above. i don't appreciate your
patronization either. i'm trying to have a serious discussion...which you
just claimed i wasn't trying to do! don't go and do it yourself now.

I have wildly different ideas about 'scaling well'.
They mainly involve good database design, smart queries, sessionstorage in
DB, loadbalancing if needed, etc.

that's part of it, but it shouldn't stop there.

Saying that using $_REQUEST 'scales better' is utter nonsense.

no, it's not.

You have no clue what you are talking about when you say such things.

read what i just explained.

It was just ment as an example for ONE script, not some class you
implement everywhere...
If you copy/paste code from one script to the next script without
understanding 100% what you are doing, you are bound for serious
trouble.

no one said anything about that. reusing code is !== copy/paste!

Then why did you say that?

i didn't. you seemed to think my reuse of code involved copy/paste. your
quote 4 lines up, just to refresh your memory.

YOU brought up the reuse of my examplecode.

yes, and it had nothing to do with copy/paste. it had everything to do with
userdelete.php being a stand-alone script and that reusing by inclusion in
users.php wouldn't scale easily if users.php didn't follow your get/post
rules.

It was an example to make a point to you.

i think most all examples are mean for that reason. where are you going with
that comment?!

My example was not ment as a fullfledged superduper class fit for every
and any situation!

yet when designing code, you cannot forego thinking about how accessible and
expandable your current functionality is.

Try to keep focussed, and stop bringing up irrelevant points.

i am not bringing up irrelevant points. please tell me how anything i've
said is so.

And what 'bad design'?
Are you claiming using $_REQUEST instead of $_POST/$_GET/whatever, is
BETTER design? You can't be serious.

i'm saying that *how* your input arrives is irrelevant to how your system
operates. relying on data coming from one venue (POST) to mean something
completely different from another (GET) is an exercise in bad design.


What is wrong with expecting data coming into $_POST when I use a form
with Method="Post" to get the info in there?

nothing. however, method can also be 'get'...and when the data arrives and
you plan to take different actions on whether it was 'get' or 'post', you
could have problems. the 'method' has been coupled with your decision
tree...your business logic. understand?

That is *Bad design* according to you?

not decoupling your interface from your business logic *is* bad design. you
simply haven't understood my point yet.

Lol.

hardy-har-har. now, where does THAT get us?

my claim is that BETTER design is removing the importance or related
meaning to the venue(s) from which we expect input.

Yes, don't worry. I totally understand what it is you are claiming.

i don't think you do, or you wouldn't be lol-ing so much and trying to be
snide. i'm not being nasty, why are you starting to? this is a discussion,
not an argument.

<snip>

a confirmation that the end-user really
wants to delete user x helps avoid that.
Of course it avoids that.
I was just giving you a possible scenario where using $_REQUEST leads to
trouble.

right, i just don't think there's a good way for you to make a good case
using the example you gave. perhaps a different one?

No.
If you are unable to extend my example yourself, and keep insisting on
defending YOURSELF instead of focussing on what good programming practice
would be, then I give up.

apparently, 'good programming practice' is what is being focused on. we are
disagreeing. and, just as you are doing, i'm defening my POINT not MYSELF.
not only have i extended your example, i used it to demonstrate my point.
decoupling IS GOOD PROGRAMMING PRACTICE. the debate should now be about
'does the input method couple or decouple my business logic from the user
interface?'. to me, that answer is painfully apparent.

I have better things to do.
Seriously: keep $_REQUEST'ing and making code that avoids the same HASH in
superglobals all you like.
Why should I care?
I merely wanted to help/warn you, not having a pissingcontest.

and i just wanted to know what your reasons were for your distain of
REQUEST. this isn't a pissing contest. it's called a discussion.

So let's say for the sake of the discussion that in my example the
scripts posted to is the script AFTER the confirmation, ok?

Let's please not dive into such silly arguments as when to show a
warning and when not. That is beside the point I think.

uhm, no, it's not silly - it's relevant.

sure.


however, the catch all is not
REUSING the ID in the first place. that's just asking for trouble.

again, that is what i initially countered with AND, it removes the need
to magically rely on, and assume different meanings for, different input
venues (post/get/cookie).

It is really funny how you keep naming POST/GET?COOKIE magical.
Is your steeringwheel in your car magical? And the breakes? Magical too?

there you go again. <sigh>

they are not magical. assigning *meaning* to how input arrives will have to
'magically' be understood by you and your developers - they mean 'show
information' when GET, or 'edit/delete information' when POST. i've no idea
how muddled life becomes for you when you describe SESSION...is that just,
'anything in here should just be toted around'. and COOKIE?

do you get the point yet?

We are talking basic buildingblocks here for PHP applications.
Nothing magical about them, nor with using them right.
You can keep repeating that I have 'magic rules', but that will probably
only convince yourself.

it's not about convincing. it's about explaining. i've done my best, it's up
to you to understand...if you want to. i've understood your case by
parroting it back to you and modifying it enough to express my point. i
assume you know my point well enough to do the same? if not, i'd appreciate
you telling me where you are confused...that, or re-reading this post.

yes, it is asking for trouble.

If you are in the habbit of using $_REQUEST it is indeed asking for
trouble....

no. as you just said, the 'catch all' is not 'reusing' hash keys. all
else is just as prone to the same downfalls mentioned in your example.
how does one prevent key overlap/reuse? i have pointed to oop'd business
logic to drive your system rather than input-magic.

You showed you program poorly.

really? how's that?

You are fixing things you broke yourself and call that good programming.

i never broke anything! where are you getting that?!

If using the right superglobals is over your head, well, stick to
$_REQUEST, and make it look smarter by naming it your *business logic*.

i know damn well how input methods work. i decouple the interface from the
logic. perhaps you need a refresher on (or an introduction to) decoupling!

What do I care?

i don't know. what's more, you're quickly removing my interests here.

I repeat: I was trying to help you so you learned something, and could
avoid stupid problems in the future.
But you clearly showed you don't give a damn what I say, and also don't
listen to me, and twist my words whenever it suits you.

wow! you're pissed. why?

<snip>

if i specify the 'right superglobals' as having some kind of association
to business logic/decisions/actions, i have created failure and invited
mistakes.

Why?

uh, scaling, decoupling, actions are taken based on input method rather than
a formal model of logic which can be controlled.

you cannot enforce your system's design with input venues!

Why not?

not everyone uses get/post/et.al. as you do. further, if you exercise the
right logic on the wrong input venue, you're fucked. there is no mechanism
in place, other than you telling them verbally, to stop them from mis-using
get/post/et.al. THAT is why it is uninforceable.

your appropriate counter here would be to tell me how you CAN enforce system
design using input venues.

If I send you some XML file with data, do you respond with: YOU CANNOT
FORCE ME INTO YOUR DATAFORMAT!!
Of course not.

that's not even close to the same thing! even as it is, this is support for
ME, not YOU! all i care about is receiving the xml. i couldn't care two
flying fucks if i got it from a soap request or from a form upload! i will
apply validation over the input either way.

you're saying that you will do *different* things with the xml because it
was a soap call or a form upload.

You are thinking up problems that are not there.

if at all, i'm thinking ahead. don't worry though, i'll filter out those
that don't matter. at least i've have programmed with something else in mind
than just making something initially work.

I expect you started using $_REQUEST when you were a PHP freshman, and
never learned it doing the right way.

quite the inverse. but you just keep trying to insult me if that makes you
feel better. :)

you
simply can't! either a user is going to hose you up, or a developer is
going to bite you in the ass. that, and you can't scale easily with that
architecture.

LMAO!
You are the one with bad design.

really? you've never seen my code and you scarcely understand the simple
counter examples i've spelled out. how would you know, really?!

And stop telling me using $_REQUEST has anything to do with scaling, it is
too stupid for my brains to process, and it hurts.

i gave you the definition. i gave you the example, a simple one. if that
makes your brain hurt, i suspect it is not from it being beneath your
capacity. i think you know what i mean.

if i don't allow the reuse of hash keys, i can scale. i can also enforce
my business rules (et. al.) and keep both the user and the developers
from fucking my system over. and finally, we aren't working with magical
meanings of data based on where it came from - we have a document system
of behaviors instead.

Yes, we have been through your ideas of 'scaling'.
Ouch!

i've already, long ago, gotten that you're disinterested. why not just drop
out of the thread then?

again, i think a better example is needed...though i do appreciate this
one.
Here is one:
You receive a phonecall:
A friendly female voice says:
"Hi Barry/Dale, this is a collect call from... "
Barry/Dale interrupt: "I don't care where it comes from, I'll take it
anyway."

i may do that in real life anyway. i have free global phone service. but,
this IS a perfect example. you assume that your solution fits EVERY
system in the world. in my 'phone' system, i want to take calls, wtf does
it matter to me where it's coming from? your 'phone' system may cost an
arm and a leg. you may interupt and say "i don't care where it comes
from, i refuse the connection". you also may have several places where
the phone call could have come from - dude, you've only got 3 php input
venues...get/post/cookie - this set could mean that you require more
meanings your phone than what get/post/cookie can magically afford.

oop'd design handles that and scales all the scenarios i mentioned...and
couldn't care less about the OPERATOR that is forwarding the call. which
btw, the operator is akin to post/get/cookie NOT where in the world the
call came from. :)

You managed to reword that all in a way that makes you feel god, right?
Enjoy. :-)

only so that the example you gave would *somehow* relate to the topic at
hand!

Well, that is just a silly joke, but I am firmly convinced you should
take your data where it is supposed to come from, so never use
$_REQUEST.

the data is supposed to come. 'from' is almost irrelevant if your system
is design properly. the only expection should be cli - no
post/get/cookie.

Besides that: Using $_REQUEST simply doesn't offer any advantage at all,
only slightly shorter code in some cases.

no, it allows you scale and reuse code. there are other reasons as well,
the biggest being that your system shouldn't be enforcing it's design
based on a non-enforceable construct such as input superglobals.

Haha!


hardy-har-har. again, where does that get us? if you think you can enforce
business logic over a superglobal, i'm all ears!

Do you use:
SELECT * FROM ....
instead of naming the columns too?

no, but i hardly see a comparison to be made here. in my db, there's only
one place i can get data. from the browser, there are several.


Oh well, it was just a question.

a pretty lame one. see, the thing about trying to be patronizing is that you
have to do it well in order for you not to look silly. you should start with
content that relates to the discussion.

I expected you to answer: "Of course I use 'SELECT * FROM...' since it
scales better! If I add a column to my table later in the process, I have
the data right at hand.".

again, you just can't make points using examples that don't support them.

select only what you need, and especially, insert using specified columns.
adding that same new column and inserting into the table without specific
columns fucks up the works, now, don't it! and, if i need to use a new
column somewhere, i'll have to go into the script and add it for display
anyway - it just means while i'm at it, i'll have to add the column to the
select.

i'm not stupid, but your example is certainly lack-luster.

Of course, all this can be avoided easily if your program perfectly
and never make mistakes, but I doubt that. ;-)
there are mistakes like using $someVar in one place and $someVare in
another - a type-o. a script that has not been tested for the most
basic of things, as in this example, is no mistake. it is poor
workmanship. i can guarantee that *every* time i program something,
there will *never* be poor workmanship in it even though it will have
had, at some point, mistakes in it.

don't doubt that.

I do not want to insult you: But since you prefer using $_REQUEST over
the appropriate superglobals, I do doubt your workmanship.

and i'm not so concerned about that. my workmanship is confirmed
superlative not only in words, awards, and project proposals; it's also
confirmed by the caliber of the companies that keep me gainfully
employed.

Good for you.
Enjoy it, and don't forget to scale well. ;-)

i won't. flexible code, tight design, future enhancements, maintainable
source...that's all important to me. <sigh> if only you would throw some
sarcasm my way...that'd make my day.

I can only say you lost some of MY respect in this discussion.

like i give a *** now! you've trolled through half of this post and NEVER
showed you understood what i was saying. that's far different than just
disagreeing with what i said, btw!

Not because your use $_REQUEST (we all make mistakes), but because your
inability to learn.
That is weak in my book.

being an ass is pretty demeritous in mine as well.

But since I don't employ you, my lost respect shouldn't be a problem for
you. :-)

yawn.

Of course, you can always change my mind by giving a valid reason why
you do so. I don't think there is one.

for now, let's stick to you giving me a valid reason why you should not.

I expected that.
Still no reason.
Why don't you claim 'it scales better' without giving a valid reason?

dude! i've given examples AND explained till i'm blue in the face! can you
not at least try to show you understand by putting my POV in your own words
here? at least i'd know you were listening. plus, i'd probably readily see
where you are having problems understanding.

your examples thus far have failed to make your case...and, i asked
first.

Wrong.

according to you.

My example showed a scenario where data comes into an app that was ment
for something else.
You counter that by claiming that your receiving script should handle that
the right way.
I say that is nonsense, since every good writen script should handle the
data it receives the right way, no matter where it comes from.

'no matter where it comes from' IS MY POINT, nong-nong! you seem to think
handling it the 'right way' is BASED on WHERE it came from!!!

You are only creating a problem by letting $_REQUEST do the job.

request is not doing ANY job for me other than giving me data! ONLY IN YOUR
WORLD does get/post/cookie/session cause your intercept of data to branch to
different types of action! THAT is 'letting [something] do the job'.

That is why you have to be carefull to avoid collisions in the hashes.

your method, my method...BOTH require being careful. that's not a point
either of us can claim. you'll notice that it's not one i've tried to have.
that's your second attempt!

You CREATE a problem you solve yourself.

i have NO problems.

I avoid the problem.

only if your team of developers stick to the meanings you assign
GET/POST/COOKIE/SESSION. other than that, you're fucked in short order.

<snip>

no. i was referring to deleting a user having id 'A', years later (as you
say), someone comes back on a url query string to delete user 'A'. if
you're allowing your db to reuse id's, then that's your mistake.

Again you assume too much.
Why do you think the id is reused? Did I claim that?
You are thinking up bad programming practice I'll never use to make your
argument. Weak. Stick to the facts.

first, i didn't understand your english. second. i allowed for two possible
meanings. i followed up on both. either speak better english, or don't get
snippy when i follow a path you didn't intend.

I am talking about a existing id, somebody wanted to store in SESSION or
COOKIE or whatever. Then calling the deleteuser.php will delete this user.
It is just a damned simple example, why is it soo over your head?

i have had NO problem understanding YOUR example. you fail to see how it
breaks apart when i point out shortcomings to YOU.

I'll repeat my argument in (hopefully) clearer language:

no, at this point, i couldn't care less what you have to say. i'll just
forego the remains quips and snipes and barbs you're hurling. if you want to
continue to discuss this, then show me you understood one iota of what i
said simply by rephrasing it in your own words. you as of yet have failed
miserably at showing an interest in anything other than what you're running
on about.

cheers.

<snip diatribe>


.