Re: notice and warning

..oO(Dale)

"Erwin Moller"
<Since_humans_read_this_I_am_spammed_too_much@xxxxxxxxxxxxxxxx> wrote in
message news:488760ea$0$49891$e4fe514c@xxxxxxxxxxxxxxxxx

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). :)

This is childish.

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.

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).

That's just a broken design. It seems that you haven't understood the
differences between POST and GET and when you should use one or the
other.

In short: Listing should done with GET, changing with POST. Simple and
reliable.

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.

POST and GET _do_ have a totally different meaning, otherwise we would
not have these various methods at all. There are important differences
between them on the HTTP level and how user agents handle them.

BTW: How do you handle file uploads? Technically they're also just some
input data, but can't be found in $_REQUEST. Doesn't this violate your
world view of "good design"?

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

Better design takes exactly the data it expects from exactly the source
where it's supposed to come from.

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?

$_GET['foo']
$_POST['foo']
$_COOKIE['foo']
$_SESSION['foo']

Same hash, totally different things. They simply can't overlap.

If you use the right superglobals, you'll NEVER think about that 'problem'
again.

if i specify the 'right superglobals' as having some kind of association to
business logic/decisions/actions, i have created failure and invited
mistakes. you cannot enforce your system's design with input venues! 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.

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.

_You_ are relying on some kind of magic when using $_REQUEST. Its
meaning is totally unclear and its structure depends on configuration
options.

In my framework I can reuse hash keys, I can scale, no one (except for
myself) can f**k it up and I don't rely on any magic. I exactly define
and document where I expect which data from and my scripts simply work
by following these rules.

If we stick to your example: You say using $_REQUEST scales better.
I say it bugs better. ;-)

no, the mistake is in allowing your system to *reuse* user id's...not how
it came about that someone is just saying to delete said id.

Mistake?
Let me restate that, it is getting more and more amusing.

Do you claim that: "Since it is better to use $_REQUEST over
$_POST/$_GET/etc, you should also NEVER use the same variable (or better:
key in associative array) in your posts/session/get/cookie."

Is THAT what you say?

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.

The real mistake here is to allow a delete action invoked by GET. That's
just BAD (broken as designed). There are much more ways to trigger a GET
request than a POST request. If you don't take this into account, a bot
or even a browser may automatically screw-up your system.

Of course reusing internal IDs and primary keys is bad as well, but not
the main issue here.

as it is, you mean that 'id' is possibly in post and/or get. and, that each
context (post/get) means for 'id' has different meanings or should direct
your application to take differnt action. that's dangerous business.

Nope, it's absolutely correct behaviour and follows the different
semantics of GET and POST as defined in the HTTP standard.

what i am saying is that not recycling db "id's" and not overlapping input
hash key names ("id") and SPELLING OUT their *context* such as 'deleteId'
and 'loggedInUserId' not only takes the *magic* out of your application, it
also makes it safe to use REQUEST.

Too much work for me. The last two steps are totally unnecessary with
proper handling of input data. In fact you're doing much more work to
keep your application safe just for the sake of using $_REQUEST.

I can easily reuse hashs and don't have to use this kind of "Hungarian
Notation" to spell out their context, simply because the context is
already given by the data source itself. There's nothing magic about it,
everything is exactly and well defined, quite contrary to $_REQUEST.

post doesn't know
that the user is doing something they ought not do, neither does get, nor
cookie.

GET and COOKIE at least "know" that they shouldn't change the server
state. That's what POST is for.

Indeed. They are merely superglobals, one shouldn't expect them to know
anything except what they are build for: holding the information they are
suposed to hold. Using them wisely is up to the programmer that implements
them.

no problem there. and, if you have good design

With a lot of additional steps ...

there is nothing unwise
about $_REQUEST.

.... to keep the design safe.

you'll find another co-worker, oblivious to your
post/get/cookie 'rule' and he'll kill your how dataset of users
inadvertently.

What? My 'rule'?

damn! in *your own example*, you expect a hash key of 'id'. all the while,
you expect it to have additional/specific meaning based on what superglobal
it is in. that is an implicit rule! if your other developer is not aware of
your rule, you code is shot to hell and your data will bear the results.

man documentation

Other developers always have to follow the rules you define if they want
to get their code working with yours. Every single API requires that. If
they don't follow your rules - their problem.

And something tells me you haven't worked too often with other PHP
programmers, otherwise you surely would avoid $_REQUEST.

wow! assumptive, are we not?! i work every day with 22 other professional
php developers. that's just with my full-time job. i work for two other
companies as a consultant...and, i'm not alone there either.

No offense intended, though, but I don't consider it professional to use
$_REQUEST. And I don't like consultants either, because too often they
are responsible for the worst crap of code. TheDailyWTF is full of such
stories.

Good for you.
But this sounds as empty to me as: "That is why we try to develop software
without bugs."

perhaps you missed it, that ARCHITECTURE THAT DEFINES HOW THE SYSTEM WORKS.
saying 'id' has a meaning to you in POST that it doesn't in GET simply DOES
NOT DEFINE ANYTHING!!! it is magic, not architecture.

$_GET['id'] - get informations about a user
$_POST['id'] - modify the user record
$_SESSION['id'] - keep the user logged-in

This is architecture, not magic.

PS: Please try to use CAPITALS at the beginning of your sentences. Makes
it so much easier to read for me. :-)

i'll think about it. :)

Obviously not.

Micha
.