global variables

[Sandman]

I dont think I understand them. I've read the section on scope in the
manual inside out.

I'm running PHP 5.2.0 Here is the code I'm working on:
//include_me.php
<?php
$MYVAR = array();
global $MYVAR, $a;
?>

//array1.php
<?php
require("include_me.php");

global $MYVAR, $a;

$sname = 'user';
$email = 'u***@yahoo.com';
$GLOBALS['a'] = 'here';

$MYVAR['sname'] = $sname;
$MYVAR['email'] = $email;
$MYVAR['age'] = 34;

print "SNAME: {$MYVAR['sname']} <br>";
print "EMAIL: {$MYVAR['email']} <br>";
print "AGE: {$MYVAR['age']} <br>";
print "A: $a <br>";

print '<a href="./array2.php">Next</a>';

?>

//array2.php
<?php
require("include_me.php");

global $MYVAR, $a;

$sname = $MYVAR['sname'];
$email = $MYVAR['email'];

print "SNAME: $sname <br>";
print "EMAIL: {$MYVAR['email']} <br>";
print "AGE: {$MYVAR['age']} <br>";
print "A: $a <br>";

?>

When I load array1.php, I see:
SNAME: user
EMAIL: us**@yahoo.com
AGE: 34
A: here
Next

Click on Next, and I see:
SNAME:
EMAIL:
AGE:
A:

Can I preserve the changes across page loads with globals?

Thanks,
EL

[Janwillem Borleffs]

Sandman wrote:

Can I preserve the changes across page loads with globals?

No. The global keyword is used to import variables into a function's
namespace:

$a = 1;

function foo() {
global $a;
print $a;
}

foo();

What you are looking for are sessions or cookies:

http://www.php.net/session
http://www.php.net/manual/en/function.setcookie.php
JW

[=?ISO-8859-1?Q?Oliver_Gr=E4tz?=]

Sandman schrieb:

I dont think I understand them. I've read the section on scope in the
manual inside out.

Global variables are pretty much the variables you shouldn't use at all
if you plan on writing PHP applications that are stored in more than
like three files. Global variables make all kinds of problems:
- They are shared across all files of your program. If you decide to
reuse parts of your program in another project you have to make a list
of all global variables so you dont' run into collisions with the
variables of your new project.

- If you use external packages then you don't know which global
variables this package might use. Common variables like $name are easily
overwritten and hell breaks loose. This problem is known as "pollution
of the global namespace".

- Depending on the server config (register_globals) the visitor can send
you global variables. This makes them insecure because you can't trust
the contents of global variables. An important rule in web programming
is NEVER TRUST USER INPUT so this means SANITIZE ALL GLOBAL VARIABLES
before using them. Or... don't use them.

- Global variables in PHP are not as global as they are in other
languages where you can sometimes always see the global variables. Some
languages even have the keyword "local" to prohibit a variable from
becoming global. PHP instead has the "global" keyword to define a
variable as global. But better forget this keyword for larger projects!
The best alternative to global variables are static class variables:

class MyVars
{
static $var1='value1';
}
MyVars::$var1 = 'huba';

Side note: And using a rare (best: unique) prefix for all classnames
ensures that you can share the code with other projects without
problems. Prefixes are PHPs poor excuse for namespaces until they
hopefully become available at some point. Those ugly reverse domain
based namespaces in Java have a purpose: They ensure uniqueness.

Can I preserve the changes across page loads with globals?

Nope. Basic rule: PHP is stateless. You lose everything after the
request is served. Every PHP script on a webserver is started after a
request is made. The script can receive input in the form of four
different concepts:
G - GET data, this is the URL, variables are transferred in the
?var=value&var2=value2. This data has "view persistence", it is tied to
the browser window. Hit F5 and the same data is submitted again. All is
stored in the URL. You can even bookmark the data. GET data is limited
in its length, it may not exceed a few kilobytes, depending on browser
limits.

P - POST data, this is normally generated when you submit a form. The
variables are transferred in a similar format to GET, but this time in
the body of the request and not in the URL. This data has "limited view
persistence". The browser may ask you if you want to resubmit the form
data if you hit F5 but normally the data is lost once the form has been
processed. POST data may be huge, in case of file uploads it can be
several megabytes big.

C - COOKIE data, this is stored in the visitor's browser if the browser
accepts cookies. Cookies data has "session persistence" or even
"multi-visit persistence", depending on the settings in the visitor's
browser and the expiration time you set for the cookie. This data is
shared across all windows or tabs a visitor opens when browsing your
site because it is bound to the domain. DO NOT RELY ON COOKIES because
visitors may choose not to accept any cookies.

S - SESSION data, this is stored on your server, by default in a simple
file in a temp directory. From the persistence point of view it is much
like cookie data, but you can't normally define how long the data will
survive. Don't expect the session data to last longer than, well a
visitor's session when browsing your site. The problem with sessions is
that you have to know which session data belongs to which visitor
because they are not implictly connected. This connection is established
with the session ID. This is a variable that has to be transfered from
request to request via the G, P or C method. The PHP session functions
are good at automatically transferring the session ID from request to
request.
This GPCS scheme is accompanied by E, the environment information about
the server on which your PHP is running. The combination EGPCS is the
default value for the configuration directive varaibles_order (see
http://de.php.net/manual/en/ini.core...riables-order). This
directive defines a) which of the data sources as input for your script
are used and b) which data comes through if there are variables with the
same name. P comes after G, so a POST variable overwrites the GET
variable of the same name.

REMEMBER: Session data is usually shared among all open windows of a
visitor just like the cookies! To store values of a multipage-form in
the session you cannot simply write the data into the session. What if
the visitor opens the same form twice? You have to work with an array
and a unique form instance identifier as key in the array. Or you use
hidden fields or store the data in the database page by page but that's
another story.

Other ways to store data permanently include all sorts of files and
databases. And if you avoid doing full page request at all by using hip
and cool Ajax technology then you can store data in javascript variables
across "background requests".

[Toby A Inkster]

Oliver Grätz wrote:

- Global variables in PHP are not as global as they are in other
languages where you can sometimes always see the global variables. Some
languages even have the keyword "local" to prohibit a variable from
becoming global. PHP instead has the "global" keyword to define a
variable as global.

In PHP the global keyword basically pulls a variable from the global
namespace into the local namespace.

What most other languages refer to as "globals" PHP calls "superglobals".
There's no way to define superglobals though -- PHP defines a few on its
own (depends on your version, but in recent ones, $_POST, $_GET, $SERVER,
$_SESSIOM, $_ENV, $_FILES and $GLOBALS) and you're stuck with them.

Although I steer away from globals (in my current project, over 4000 lines
of PHP so far, and not a single global!), sometimes I really would
appreciate having a method of defining superglobals. Not going to happen
though. :-(

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~ http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[Sandman]

Awesome discussion and explanation folks.

Yes, I was thinking a global was like a superglobal, but its not.

I ended up imploding my array and sending it to the next page via
POST. Ez-peazy.

Thanks,
EL
On Feb 14, 9:08 am, Toby A Inkster <[e-mail]>
wrote:

Oliver Grätz wrote:

- Global variables in PHP are not as global as they are in other
languages where you can sometimes always see the global variables. Some
languages even have the keyword "local" to prohibit a variable from
becoming global. PHP instead has the "global" keyword to define a
variable as global.

In PHP the global keyword basically pulls a variable from the global
namespace into the local namespace.

What most other languages refer to as "globals" PHP calls "superglobals".
There's no way to define superglobals though -- PHP defines a few on its
own (depends on your version, but in recent ones, $_POST, $_GET, $SERVER,
$_SESSIOM, $_ENV, $_FILES and $GLOBALS) and you're stuck with them.

Although I steer away from globals (in my current project, over 4000 lines
of PHP so far, and not a single global!), sometimes I really would
appreciate having a method of defining superglobals. Not going to happen
though. :-(

--
Toby A Inkster BSc (Hons) ARCS
Contact Me ~http://tobyinkster.co.uk/contact
Geek of ~ HTML/SQL/Perl/PHP/Python*/Apache/Linux

* = I'm getting there!

[=?UTF-8?B?T2xpdmVyIEdyw6R0eg==?=]

Toby A Inkster schrieb:

>
What most other languages refer to as "globals" PHP calls "superglobals".
There's no way to define superglobals though -- PHP defines a few on its
own (depends on your version, but in recent ones, $_POST, $_GET, $SERVER,
$_SESSIOM, $_ENV, $_FILES and $GLOBALS) and you're stuck with them.

Although I steer away from globals (in my current project, over 4000 lines
of PHP so far, and not a single global!), sometimes I really would
appreciate having a method of defining superglobals. Not going to happen
though. :-(

I intentionally left out elaborating about the nature of the globals vs
superglobals because use of global variables is somewaht discouraged.
Even Zend tells developers to use static class variables instead. And by
the way, Defining your own superglobals is NOT impossible. You CAN use
the runkit extension (http://de.php.net/runkit) to define variables as
superglobals. But the nature of this extension as "sandbox" should tell
developers not to do so ;-) But if you find _good_ reasons to use your
own superglobals, you are free to do so.

OLLi