SitePoint Sponsor

User Tag List

Page 1 of 3 123 LastLast
Results 1 to 25 of 54
  1. #1
    SitePoint Enthusiast
    Join Date
    Dec 2001
    Location
    Oregon, USA
    Posts
    88
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    OOP abstraction layer

    I wrote a decent OO abstraction layer, and it worked fine, until the problem of functions came in. As long as I was using the same object, everything worked fine, but each time I create a new object, it creates a new connection. When I write functions, it won't let me use any objects out of its scope, so I have to create a new DB object. If I have a function that is repeated several times throughout a script, I'm connecting to the same database 3 or 4 times!

    There has to be a more efficient way of doing this... I suppose I could integrate the function into the class, but I'd really like to keep the db class as a seperate abstraction layer.

  2. #2
    SitePoint Guru
    Join Date
    Jan 2001
    Location
    Alkmaar, Netherlands
    Posts
    710
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is a pattern called singleton pattern. I think this is what you need. First seperate your database connection (as seperate class probably) then check if there is such a class in use(singleton pattern) if in use use it as connection, otherwise create it.
    Check static keyword in PHP.
    I never implemented this pattern but I will check out when I find time.

  3. #3
    SitePoint Enthusiast fluke's Avatar
    Join Date
    Mar 2002
    Location
    Ireland
    Posts
    51
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You could always pass the db connection into the constructor of the new object. I use this in the app im writing at the moment, i.e.

    PHP Code:

        $oAddNews 
    = new cAddNews($ptrDB);

        class 
    cAddNews
        
    {

            
    // Local DB Connection
            
    var $oDB;
            var 
    $bPageValid;

            function 
    cAddNews($ptrDB)
            {
                
    // Pass in a DB Connection
                
    $this -> oDB = &$ptrDB;
            } 
    It does get a bit mad when you have loads of objects as your always passing a connection about, and you must make sure that none of your 'sub' objects closes the DB connection on you

    fluke

  4. #4
    purple monkey dishwasher scoates's Avatar
    Join Date
    Nov 2001
    Location
    Montreal
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    as much as you global whiners ( (-: it's a joke ) don't think they should be used, what I do for my DB connection is this:

    every template in my application calls init.inc.php which defines $DB as a new database connection object.

    to query, I do $someQ = $DB->query($sql) which creates a new Query object.

    Any time I need to use the database connection (that was made in init), I just global $DB, and use local instances of Query.

    S

  5. #5
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That's exactly what I do too, use a *global* $db variable.

    I know that there are people out there who say that globals are evil, in any programming language, but I don't see the evil in the use of a global database access object.

    I think that if a class is only instanciated once throughout a script, it's legal to make this a global object. It is also possible to pass this object to every function or class constructor, but I don't see the use of this when you can just access the global object.

    Just for your information, the only global variables I use in my scripts are:

    - $cnf (configuration object, holds all paths, urls, db settings, etc)
    - $db (database access object)
    - $p (page object, with properties such as title, responsible for handling template output)
    - $u (user object)

    I believe that all of these objects can be seen as 'layers' or 'tiers' (?): a database abstraction layer, user interface, authorization layer and configuration. Because PHP doesn't have namespaces like for example C++ has, I think it's legal to make these global objects. I do agree that using global variables which are not objects is a bad practice.


    Please let me know your opinion on this use of global variables, all of which are objects by the way.

  6. #6
    SitePoint Columnist Skunk's Avatar
    Join Date
    Jan 2001
    Location
    Lawrence, Kansas
    Posts
    2,066
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    That sounds perfectly fair to me - as long as the code you are writing is always used in the same overall framework (where the $db, $cnf, $p and $u objects are all available) you shouldn't get any problems. The only downside is it makes your code less portable - if you ever try to reuse a function from your exising code in some other application where those objects don't exist you will run in to problems. Provided you are not writing your code for re-use outisde of the current framework that issue will never come up and you'll be fine.

    Language purists might disagree but I see that as a perfectly valid use for globals - in fact I do pretty much the same thing myself.

  7. #7
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's me again, that guy that never stops whining about global variables... :-)

    I believe that all of these objects can be seen as 'layers' or 'tiers' (?): a database abstraction layer, user interface, authorization layer and configuration.
    It's exactly the opposite: when using global variables, you LOSE the layers. When you think you have a system of, say, 6 layers, and you put the database object $DB in the first and use it in the sixth (as 'global $DB', that sixth layer becomes, by definition, the second layer: in an n-layered system, layer n directly depends on layer n-1, but not on any layer lower than n-1. That's the whole point of layering. When your sixth layer becomes in effect the second layer, the third, fourth and fifth layers no longer exist. And gone is your layered code. Thank you global variables!

    On the other hand: how many layers does a typical PHP application have? That depends on how you code it, of course, but most of the code I get to see (in forums and such) has at most two. In that case you can argue that using global variables isn't that bad, because there are no layers to mess up anyway... My answer to that: if an application use only 2 layers, it has a bad design.

    Let's examine the typical PHP code for printing a list of articles (or books, or whatever):

    PHP Code:
    function printList($category_id)
    {
        global 
    $DB;
        
    $DB->query("select id, name from article where category = $category_id");
        while (
    $row $DB->fetchRow())
        {
            print 
    "<a href=\"article.php?id=${row['id']}\">${row['name']}</a><br>\n";
        }  

    Code like this is very common. Although a very short function, it does many things:
    - It executes an SQL query
    - It traverses all rows in a query result
    - It prints each row in some way

    When you think about this for a while, you'll see that there are forced dependencies in this code that needn't be there. You can see these dependencies by looking at the code in 'reverse order':
    - Information on a single article is printed. Where does this information come from? It currently comes from a set of rows, and there's no way to change that.
    - A set of rows is traversed. Where do these rows come from? They currently come from an executed query, and so it will be forever.
    - A query is executed on a database connection. Where does that connection come from? It is currently imported in the function by using 'global', making this function directly dependent on the layer the database object was declared in.

    I'm not saying this is all wrong, or that it should be any different. For the sake of the argument, I'm only using a very simple example. Anyway, it's clear that this code, although doing much, has only one layer. And that has its consequences. What if the articles should be printed differently, or the query must be changed, or a different database connection should be used, or a whole different datasource (a flat file)? The only way to change those things now is by updating ALL of the code. Because it's all in the same layer. (Note again: it's a very simple example, hopefully you get the idea.)

    Another way of implementing the above example is like this:

    PHP Code:
    function selectList(&$database$category_id)
    {
        return 
    $database->execute("select id, name from article where category = $category_id");
    }

    function 
    printList(&$it)
    {
        for (
    $it->reset(); $it->isValid(); $it->next())
        {
            
    $row = &$it->getCurrent();
            print 
    "<a href=\"article.php?id=${row['id']}\">${row['name']}</a><br>\n";
        }
    }

    $result selectList($database12);
    $iterator = new QueryIterator($result);
    printList($iterator);

    // Or, more compact:
    printList(new QueryIterator(selectList($database12))); 
    An explanation is in order: the method 'execute' of class Database returns an object of class QueryResult, which can be used to access rows in the result. These methods are not part of the Database class (like before in '$DB->fetchRow()), because I want to be able to run another query while I'm still processing the first. By separating the database connection from the query result this is suddenly possible (and the code gets simpler as well). To process the rows I could either access each row through the interface of class QueryResult (e.g. '$row = $result->getRow(3)'), but in this case I wrap it up in an 'iterator', which is passed along to the function 'printList'. I also have iterators for built-in arrays and strings, lines in files, nodes in XML trees... All iterators have the same interface, so function 'printList' has become a generic function (it works on any datastructure I have an iterator for) instead of a specialized one.

    Looking at the functions calls in the pipeline, you'll see that they are printed in the same order as the dependencies (or: reversed from what they were at first): show results -> get list -> select data. That's not just a coincidence!

    Even though this is a very simple example, hopefully you'll notice the following:
    - Function 'selectList' knows about the database connection.
    - The QueryIterator knows nothing about the database connection, only about the result from some query.
    - Function 'printList' knows nothing about the database connection or the fact that the data it processes comes from an executed query.

    If I have code like this, and I use a global variable in function 'printList', the nice layering I got is immediately destroyed. And that's definitely not what I aimed for when I designed and coded it this way! Maybe in this particular case it's not much of a problem. But in a larger application, with many layers, it certainly is.

    There are many other remarks I could make about this example (why this is so much better ;-)), but this is not the place (nor the time; it's getting late here). The subject was 'global variables'. Once again. <<Sigh>> I'll say it one more time, and I will probably have to repeat this 'til my dying day: "global variables are evil!"

    Vincent

  8. #8
    purple monkey dishwasher scoates's Avatar
    Join Date
    Nov 2001
    Location
    Montreal
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    PHP Code:
    function get_some_db_info(&$DB) {
        
    $result $DB->query("select * from some_table");
        return 
    $result->to_array();

    is no different than:
    PHP Code:
    function get_some_db_info() {
        global 
    $DB;
        
    $result $DB->query("select * from some_table");
        return 
    $result->to_array();

    when it comes right down to it. The first is not dependent on a variable in the parent scope actually named "$DB", but it's still expecting a DB object with a query() method.

    The second just keeps you from needlessly passing a $DB variable in the function call.

    In my opinion, they're both "correct," but the second is much more readable because your code doesn't have to pass $DB to every function it calls.

    This is talking about a semi-layered/semi-tiered system (2 layers).

    I see your point, but $DB is much more than just data you're passing to the function. It's a UNIQUE object. I _never_ have more than one DB connection in my framework, and if I ever need a second, I'll probably just globalize a $DB2 object.

    S

  9. #9
    SitePoint Columnist Skunk's Avatar
    Join Date
    Jan 2001
    Location
    Lawrence, Kansas
    Posts
    2,066
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    voostind that post was fantastic - you've helped me start thinking about the layer idea in a whole new way (and the iterator stuff was very handy, I've been trying to think of ways of handling "collections" of results from a database for ages, and your QueryIterator has provided just the inspiration I needed). I've disagreed with you once or twice before on this forum but I've finally understood where you are coming from. Thank you.

  10. #10
    Making a better wheel silver trophy DR_LaRRY_PEpPeR's Avatar
    Join Date
    Jul 2001
    Location
    Missouri
    Posts
    3,428
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by scoates
    when it comes right down to it. The first is not dependent on a variable in the parent scope actually named "$DB", but it's still expecting a DB object with a query() method.
    exactly.

    i kinda think about this global variable stuff like PHP's built-in variables. before PHP 4.1.0, the $HTTP_*_VARS arrays weren't global. if you wanted to access them in function, you had to use `global $HTTP_*_VARS'. was that bad? i think it was inconvenient, but not bad. what were you supposed to do, pass the array as a parameter to the function?

    now the $_* arrays are super globals and available in functions automatically. by being that way, you are depending on the variable(s) to be named $_*. in any script there are variables that already exist; that you depend on. you can't just call every variable whatever you want.

    in your case (and i'd do it too in a script whose code won't be reused), you are simply doing the same thing with $DB. since it's always the same, i think it's fine.

    also, constants are globally available. is that bad? you're relying on them having a certain name.

    i probably didn't say this very well, but hopefully you get the idea.
    - Matt ** Ignore old signature for now... **
    Dr.BB - Highly optimized to be 2-3x faster than the "Big 3."
    "Do not enclose numeric values in quotes -- that is very non-standard and will only work on MySQL." - MattR

  11. #11
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    'function get_some_db_info(&$DB)' ... is no different than: 'function get_some_db_info()' ...
    On the contrary, these functions are very different. What you are referring to as 'being the same' is not the function, but only the function body. And a function body is only a small part of a function. Equally important is the function interface: a clear name (saying WHAT it does), some arguments (showing HOW it's done), and the (optional) type of the result. You didn't name the function 'get_some_db_info' as 'gsdi'. Why not? Because it wouldn't be clear what the function did. The same argument goes for the function parameters.

    Given only the interfaces of all functions (or the classes and their methods) in the system, you should be able to draw a graph of all dependencies. This graph can be drawn in such a way that all layers in the system become visible. There should be no need to look at the function bodies, as these are only 'implementation details'. In other words: not interesting.

    Maybe both functions you showed have more or less the same function body, but when using global variables, it's not the function that uses them you should look at. You should examine the code that calls those functions. For example, when you don't use global variables, you'll have to do this:

    PHP Code:
    function layer2(&$db)
    {
        return 
    layer3($db);
    }

    function 
    layer3(&$db)
    {
        return 
    layer4($db);
    }

    function 
    layer4(&$db)
    {
        return 
    $DB->query("select * from some_table");
    }

    $db = new Database;
    $result layer2($db); 
    Now, that code certainly doesn't look nice. But that has nothing to do with the fact that no global variables are used. With global variables, the numerous $db objects won't be passed any longer, but that doesn't change the design, which is wrong. The fourth 'layer' (which is actually the second) shouldn't be handling the query to the database at all.

    Knowing nothing about your code: when you say you have to pass $DB a lot of times and therefore make it global, that tells me that your design is wrong. I never use global variables, and I also don't have to pass my database object numerous times: only to the layer that uses it.

    ... when it comes right down to it. The first is not dependent on a variable in the parent scope actually named "$DB", but it's still expecting a DB object with a query() method.
    In this case, you're right, but that's only because this is a simple example. Say you're working on a layer that knows nothing about the database (layer 4 or something). As soon as you need to place a call to the global variable-version 'get_some_db_info', you'll be instantly using the $DB object. What's worse: you won't even know it! At once, layer 4 becomes layer 2. If you want to use the version where a reference to the database object is passed, you have a problem: the fourth layer knows nothing about the database, so there's nothing to pass on. That makes it immediately clear the code was designed the wrong way somewhere along the way.

    One solution to the problem is by making some object 'special', 'unique' or 'global'. But that messes up the layering, so that's not a real solution. A second solution is to redesign the existing code. Although this is the best solution by far, programmers almost never do this, because it's too much work. And that's just too bad, because if they would, they'd become much better at their job.

    I see your point, but $DB is much more than just data you're passing to the function. It's a UNIQUE object.
    There's the problem. Why is $DB unique? Because you made it so, not because it actually is. Whenever there is a 'special case' in software you're writing, you have a problem. NO part of the code need (or should) be special at all. It points to a bad design.

    now the $_* arrays are super globals and available in functions automatically. by being that way, you are depending on the variable(s) to be named $_*. in any script there are variables that already exist; that you depend on. you can't just call every variable whatever you want.
    About those superglobals: using them all over your code is a bad idea; it's much better to only read their values in the parts of the code that was responsible for creating those variables in the first place. Also, you should only read the contents of those variables, and not set them. That makes them, in effect, constants.

    Also, constants are globally available. is that bad? you're relying on them having a certain name.
    A constant is not at all like a variable. A constant can be set only once, and, after being defined, is read-only. That's not at all like a variable. The code that creates a variable should be able to track what happens to that variable. If you make a variable global, that's impossible. For constants it doesn't matter, because there's nothing to track: they never change. Also, constants have limited use in code. They are useful for specifying 'magic numbers', but that's about it.

    Vincent

  12. #12
    SitePoint Guru
    Join Date
    Oct 2001
    Posts
    656
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    voostind, thanks for showing us a good example of how to actually build a nice 'layered' system. I've heard about it tons of times, but nobody has every really showed how to code it.

    Still, I believe that it is a bit of overbloating the code. Say you want to code something that lists news items in a database. Do you really need to have three functions then??: get_news_from_db(), print_db_news(), iterate_db_news()?? Why not just do this in one function?

    And about a global $db object being unique and stuff.. in my application (framework) I can be 100% sure that the DB object is *always* available. It is just bloated to pass this object to every function or class method I call, or to write a special function for everything that accesses this DB layer. It is much easier, and in my opinion it also produces easier to understand code, to write three functions for each function, instead of just one.

  13. #13
    SitePoint Columnist Skunk's Avatar
    Join Date
    Jan 2001
    Location
    Lawrence, Kansas
    Posts
    2,066
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by Captain Proton
    Do you really need to have three functions then??: get_news_from_db(), print_db_news(), iterate_db_news()?? Why not just do this in one function?
    One word - reusability. What happens if a couple of weeks later you decide you want to display just the news headlines in a box on your site somewhere? Or you want to only display news from a certain date? If you wrote three seperate functions you will be able to achieve this with much less code (and should you ever change the way your news is stored in the database you will only have to change the get_news_from_db() function rather than having to change the print_news_list(), print_news_headlines_list() and print_news_for_specific_day() functions).

  14. #14
    SitePoint Evangelist galt's Avatar
    Join Date
    Apr 2002
    Posts
    461
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Okay, here is my two cents (thats all I have).

    0. Good programmers reuse a lot more code than they write new each time.

    1. By using global $DB, you are commiting all of your code to a single database. This is a fundamental design decision that could be very flawed in the future. What happens if later on you need to intergrate some of the code from one app with code from another app to make a third app? Commit to a single database for everything? Sometimes that is a bad idea, especially when talking about external applications. As an example, my phpPP system uses three databases. One holds the VBulletin stuff, one holds the phpPP stuff, and the third holds the use app stuff that is unqiue to each website. This lets me isolate VB upgrades and phpPP upgrades from the ultimate application system. What should I do, have three sets of database functions? Global variable scheme just collapses completely when thinking about robust system design.

    2. I wihs I was more fluent in all of this layering stuff. Right now I take a pragmatic approach, but I am not sure yet if it saves me time or not. First time I need code, I just write in inline. The second time I do something, I decide if it is worth another layer. If so, I go rewrite the first use to share some code. But for most display functions, I don't really see very much in the way of re-use for what I am working on. If someone could suggest a REALLY GOOD book on layering and constructing multi-tier objects, I would be appreciative.

    I have never met a global variable I couldn't do without. Sometimes "no globals" is a nuisance initially, but it always pushes me out the other end with a much better design.

  15. #15
    What? Maelstrom's Avatar
    Join Date
    Oct 2001
    Location
    Whistler BC originally from Guelph Ontario
    Posts
    2,175
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    galt:
    I love how you started with 0...too funny

    As for you last response. I am in the same boat. I want a better understanding of the theoretical side of development. Layering is a little over my head as well as some other advanced development issues. Any tutorials or books would be great...

    BTW I am going to be taking up c++ so I assume there will be books for these topics directly relating to that language. hints?
    Maelstrom Personal - Apparition Visions
    Development - PhP || Mysql || Zend || Devshed
    Unix - FreeBSD || FreeBsdForums || Man Pages
    They made me a sitepoint Mentor - Feel free to PM me or Email me and I will see if I can help.

  16. #16
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    A very good book (at least, that's my opinion) on building object-oriented systems is 'Large Scale C++ Software Design' written by John Lakos and published by Addison Wesley.

    The title sounds a bit scary, and it is true that you have to be a bit more than a beginner in C++ to understand everything. On the other hand, it explains techniques to build layered systems that can be used in any language.

    The book even includes a software package to compute the dependencies between the various 'components' in a C++ program. The resulting dependency graph (the layers in the system) can be compared to many general cases, and give you an idea of how your code could be improved.

    All in all, a very good book. For more information, see http://cseng.aw.com/book/0,3828,0201633620,00.html


    Vincent

  17. #17
    What? Maelstrom's Avatar
    Join Date
    Oct 2001
    Location
    Whistler BC originally from Guelph Ontario
    Posts
    2,175
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanx Voostind. I will of course have to get a beginners book first. But that looks like a great second addition
    Maelstrom Personal - Apparition Visions
    Development - PhP || Mysql || Zend || Devshed
    Unix - FreeBSD || FreeBsdForums || Man Pages
    They made me a sitepoint Mentor - Feel free to PM me or Email me and I will see if I can help.

  18. #18
    Super Ninja Monkey Travis's Avatar
    Join Date
    Dec 2001
    Location
    Sioux City, Iowa
    Posts
    691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by galt
    I have never met a global variable I couldn't do without. Sometimes "no globals" is a nuisance initially, but it always pushes me out the other end with a much better design.
    does that include the super globals $_post and $_server?
    Travis Watkins - Hyperactive Coder
    My Blog: Realist Anew
    Projects: Alacarte - Gnome Menu Editor

  19. #19
    SitePoint Evangelist galt's Avatar
    Join Date
    Apr 2002
    Posts
    461
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    See, there you go. I thought the discussion was about introducing global variables into an application design, not using them to communicate with the operating system. My mistake.

  20. #20
    Super Ninja Monkey Travis's Avatar
    Join Date
    Dec 2001
    Location
    Sioux City, Iowa
    Posts
    691
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    so you do use the super globals then?
    Travis Watkins - Hyperactive Coder
    My Blog: Realist Anew
    Projects: Alacarte - Gnome Menu Editor

  21. #21
    What? Maelstrom's Avatar
    Join Date
    Oct 2001
    Location
    Whistler BC originally from Guelph Ontario
    Posts
    2,175
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by galt
    See, there you go. I thought the discussion was about introducing global variables into an application design, not using them to communicate with the operating system. My mistake.
    I am curious too...simply because I will not use regular globals but I do use superglobals...
    Maelstrom Personal - Apparition Visions
    Development - PhP || Mysql || Zend || Devshed
    Unix - FreeBSD || FreeBsdForums || Man Pages
    They made me a sitepoint Mentor - Feel free to PM me or Email me and I will see if I can help.

  22. #22
    SitePoint Evangelist galt's Avatar
    Join Date
    Apr 2002
    Posts
    461
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Actually, I use hyper-globals, but only when visiting subspace.

  23. #23
    purple monkey dishwasher scoates's Avatar
    Join Date
    Nov 2001
    Location
    Montreal
    Posts
    794
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    don't forget about the überglobals.

    (-:

    S

  24. #24
    What? Maelstrom's Avatar
    Join Date
    Oct 2001
    Location
    Whistler BC originally from Guelph Ontario
    Posts
    2,175
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Originally posted by galt
    Actually, I use hyper-globals, but only when visiting subspace.
    Thats all fine and good, and i do love humour. But it really doesn't answer the question which we are really curious about.

    Fine you don't use globals, neither do I. But I do access variables via the super globals. Do you as well?...
    Maelstrom Personal - Apparition Visions
    Development - PhP || Mysql || Zend || Devshed
    Unix - FreeBSD || FreeBsdForums || Man Pages
    They made me a sitepoint Mentor - Feel free to PM me or Email me and I will see if I can help.

  25. #25
    SitePoint Evangelist
    Join Date
    Oct 2001
    Posts
    592
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    There is no way to not use those superglobals, because there's no other way to
    process a GET or a POST...

    However, I personally use the following 'rules' when I use the superglobals:
    - I treat them as read-only. That doesn't quite make them constants, but they're not plain
    variables either. (And of course, this doesn't work for $_SESSION; this one has to
    be set, or else it won't do any good.)
    - The code that reads/writes the superglobals is concentrated in one place. There is only
    one object that processes the results of a form being posted. When some other part of the
    application needs those same results, it must request them from previously mentioned
    object, which it can only do if that object is in scope.

    Using these two simple rules, accessing those superglobals is perfectly possible, without
    messing up the code.

    Vincent


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •