Re: notice and warning

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? ;-)

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



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.



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.


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?




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

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

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.

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





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'?

Not paying attention to where the data comes from?

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

Saying that using $_REQUEST 'scales better' is utter nonsense.
You have no clue what you are talking about when you say such things.


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?
YOU brought up the reuse of my examplecode.
It was an example to make a point to you.
My example was not ment as a fullfledged superduper class fit for every and any situation!
Try to keep focussed, and stop bringing up irrelevant points.



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?

That is *Bad design* according to you?
Lol.



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.



as for willy-nilly deleting a user,
willy-nilly?
I have honestly no clue what that means, since I am not a native english speaker. Sorry. :-)

sorry. it means to choose something based on nothing - haphazardly.

Ah, ok, thx.



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.

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.



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?

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.



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.
You are fixing things you broke yourself and call that good programming.
If using the right superglobals is over your head, well, stick to $_REQUEST, and make it look smarter by naming it your *business logic*.

What do I care?
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.

Yes, I get Jerry now.
But I am not in the habbit of plonking.



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.

Why?

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

Why not?

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

You are thinking up problems that are not there.
I expect you started using $_REQUEST when you were a PHP freshman, and never learned it doing the right way.


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.
And stop telling me using $_REQUEST has anything to do with scaling, it is too stupid for my brains to process, and it hurts.



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!



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


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!


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.

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



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 can only say you lost some of MY respect in this discussion.
Not because your use $_REQUEST (we all make mistakes), but because your inability to learn.
That is weak in my book.

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


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?

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

Wrong.
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.
You are only creating a problem by letting $_REQUEST do the job. That is why you have to be carefull to avoid collisions in the hashes.
You CREATE a problem you solve yourself.
I avoid the problem.



So, in my opinion, it is always better to state where you get your data from.
i haven't found that to be my case. i do use post/get/cookie specifically, but only when it is absolutely needed...like obfuscating security, i.e. processing a request that should have both get and post data, not just one or the other.
I am glad you found a reason to use it, but honestly that reason doesn't make a lot of sense to me.

i'm making an effort to show that i understand your POV. try it sometime. :)

Sorry mate. :-/
If that is security for you, you'll have still a long way to go.

i'm well aware of that.

Using $_GET or $_POST or $_REQUEST has absolutely nothing to do with security.
They only have to do good clean programming, which is of course the first step to secure applications.

just as get/post/request/cookie have absolutely little to do with how your application *should* process inputs in a formal system. the 'little' being minute enough to almost discount completely.

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.

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.

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'll repeat my argument in (hopefully) clearer language:
Firstly, a userid in a well designed database has an incremental number.
So to keep to the above example:

Your app takes a userid, lets say 12345
Your way:
Something like this:

if (isset($_REQUEST["userid"])){
$delUserid = (int)$_REQUEST["userid"];
if (..currentuserhasrightstodelete_$delUserid..){
// Code to delete a user based on $delUserid.
}
}

Right?

My argument against that:
Somebody extends your application, maybe you, and needs *the-userid-of-the-currently-logged-in-user* in a session or cookie for that, so he stores it in $_SESSION["userid"].
(I don't know if your $_REQUEST expands to $_SESSION too, but that is not important for my argument.)

Now if somebody calls this userdelete.php script for whatever reason, the currently-logged-in-user (being youself) will be deleted, since you didn't care to specify it to POST instead of REQUEST.

That was my argument.
You can try to weaken my argument by throwing your security-classes at my head, and saying it scales better, and taking all kinds of precautions to avoid the same keys in GET/POST/COOKIE/SERVER/etc, but I still say you are lazy and could have avoided this situation altogether by simply using POST if you expect the data from a posting.

It is not too complicated, allthough you try to complicate it.



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.

No, I never do that. Why do you think so?
If I write a script that expects a value from a form with action="post", I simply use $_POST["thatkey"] to get it.

If I expect a GET from some URL, I simply use $_GET["thatkey"] to get the value.

I cannot remember I was ever in the situation I needed to take different actions based on this...



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.

Now I am recycling ids?
I never did that the last 15 years.

I really have the impression you have some mental image in your head of how I work, and I can't see how it got in there.
Nothing I wrote implicated what you say.

Why don't you stick to the facts and the problem at hand?



post doesn't know
that the user is doing something they ought not do, neither does get, nor cookie.
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, there is nothing unwise about $_REQUEST.

Yes there is: I told you many times why now.




if that's how you validate user interaction with your system, i hope
you're a good magician.
???
I wonder how you communicate with user if you don't use their info.
Post/Get/Cookie are the only communication you have with a webclient....

that's not what i'm saying. if you expect another developer to be able to read your mind as to what meaning "id" has if it comes in via POST vs. GET vs. COOKIE, then you had better brush up on your magic skills and the other developer should have the name Karnack!

I will never pass 'id' but 'userid' or 'articleid' or whatever.
Only a stupid programmer will not understand the 'userid' will probably have something to with some table in the database probably named 'tbluser' or something.

I do not expect mindreading/magic whatever. I expect a serious programmer who thinks.


And no, I am not Richard Stallman, I am no magician, that is why I program defensive.
I hold that as a good habit.

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.

???
Firstly: passing 'id' around is not really recommended by me.
Secondly: You seems to think that using $_POST and $_GET is somehow very strange and will suprise another programmer.
It will not.
I even daresay good programmers will prefer them over $_REQUEST.
I have no 'rule' besides that when I post info with action="Post" I expect the receiving script to use $_POST[] to get that info.

You may call that my 'rule' and my 'magic' all you like, but that won't help you.
It is very simple and basic and EVERY EXPERIENCED PHP programmer will know right away what I am doing.

This whole 'magic' bull*** of you sounds to me like:
"AAARGH!! You are joining strings with the . operator! You better document that 'magic rule' of yours very well. Nobody will understand it."

It is all so darn basic that I am suprised to find myself in this discussion.


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?!

Yes, I learned from the best!


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.

So because you and your coworkers prefer $_REQUEST, that makes it right?
http://skepticwiki.org/index.php/Argument_from_Popularity


what you've just said is a logical fallacy. look that term up, then tell me which one it was...i'll give you a prize. :)

You are right! That was a logical fallacy, I immediatly admit that.
Well spotted Dave/Barry/whatever!

Now for the prize: (what is it by the way?)
I think "Affirming_the_Consequent".

I am not 100% sure, but my guess would be:
If 'A' then 'B'
'B'
Therefore 'A'

with:
Statement 'A': "Using $_REQUEST is inferior programming compared to using $_GET/$_POST/etc. Good programmers don't use $_REQUEST."

Consequence 'B': "Bad programmer use $_REQUEST."

(The original is slightly more complex, since I assume it would rub off on you meeting good programmers.)

I says: "Since you use $_REQUEST, you must be a bad programmer."

That way I didn't provide ANY proof for 'A', I merely stated it was true and that 'B' follows out of it (which is true).

So my guess is "Affirming_the_Consequent"
http://skepticwiki.org/index.php/Affirming_the_Consequent

Is that right?
If not, please put it in the right form. I like logical falacies.

You might also say this was an 'Ad Hominem'.


this is why we develop *architecture* that clearly defines
the condition(s) in which things can be done.
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.


I might say the same about $_REQUEST, and say you could as easily get your information from an CSV file or an XML file.
I totally agree that your architecture defines how the system works, but that has nothing to do with using $_REQUEST.

Why don't you write a super-duper-REQUEST that also checks every file on the sytem for the 'id'?
Why not?
Because you want to KNOW (or in your case SHOULD WANT TO KNOW) where the data comes from to know what it means.


It is an open door, and has nothing to do with the topic at hand.

wow! i'm doubting your fluency and literacy. at least it's not your native laguage, i can discount that.

Please simply correct me, that way I learn something new.
(Yes, I like to learn new things and appreciate being corrected when wrong.)

Is 'open door' wrong? (It is a Dutch expression)
I am quite sure 'topic at hand' is OKish.



Coreproblem is simply this: You are receiving your data from unknown sources instead of pinpointing where your data comes from.

simply put as well: it should matter very little where your data comes from as long as you have your business logic set up so that it is *decoupled* from the input's context - whether browser or cli!

We have been over that.
I say it DOES matter, allthough I believe you can do it right with only $_REQUEST if you take a lot of precautions like you forced yourself into.


That is inferior programming compared to being more specific.
Period.

having multiple meanings for 'id' because of the superglobal housing it is NOT specific at all to the meanining itself.

Again, using 'id' is very stupid since it is undescriptive.
I used 'userid' in my example.


can you search php doc's and
find out the specific implementation for POST as it relates to your application? can your developer know without asking you that POST['id'] refers to the currently logged on user, and that GET['id'] means the id of some other user that should be deleted?

I seriously think you should reread my original postings and example.
You are saying things I never said/claimed or even wanted to imply.

For clearity's sake: I think it is utter stupid to post an 'userid' to the same script, where the GET menas something else than the $_POST variant.
I never did it, and will never advise to do so.

Go reread, and try to understand my simple example.


the answer is no, which is why your example fails to make your case.


If your assumptions were right: yes. I couldn't agree more.

What architecture you use has little to do with my above statement.

it has everything to do with it. research 'decoupling', then try and bring that knowledge back here. then tell me how you decouple your business logic from it's implementation. then, tell me again that you're right...without blushing. :)

Learn to read before being a smartass.
You make a fool out of yourself.


I mean, if a script allows to delete a user (passed by userid) is up to the script, and the problem at hand.
That is valid for both our positions! (your $_REQUEST or my specific superglobal.)

the fact that it IS valid for both positions and the fact that YOU ACKNOWLEDGE IT, simply means you've negated everything you've said! as it was never my claim to NOT use specific superglobals, and yours that REQUEST should be written out of the language, i thank you for declaring me the winner of this little chat!

Three possibilities comes into mind:
1) I write very confusing for you. You misinterpret all I say. (That could very well be because I must write in english, but I think my example was very clear.)
2) You are unable to think logically
3) I am unable to think logically

Right now I hold position 1).



it keeps users from doing
things they shouldn't and developers aware of the rules in place so they too don't do something they shouldn't...at least if they do, you can easily pin-point where things went wrong. :)
Yes, using $_POST/$_GET/$_COOKIE instead of $_REQUEST will surely keep you busy with pinpointing problems.
You haven't given me ANY reason to use $_REQUEST yet.

ahhh, editing sure makes that more accurate. and what's more, you haven't given me ANY reason to NOT use $_REQUEST yet. as it is, i never TRIED to get you to use it. i just asked what was wrong with using it. as it stands, i remain unaffected and wholly unconvinced.

I gave you an example.
I showed that using $_REQUEST leads faster to problems when the application is extended with my example that deletes a user. Using $_REQUEST makes it possible the script was called unwanted, and a user gets deleted because some other UNRELATED supergloabl holds a key with the same name.
I don't think that was too difficult.

You, however, showed nothing. Not one reason to use $_REQUEST, except that nonsense about scalability.


I think we work widely different...

perhaps. perhaps not. this is a difference of opinion to me, nothing more.


Right now I think you misread my example.
I hope that was the case.
Please retry and don't put words into my mouth like: "You use the key 'userid' in the same script differently for $_GET context than for $_POST context.". I never claimed such stupid stuff, you dreamed that up.


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

Still working on it then?
If you work for all those great companies who need your advise, why don't you try good captalisation in your pieces?

Regards,
Erwin Moller

.