PHP forum software that isn't an utter disgrace?

[kyberfabrikken]

I don't think the use of globals in PHP is not always a bad thing. There are instances where it just makes sense. For example the database class in most PHP software is used almost globally in everything.

Well ... you probably picked the worst possible example. A lot of applications have a global named $db. What happens when you want to run two of them together ?

[DougBTX]

What happens when you want to run two of them together ?

They'll be using the same DB anyway, just watch your table names

[Silverhawk]

Unless your going to go commercial with your code I see no reason as to why you can't code how you want, uncommented, sloppy, badly formatted, whatever. It usually won't be a problem if its only you looking at it. I can write a several thousand line piece of software without any documentation and still understand the whole thing (since it was a result of my thinking).

Now if your going commercial, I can see why you may want to use better coding habbits.

Never ever assume that you will be the only person who will be reading your own code. Even if the code is in-house, there may be other developers who will be looking at your code in the future.

Even if you are coding for your own personal use alone, you should add some comments or structure your code nicely. It is good practice so get into the habit of doing it. Many years down the road you might need to look at your code again and comments will help you understand what you were doing back then.

Still - I don't ever write code which access said superglobals directly at the application-level. Instead I wrap it in a request-object. Most serious PHP projects does something similar.

This interests me, mind sharing how exactly this is done?

There are tons of ways to get around arduously passing the database connection instance to the constructor.

Mind sharing such methods?

[Serberus]

A registry, service locator or using dependency injection.

[tetsuo shima]

A global db object is one of the common mistake I see people do. I have bookmarked this thread for when I met someone who thinks it's a good idea.

[kyberfabrikken]

They'll be using the same DB anyway, just watch your table names

Will they be using the same driver too ? What if they don't ?

[kyberfabrikken]

Still - I don't ever write code which access said superglobals directly at the application-level. Instead I wrap it in a request-object. Most serious PHP projects does something similar.

This interests me, mind sharing how exactly this is done?

Well - nothing magic really.

class Http_Request implements ArrayAccess
{
    public $GET;
    public $POST;
    public $FILES;
    public $HEADERS;
    public $ENV;
    public $INPUT;

    protected $REQUEST;

    function __construct() {
        $this->GET = isset($_GET) ? $_GET : Array();
        $this->POST = isset($_POST) ? $_POST : Array();
        $this->COOKIES = isset($_COOKIES) ? $_COOKIES : Array();
        $this->FILES = isset($_FILES) ? $_FILES : Array();
        $this->HEADERS = apache_request_headers();
        $this->ENV = $_SERVER;
        $this->INPUT = file_get_contents('php://input');
        $this->REQUEST = ($this->ENV['REQUEST_METHOD'] == "POST") ? $this->POST : $this->GET;
        $this->decodeInput();
    }

    function offsetExists($offset) {
        return isset($this->REQUEST[$offset]);
    }

    function offsetGet($offset) {
        return $this->REQUEST[$offset];
    }

    function offsetSet($offset, $value) {
        throw new Exception("Not implemented");
    }

    function offsetUnset($offset) {
        throw new Exception("Not implemented");
    }

    protected function decodeInput() {
        if (get_magic_quotes_gpc()) {
            foreach (Array('GET','POST','COOKIES') as $property) {
                recursive_array_map('stripslashes', $this->$property);
            }
        }
    }
}
function recursive_array_map($callback, &$var) {
    if (is_array($var)) {
        foreach (array_keys($var) as $key) {
            recursive_array_map($callback, $var[$key]);
        }
    } else {
        $var = call_user_func_array($callback, Array($var));
    }
} 

[33degrees]

Interesting, php://input gives you the form data, correct?

[kyberfabrikken]

Interesting, php://input gives you the form data, correct?

It's the raw request body (equal to the deprecated $HTTP_RAW_POST_DATA).

[dreamscape]

class Http_Request implements ArrayAccess 
{ 

    function __construct() { 
        $this->GET = isset($_GET) ? $_GET : Array(); 
        $this->POST = isset($_POST) ? $_POST : Array(); 
        $this->COOKIES = isset($_COOKIES) ? $_COOKIES : Array(); 
        $this->FILES = isset($_FILES) ? $_FILES : Array();
        /** snip **/
    }
} 

This part doesn't make a whole lot of sense to me. Most of the superglobals are always set. GET, POST, and FILES are always at least a blank array; even in the CLI they are set. The only one that might not be set is COOKIES, which is only set if the client sends cookies in the request header.

You may be banking on the possibility that this will change in the future, but there's no real evidence of that so you're left with a pre-mature safe guard based on pure speculation. You might as well have just coded it as "true ? $_GET : Array();"

But then again, you do "$this->ENV = $_SERVER;" since $_SERVER is always set, so maybe you're just not aware that GET, POST, and FILES are always set (it's not intuitive since you'd think POST would only be set if the request is a POST).

[Serberus]

This part doesn't make a whole lot of sense to me. Most of the superglobals are always set. GET, POST, and FILES are always at least a blank array; even in the CLI they are set.

Unless this class was for use with versions of PHP < 4.1.0 (very old)? Then again you might expect $HTTP_*_VARS in the else clause.

[dreamscape]

Unless this class was for use with versions of PHP < 4.1.0 (very old)?

I doubt it seeing as it implements the SPL ArrayAccess interface.

[m1k333]

phpbb is the best!

[scarfhogg]

I doubt it seeing as it implements the SPL ArrayAccess interface.

And uses __construct() ...

[Serberus]

Good points

[33degrees]

They'll be using the same DB anyway, just watch your table names

Actually, I just ran into an issue today, where there was data we needed in a different database than the application's main one, but all the db calls shared a singleton db object. A possible moral to this story could be; never assume you will only every need one instance of an object.

[nacho]

A possible moral to this story could be; never assume you will only every need one instance of an object.

Well, I disagree here. I think you should take into account the nature of the object in order to determine if there could be a need for a second instance. In the case of database connections, it seems obvious to me that while in an early stage almost every web application would likely use just one connection, as soon as you realise there is a probability of the application to grow, the chance you would use a second connection is quite real and therefore using a factory would offer the flexibility you'd need.
However, take an application controller, or an error handler, for example. How many instances would you think you need, despite of the application getting larger? I can only see the need for one of them.

[Silverhawk]

A registry, service locator or using dependency injection.

Thanks, more stuff for me to read to build better PHP applications ^_^

Well - nothing magic really.

class Http_Request implements ArrayAccess
{
    public $GET;
    public $POST;
    public $FILES;
    public $HEADERS;
    public $ENV;
    public $INPUT;

    protected $REQUEST;

    function __construct() {
        $this->GET = isset($_GET) ? $_GET : Array();
        $this->POST = isset($_POST) ? $_POST : Array();
        $this->COOKIES = isset($_COOKIES) ? $_COOKIES : Array();
        $this->FILES = isset($_FILES) ? $_FILES : Array();
        $this->HEADERS = apache_request_headers();
        $this->ENV = $_SERVER;
        $this->INPUT = file_get_contents('php://input');
        $this->REQUEST = ($this->ENV['REQUEST_METHOD'] == "POST") ? $this->POST : $this->GET;
        $this->decodeInput();
    }

    function offsetExists($offset) {
        return isset($this->REQUEST[$offset]);
    }

    function offsetGet($offset) {
        return $this->REQUEST[$offset];
    }

    function offsetSet($offset, $value) {
        throw new Exception("Not implemented");
    }

    function offsetUnset($offset) {
        throw new Exception("Not implemented");
    }

    protected function decodeInput() {
        if (get_magic_quotes_gpc()) {
            foreach (Array('GET','POST','COOKIES') as $property) {
                recursive_array_map('stripslashes', $this->$property);
            }
        }
    }
}
function recursive_array_map($callback, &$var) {
    if (is_array($var)) {
        foreach (array_keys($var) as $key) {
            recursive_array_map($callback, $var[$key]);
        }
    } else {
        $var = call_user_func_array($callback, Array($var));
    }
} 

This is for PHP5 right? Could i do something similar using PHP4? I'm not very famiilar with PHP4's OOP capabilities. Took a long break from doing PHP and concentrated on C++, C# and JAVA in college. Used to hate the idea of classes but now i'm seeing its advantages.

PHP4 support is important to me, because most servers still don't provide PHP5... so i can't build a solution which the client's server might not support.

[Ren]

However, take an application controller, or an error handler, for example. How many instances would you think you need, despite of the application getting larger? I can only see the need for one of them.

I have two error handlers. One for development, another for live.

[NetNerd85]

Agreed that a lot of applications out now are very dated and can be poorly written. OsCommerce is a perfect example of what not to do now days.

I do agree that the lack of professional and up-to-date resources is damaging to those that don't actively seek out "the best way" / just don't know any better.

[nacho]

I have two error handlers. One for development, another for live.

Mmmm, I have to say I didn't expect that one coming from you
So you mean you have two instances of your error handler running at the same time ... for development and production?

[kyberfabrikken]

This part doesn't make a whole lot of sense to me. Most of the superglobals are always set. GET, POST, and FILES are always at least a blank array

You're right. Dunno why I had thoose safeguards.

This is for PHP5 right? Could i do something similar using PHP4? I'm not very famiilar with PHP4's OOP capabilities.

Yes and yes. Although PHP4 is really quirky when it comes to objects.

This should work in php4

class Http_Request
{ 
    var $GET; 
    var $POST; 
    var $FILES; 
    var $HEADERS; 
    var $ENV; 
    var $INPUT; 

    function Http_Request() { 
        $this->GET = $_GET; 
        $this->POST = $_POST; 
        $this->COOKIES = isset($_COOKIES) ? $_COOKIES : Array(); 
        $this->FILES = $_FILES; 
        $this->HEADERS = apache_request_headers(); 
        $this->ENV = $_SERVER; 
        $this->INPUT = file_get_contents('php://input'); 
        $this->_decodeInput(); 
    } 

    function _decodeInput() { 
        if (get_magic_quotes_gpc()) { 
            foreach (Array('GET','POST','COOKIES') as $property) { 
                recursive_array_map('stripslashes', $this->$property); 
            } 
        } 
    } 
} 
function recursive_array_map($callback, &$var) { 
    if (is_array($var)) { 
        foreach (array_keys($var) as $key) { 
            recursive_array_map($callback, $var[$key]); 
        } 
    } else { 
        $var = call_user_func_array($callback, Array($var)); 
    } 
} 

[Edman]

What on earth is the advantage of doing something like that? What would be the difference of simply running the 2 functions needed upon initialisation and write to the respective variables, and then instead of typing $Http_Request->offsetGet('offset') all over just do $_GET['offset']?

I personally think this class totally overcomplicates something extremely simple.

[kyberfabrikken]

What on earth is the advantage of doing something like that? What would be the difference of simply running the 2 functions needed upon initialisation and write to the respective variables, and then instead of typing $Http_Request->offsetGet('offset') all over just do $_GET['offset']?

I personally think this class totally overcomplicates something extremely simple.

Actually that would be $http->GET['offset'] or simply $http['offset'] because of SPL's ArrayAccess interface. The reason - as already discussed - is to put the variables in a scope.

[agoossens]

What on earth is the advantage of doing something like that? What would be the difference of simply running the 2 functions needed upon initialisation and write to the respective variables, and then instead of typing $Http_Request->offsetGet('offset') all over just do $_GET['offset']?

The superglobals are just as evil as standard global variables, they just sound cooler. Hence they suffer from all the same problems, namely coupling with god knows how many points around the application.

I must admit, I do agree with you - it does seem to overcomplicate things. For me personally it's a matter of consistency and since I always try to push data, never pull it, why should I break that consistency just to pull in from the superglobals and save myself a little time? If nothing else it makes testing so much easier (if I ever write tests, but let's not go there).