On Tuesday, April 23, 2002, at 02:28 PM, Andre Dubuc wrote:
> I tried with "VALUES ($_GET['sfname'] etc, etc " and got a T_Variable
> error
> as you said would happen. I've yet to try what you've suggested, but
> since
> the "Test to ensure your PHP binary is working" shows that it is indeed
> funtioning, I think with the info you've provided, I should be able to
> pass
> the variables or the array to the next page.
Yep. You can't do it with "VALUES ($_GET['sfname'] etc, etc ". You'll
have to do it with "VALUES (" . $_GET['sfname'] . ", " .
etc . ", " . ")";
> I did a print_r($_GET); for pages 1 and 2, and both showed the array
> for that
> page only. I sort of thought that the command would show the $_GET array
> "growing" with the values from page 1 and page 2.
Think about it -- the $_GET array simply shows the variables that were
sent to that particular script using the GET method. Since HTTP is
stateless, this won't grow over the lifetime of a browser's session --
for that you need to take your GET variables and place them into an
array in a SESSION variable or something. What you have observed is
normal. One other way to make your GET array grow is to grab the
contents of the $_GET array using a foreach () loop or something, and
then place them into a hidden form field. But bear in mind that the GET
method only supports like 255 characters or something like that, so
doing this isn't advisable -- that is, after all, what session variables
were developed for.
> That seems to be where the
> problem lies. Using $sfname = $_GET['sfname']; on page 1 and $rfname =
> $_GET['rfname'] on page 2, I would have assumed that the print_r[$_GET]
> done
> on page 2 would show both sfname AND rfname. But perhaps I am
> mis-understanding the function of print_r[$_GET] -- it's probably
> non-cumulative and specific to the page from which it was called on. If
> that's the case, what precisely is the value of these "superglobals"
> when ,in
> fact, they are specific to ONE page only???
First of all, just so we're clear on this, print_r simply prints out the
raw value of a variable or array or object or whatever. It's something
that you usually only use in development, to echo back to yourself the
contents of a variable so you can make sure that your code is working as
expected (or find out what's wrong if it's not).
SUPERGLOBAL doesn't refer to SUPERSESSION -- it doesn't mean that the
variables become any more persistent than before. The differences are
slight, and the name "SUPER" may have misled you. What is meant by
SUPERGLOBAL is that when you refer to a superglobal using the
superglobal syntax ($_GET, $_SERVER, etc), it is automatically
globalized. What value is this? Well, for one thing you don't have to
declare these as global with the "global" keyword in a function.
Normally, this won't work:
$name = "Andre Dubuc";
function printname()
{
print $name;
}
...because $name is defined outside the scope of the function. The name
needs to be passed to the function as an argument, or by using the
global keyword...
// as an argument:
$name = "Andre Dubuc";
function printname($name)
{
print $name;
}
// using global keyword
$name = "Andre Dubuc";
function printname()
{
global $name;
print $name;
}
These will both result in "Andre Dubuc" being printed to the screen.
But here is a superglobal being used:
// $_GET['name'] has been passed to the script,
// and its value is "Andre Dubuc"
function printname()
{
print $_GET['name'];
}
This will in fact print the name as expected, even though the name
hasn't been passed as an argument or globalized by the global keyword.
Why is this useful? Well, I have a feeling that the PHP developers
anticipated some unfavorable reaction to deprecating "register_globals =
on". So, instead of requiring everyone to use $HTTP_*_VARS all the time
(which is between 14 and 20 extra characters depending on what array
we're talking about), they came up with the much shorter $_* variable
names. Easier to use. And, since the PHP coder in question is
referring to these variables in a much more specific fashion (by using
$_GET to refer to GET variables or $_SESSION to session variables), they
are less likely to inadvertently globalize some malicious input from a
user -- so why not provide the convenience of making the variables
global?
> "With superglobals, you need to actually break out of the string by
> using the
> dot to append variable names." How I wish I knew that before: I don't
> recall
> running into that statement anywhere in the docs.
It's just like the + operator in JavaScript (well, actually in JS the +
operator also performs addition). You'll find the dot extremely
useful -- I'm sure you already know this one:
$name = "Andre ";
$name .= " Dubuc";
print $name; // prints "Andre Dubuc"
> I think I'll get used to dot notation [I used it a lot in Paradox PAL]
> and re-do my scripts properly. I'll get back to you on how it goes.
>
> Thank-you very much, Eric -- your advice and your excellent help is
> really
> what OpenSource is all about.
Hey no problem. I just got started with JavaScript and I've been asking
a million questions on another mailing list about that, so what comes
around goes around. Also, if you ever were to check the archives you'd
see that I've posted a few hundred questions here on php-general, many
of them the same ones that I'm answering today.
Erik
----
Erik Price
Web Developer Temp
Media Lab, H.H. Brown
[EMAIL PROTECTED]
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
