Re: notice and warning


"Michael Fesser" <netizen@xxxxxx> wrote in message
news:rtpg845c4lufs27lgkiic1domqbea7pqlu@xxxxxxxxxx
.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"?

i was very careful to say that there are cases where you'd want to use a
specific sg, file uploads is not the only case. i gave another example as
well, such as cli.

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.

the exact source, for me, is the end user. :)

<snip>

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

i want to take input from a caller...that's it. i don't really care what the
configuration options are...but, i do control those. the meaning is crystal
clear...i'm taking input from a caller.

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.

i'm talking about large projects with multiple developers. we must work in
two different worlds.

<snip>

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.

i'm not talking about your gui. i'm talking about what happens to the data
you're about to process. that is defined by you, not an 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.

no, it has nothing to do with making it safe to use request...at all. 'id'
should have specific meaning. if 'id' refers to one thing coming from post,
and another from get, do you think that's very clear to what entity 'id'
refers?

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.

i don't care what kind of notation it is - and, it's
camel-casing...certainly NOT hungarian notation. hungarian, btw, is a
variable's datatype prefixing the variable. this is simply a case of giving
a variable a *meaningful* name...rather than, say, $tmp - meaningless!

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.

where the hell are you getting this non-sense?!

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

those steps need only be handled in a few places and avoid the scenarios i
pointed out. i'd rather decouple than tie into an input mechanism. you
obviously don't.

there is nothing unwise
about $_REQUEST.

... to keep the design safe.

lol. i think we're just at a point of personal preferences now. it seems
you've stopped listening. you certainly haven't countered any points i've
made thus far.

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

sorry, you won't find anything in man.

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.

omg! no, it's everyone's problem including customers. you should NOT set up
a system that doesn't take precautions to keep errors at bay...and away from
your data.

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.

well, i can't help your view of consultants. some are good and some are bad.
what can i say? given that i've been retained for almost four years by both
companies probably means they like my work.

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.

when i can get information about a user regarless of taking the 'id' via
post/get/cookie/session, it becomes magic to think GET actually means 'get
me some information', the same with post. they have no meaning...just a
standard on how the data is passed to a server.

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.

no, i did think about it. obviously, my thought is, 'nah'. :)


.

Relevant Pages

  • The Reason Why LOGOS Went Away is Obvious: Here it is
    ... There are two distinct meanings of design at play. ... This meaning of design simply says ... Here I assume you are referring to fractals as creating a design ... Adam I and Adam II - representing ...
    (talk.origins)
  • Re: The Reason Why LOGOS Went Away is Obvious: Here it is
    ... The poster who originally wrote these words about Meaning 1 and ... Intelligent Design Should Be Simple to Produce". ... natural processes produce designs such as snowflakes or fractals. ... an intelligent designer for fractal patterns made by Jackson Pollack ...
    (talk.origins)
  • Re: Making Life From Scratch, If the Creator Can Do It, It Must Be Easy
    ... There are two distinct meanings of design at play. ... Meaning 1) In one, ... at how fractals of great similarity can at multiple levels of scale. ... Adam I and Adam II - ...
    (talk.origins)
  • Re: Hyperlinks
    ... http://www.snipesfamily.net/index_files/DAVE.htm The issue is that Publisher ... the design checker tool will find some of these issues. ... I am betting that you are using a script on your home page that you are not ... I have seen a lot of Publisher produced sites that load ...
    (microsoft.public.publisher.webdesign)
  • Re: notice and warning
    ... You expect some piece of data from a post in your script, ... prefer $_REQUEST over $_POST. ... the different meanings the input should have based on how it arrives. ... that's bad design. ...
    (comp.lang.php)