SitePoint Sponsor

User Tag List

Page 2 of 5 FirstFirst 12345 LastLast
Results 26 to 50 of 110
  1. #26
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Dr Livingston
    Someone suggest that you use Intercepting Filters, so the submitted data is validated before it reaches any sort of controller - makes sense, so in saying that maybe you could redirect directly from the Intercepting Filter in question based on the validation?

    So you get to one of two controllers in that event. Another benifit of course would be that the process of form validation is separated from the controller altogether. If for some reason, the means of how you validate your forms changes later, you do not need to refacter any controllers either - you simply swap over to a different Filter.
    Ah yes, the Intercepting Filters. This is probably the approach I see it all taking - but there's one big problem IMHO. And it's the fact that atleast I want to be as far as possible from any config-files at all(Some will be needed, as always.. and i think the parse_ini()-path is one of the best atm. Or simple XML configs), is that how do we set it all up. Do we have some type of CoR? Or a normal stack-like approach? For example:


    Code:
    RequestStack:
        -- HTTPRequest
        -- Intercepting Filter
        -- Controller
    The stack is exectued top-to-bottom(FIFO) and if one fails the next one is not executed, etc. Untill we get some type of response. This "RequestResponse" of some typ is passed to the:

    Code:
    Response Stack:
        -- CommandStack
            -- Login
            -- LoginFailed
            -- LoginSuccess
        -- ModelStack
            -- UserDataModel
        -- ViewStack
            -- Login
            -- LoginFailed
            -- LoginSuccess
    This "stack" after getting a valid response returns a "HTTPResponse" object that is sent to the client. (Maybee stack isn't the best name here but it's late and I need to go to sleep ;p).

    What do you guys think about this approach?

    Edit:
    Quote Originally Posted by BerislavLopac
    Personally, I'd prefer the latter -- a kind of Lego blocks you build your app with.
    Same here, I'd prefer a more loosleycoupled framework.

  2. #27
    SitePoint Enthusiast
    Join Date
    May 2004
    Location
    K.S.A
    Posts
    81
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    One sollution is to use some kind of HEAP table, because you need(imho) fast responsetimes when working with object(application) persistance. But does SQLite support HEAP?
    doesn't the :memory: option in sqlite is the same as Mysql's heap?
    PHP Code:
    $db sqlite_open(':memory:')or
    die(
    'Can not create memory DB'); 
    it's true that the DB only exists while the script is executing.. but just thought I could mention it

  3. #28
    SitePoint Enthusiast
    Join Date
    Nov 2004
    Location
    Canberra, Australia
    Posts
    66
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    2. Dynamic ini file parsing. Many PHP frameworks out there go after Java ones and use XML files for storing config information. While this got much easier with the advent of PHP5, PHP still has much simpler and I guess faster ways to store config data. One is the use of included PHP files, and another the sadly unknown function parse_ini_file() -- it uses a syntax similar to the one in php.ini file, which is much cleaner and simpler than both XML and PHP syntaxes.
    I agree that .ini files can be useful, however the main problem I have with them is that it can be difficult to represent a hierarchy of objects/data within them.

    Quote Originally Posted by BerislavLopac
    3. Arrays. I often see classes which are nothing more than glorified wrappers for PHP arrays. I have yet to see a more powerful handling of arrays than the one in PHP -- just a brief look at http://www.php.net/manual/en/ref.array.php gives an idea of a great number of built-in operations that can be performed on arrays. Just remember how much effort went into the SPL interfaces that give objects the ability to act like arrays!
    True, arrays are powerful but I generally like using a wrapper class because otherwise you have to duplicate a lot of array-specific code everywhere, for example:

    PHP Code:
    function getModule($name=NULL)
    {
       if (isset(
    $this->modules[$name]))
       {
          return 
    $this->modules[$name];
       }

    vs

    PHP Code:
    function getModule($name=NULL)
    {
       return 
    $this->modules->get($name);

    I know that's a very simplistic example, but when you're trying to write a system that uses as much OO as possible, the constant use of array handling functions just seems kinda 'icky' (I guess because it's procedural code within OO code), in my humble opinion anyway.

    Quote Originally Posted by BerislavLopac
    4. Superglobals. Various platforms has different ways to access system, application and session data -- PHP has superglobals like $_REQUEST or $_SESSION.
    Like with regular arrays, I find dealing with the raw superglobals also icky. Usually I try to have some sort of wrapper class around them, like HTTPRequest and HTTPSession, which encapsulates functionality related to each. Again this is just how I feel about it, many others would probably have no problem with using the raw superglobals throughout their code but I don't like doing that generally. Also, I guess the "globals are bad bad BAD" notion gets drilled into you a bit from the OO camps.

    Quote Originally Posted by BerislavLopac
    5. Statelessness. Unlike other platforms, PHP doesn't have the ability to keep the created objects in memory during the lifetime's application. This calls for a different approach to session and application-wide persistance, as the approach that other languages use cannot simply be emulated.
    This is true, and you do need to be conscious of how much "stuff" you are doing per request/response cycle, however you can certainly emulate the approaches other languages use (without knowing the specifics you were refering to), you just need to be mindful of bloat and require a good persistence layer/session handling.

  4. #29
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by {RainmakeR}
    I agree that .ini files can be useful, however the main problem I have with them is that it can be difficult to represent a hierarchy of objects/data within them.
    As I said, I love other peoples input and I didn't realy think about this. One sollution could be to have one .ini file for each "step" in the hierarchy, and the only reference to the rest of the .ini files it has is it's parent and it's childs.



    Quote Originally Posted by {RainmakeR}
    True, arrays are powerful but I generally like using a wrapper class because otherwise you have to duplicate a lot of array-specific code everywhere, for example:

    PHP Code:
    function getModule($name=NULL)
    {
       if (isset(
    $this->modules[$name]))
       {
          return 
    $this->modules[$name];
       }

    vs

    PHP Code:
    function getModule($name=NULL)
    {
       return 
    $this->modules->get($name);

    I know that's a very simplistic example, but when you're trying to write a system that uses as much OO as possible, the constant use of array handling functions just seems kinda 'icky' (I guess because it's procedural code within OO code), in my humble opinion anyway.
    I agree here, and I personally prefer wrapper classes vs. arrays. One example is that sometimes a stack is very efficient in terms of memory use and speed compared to a big array - where the array functionalltiy of keeping all the values in memory even after they've been used, just gets in the way.


    Quote Originally Posted by {RainmakeR}
    Like with regular arrays, I find dealing with the raw superglobals also icky. Usually I try to have some sort of wrapper class around them, like HTTPRequest and HTTPSession, which encapsulates functionality related to each. Again this is just how I feel about it, many others would probably have no problem with using the raw superglobals throughout their code but I don't like doing that generally. Also, I guess the "globals are bad bad BAD" notion gets drilled into you a bit from the OO camps.
    Could not agree more, dealing with raw superglobals is *icky*. You'd want some type of DataSpace interface and InputCleaner interface(that removes for example magic_quotes_gpc, etc.) for the HTTPRequest, HTTPResponse and HTTPSessions.


    Quote Originally Posted by {RainmakeR}
    This is true, and you do need to be conscious of how much "stuff" you are doing per request/response cycle, however you can certainly emulate the approaches other languages use (without knowing the specifics you were refering to), you just need to be mindful of bloat and require a good persistence layer/session handling.
    About the object persistance I'm quite sure that we'd want some type of easy managable way to unserialize/rebuild the objects. And this is where SQLite comes in, even if we can't use some type of HEAP-table I'd still pick a DB over "pure" file-storage just because it's a much cleaner approach. I'd also pick SQLite over MySQL here because the SQLite-file can be created at runtime if it doesn't exist - and you could have some config-variable to specifiy both the objectpersistance and session db-files location, for example:

    (config.ini)
    object_persistance = "/usr/local/framework_objper.sql"
    create_mask = 0700

    session_persistance = "/usr/local/framework_ssn.sql"
    create_mask = 0700

  5. #30
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Another thing that came up in my mind is if we want some String/Array/HashMap/Integer/Float classes? As php5 has typehinting for everything except the primitive type, this could be both a bad and good idea to make sure you get the correct input. To illustrate to example doing the same thing:


    PHP Code:
    <?php

    class String
    {
        
        protected 
    $string;

        public function 
    __construct($string=null)
        {
            
    $this->string = (string)$string;
        }
        
        public function 
    get()
        {
            return 
    $this->string;
        }
        
        public function 
    __toString()
        {
            return 
    $this->string;
        }

    }

    class 
    Tester
    {
            static public function 
    typeHinting(String $string)
            {
                echo 
    $string;
            }
            static public function 
    normal($string)
            {
                
    $string = (string)$tring/* << Has to be done on all parameter w/o type hinting, IMHO */
                
    echo $string;
            }
    }

    $str1 = new String("Woot1<br />\n");
    $str2 "Woot2<br />\n";
    Tester::typeHinting($str1);
    Tester::normal($str2);

    ?>
    Sure, it requires quite an overhead... is this overdoing and not worth it?

  6. #31
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Sorry, I meant the ForceType directive.
    If I understood it correctly, ForceType has a couple of disadvantages:

    1. It requires the existence of one file for each application -- e.g., for www.example.com/application/module/ we need to have an "application" file. which means that we can't use a single point of entry (Front Controller) for everything. Even then, Apache's multiviews option seems much more appropriate.

    2. I don't think it's portable -- even if it is, other servers like IIS probably have a very different way of handling it.

    The 404 hack has the following advantages:

    a) It abides the HTTP standards, which means that all HTTP servers have some way of setting it up.

    b) Allowes for a more flexible entry point strategy; if we really want separate applications, we can set various subfolders with their own 404 handlers.

    That being said, the main disadvantage of this approach that all of your pages return a 404 Not Found response header, which can mess up your HTTP logs.

  7. #32
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by {RainmakeR}
    I agree that .ini files can be useful, however the main problem I have with them is that it can be difficult to represent a hierarchy of objects/data within them.
    Depends on how complex a structure you need. Ini files can handle up to one level deep structures -- you can have:
    Code:
    [group1]
        var1 = value1
        var2 = value2
    
    [group2]
        var1 = value1
        var2 = value2
    which translates to:
    PHP Code:
    array('group1' => array('var1' => 'value1''var2' => 'value2'),
          
    'group2' => array('var1' => 'value1''var2' => 'value2')
          ); 
    For anything more complex use XML by any means, or multiple ini files if appropriate (e.g. multiple languages are best handled by multiple ini files, one per language).

    Quote Originally Posted by {RainmakeR}
    True, arrays are powerful but I generally like using a wrapper class because otherwise you have to duplicate a lot of array-specific code everywhere ... when you're trying to write a system that uses as much OO as possible, the constant use of array handling functions just seems kinda 'icky' (I guess because it's procedural code within OO code)
    Again, depends on what you currently need. The notion that mixing OOP and procedural is bad probably comes from Java influence -- the fact is that PHP has procedural roots, and that it has many powerful functions built in. We shouldn't be mindless purists and think in only one midset, whether procedural or OO. We should always keep in mind what would be the best PHP way to handle things.

  8. #33
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by NeverMind
    doesn't the :memory: option in sqlite is the same as Mysql's heap? ... it's true that the DB only exists while the script is executing..
    You just answered your own question here...

  9. #34
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    You see, sessions are by default stored at the disk. In any case, they need to be serialized before they are stored for persistance -- the overhead of reading a file or SQLite db is minor here.
    What is this statement based on? I believe it's the other way around, serialization is minor compared to finding and reading a file or DB record.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  10. #35
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by thr
    About the object persistance I'm quite sure that we'd want some type of easy managable way to unserialize/rebuild the objects.
    I'm not sure what you mean here.

    PHP has a) automatic serialization of everything and b) custom session handlers. So all you have to do is create a custom session handler which will work with databases (ADOdb already has one), and use your standard $_SESSION syntax.

    How is this:
    PHP Code:
    Session::store('object'$object);
    $object Session::retrieve('object'); 
    simpler and easier than:
    PHP Code:
    $_SESSION['object'] = $object;
    $object $_SESSION['object'
    (except in a OO purity way)?

    Quote Originally Posted by thr
    Another thing that came up in my mind is if we want some String/Array/HashMap/Integer/Float classes? As php5 has typehinting for everything except the primitive type, this could be both a bad and good idea to make sure you get the correct input.
    I don't think this would be a good idea, for two reasons.

    First, do you know of any good reason to put simple primitive data into objects? Everything works perfectly well without it, and adding new classes would make things more complicated.

    The classes should be defined per objects required for the application. For example, it makes sense to create a class Money, since money can have much more properties than a simple number (currency, subdivisions, conversion rates etc), but a generic Number class would be an overkill.

    Second, as I have argued on several occasions, type hinting in PHP should be used very carefully and sparingly, if at all. PHP is a dynamic language, which means that its variables are not tied to any particular data type. It also has a great set of automatic conversion rules, meaking possible such feats as putting a string into one variable and then using it in a math calculation. When it comes to objects, this dynamicism frees us from having to follow strict inheritance hierarchies and applying specific interfaces; instead we can put any object into any variable, and it will work providing it has the right properties (that is called "duck typing").

    PHP5 has introduced type hinting and interfaces, but if you think twice you will notice that this is a strange couple: one really makes no sense without the other, and everything can work quite nicely without either of them. If you use type hinting, you will soon or later need to use an interface to enable different hierarchies to be passed to the same method; and without type hinting there is absolutely no requirement to use interfaces.

    Personally, I often end up using them simply because they are here and make things easier to understand, although not to implement. However, I'd prefer the good old ducktyping and Python's notion of EAFP -- easier to ask forgiveness than permission. Luckily, PHP5 makes this easy by introducting the exceptions:
    PHP Code:
    // --- permission example:

    interface MyInterface
    {
        function 
    foo();
    }

    class 
    MyClass(MyInterface $bar)
    {

        function 
    baz()
        {
            
    $bar->foo();
        }

    }

    // --- forgiveness example

    class MyClass($bar)
    {

        function 
    baz()
        {
            try {
                
    $bar->foo();
            }
            catch (
    Exception $e) {
                
    // do something else
            
    }
        }


    The first example throws an error, the second an exception.

  11. #36
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by dagfinn
    What is this statement based on? I believe it's the other way around, serialization is minor compared to finding and reading a file or DB record.
    Sorry, I agree that my statement was not too clear: what I meant was that there is not much difference in the overhead between using a file or using a database.

    Using shared memory would probably make things faster, but I have quite bad experience with stability of this approach.

  12. #37
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    BerislavLopac: Yeah, your probably correct about the primitive>object thingie.. just a quick thought I got last night.

    I'm still trying to come up with some basic frame to build on, after reading the SKeleton-threads I'm leaning more towards some type of State-mechanism to keep the different levels of our application separate. And that all states either evalute to true or false, and both true and false either evaluteate into either true or false themself, etc. Untill we have a response of some kind.

  13. #38
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Another thing I think we should try to look to is how did Rails come up with thier "almost no config files"-setup? I don't want to mimic the rails API at all, but maybee it could give some good pointers ?

  14. #39
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    The 404 hack has the following advantages:

    a) It abides the HTTP standards, which means that all HTTP servers have some way of setting it up.
    First, I'm not absoultely against this method -- I agree it is clever and I've used it myself. Still, it IS an ABUSE of the standard. If you want an OOP analogy, it is the same as using try/catch to implement application logic rather to handle error conditions. Unfortunately, the shortest "easiest" route is not always the best. Besides, using 404s to redirect content can lead to confusing and hard to debug issues.

  15. #40
    SitePoint Guru thr's Avatar
    Join Date
    Jun 2003
    Location
    Sweden
    Posts
    664
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Was thinking that we'd need some type of logging mechanism, this is what came out in terms of code of the top of my head:
    PHP Code:
    <?php
    class Logger
    {
        
        protected 
    $log = array();
        
        public function 
    addLog(Log $log,$identifier)
        {
            
    $this->log[$identifier] = $log;
        }
        
        public function 
    log($identifier,$message)
        {
            
    $this->log[$identifier]->log($message);
        }
        
    }

    interface 
    Log
    {
        public function 
    log($message);
    }

    class 
    FileLog implements Log
    {
        
        protected 
    $file;
        protected 
    $handle null;
        
        public function 
    __construct($file)
        {
            
    $this->file = (string)$file;
        }
        
        public function 
    __destruct()
        {
            if(
    $this->handle !== null){
                
    fclose($this->handle);
            }
        }
        
        public function 
    log($message)
        {
            
    $this->openHandle();
            
    fwrite($this->handle,$message,strlen($message));
        }
        
        protected function 
    openHandle()
        {
            if(
    $this->handle === null){
                
    $this->handle fopen($this->file,'a');
            }        
        }
        
    }

    class 
    ExceptionFileLog extends FileLog
    {
        
        public function 
    log($e)
        {
            
    $message $e->getMessage();
            
    $code $e->getCode();
            
    $file $e->getFile();
            
    $line $e->getLine();
            
    $trace $e->getTraceAsString();
            
    $log "Exception on line: $line, in file: $file.\r\nCode: $code\r\nBacktrace: $trace\r\n";
            
    parent::log($log);
        }
        
    }


    $logger = new Logger;
    $logger->addLog(new FileLog("access.log"),'access');
    $logger->addLog(new FileLog("error.log"),'error');
    $logger->addLog(new ExceptionFileLog('exception.log'),'exception');
    $logger->log('error','Error on line...XXX');
    $logger->log('access','Logger.php, 18:09 2005-10-11, from localhost');
    try{
        throw new 
    Exception("... Error ...");
    }catch(
    Exception $e){
        
    $logger->log('exception',$e);
    }
    ?>

  16. #41
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    it is the same as using try/catch to implement application logic rather to handle error conditions.
    I'm not sure I understand you here. Because catching exceptions IS (one way of) handling error conditions...

  17. #42
    SitePoint Addict Trent Reimer's Avatar
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    228
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    You see, sessions are by default stored at the disk. In any case, they need to be serialized before they are stored for persistance -- the overhead of reading a file or SQLite db is minor here
    True. Just a thought on scalability: is SQLite able to serve session data to clustered servers if necessary? I have heard of MySQL being used for this purpose and would expect SQLite could too but it would be good to know that.

    I'm liking this thread. I personally don't see anything wrong with having more than one option but it IS good to have one or more *well supported* options.

  18. #43
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Database backend choice or URL format are (or should be) irrelevant to a framework/code base. They are matters of personal preference or system requirements. It is not difficult to handle different cases.

    One of the biggest drags on these design converstations is each programmers reaches their set of solutions through a series of choices they make, but they then make the mistake of believing that their solution is the "best" way rather than simply one possible result.
    Christopher

  19. #44
    SitePoint Evangelist ghurtado's Avatar
    Join Date
    Sep 2003
    Location
    Wixom, Michigan
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    We shouldn't be mindless purists and think in only one midset, whether procedural or OO. We should always keep in mind what would be the best PHP way to handle things.
    I think this is a rather crucial point that most PHP developers miss, and it hints at the reason why PHP has such an identity crisis. The majority of advanced PHP developers that have a strong influence in the usage of the language are too focused on making PHP more like other languages, when in reality what we need is more people wanting to (as you said) make PHP more like PHP. But for that, of course, you must first fully understand, just what exactly is the identity of PHP?

    Berislav, you are giving us some very valuable insight into precisely this question through your posts, I find myself constantly nodding in agreement when I read you.
    Garcia

  20. #45
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    I'm not sure I understand you here. Because catching exceptions IS (one way of) handling error conditions...
    Perhaps I misunderstood why you suggested the 404 hack? It seemed you were intending it as an alternative to either server level url handling logic (mod-rewrite) or application level logic (ForceType scripts). The point, though, is that if the server throws a 404, the idea of an error handler is to handle the error -- NOT to apply application production rules at that juncture. To give you a comparable pseudo-example:
    Code:
    try {
    	$foo = file_get_contents('bar');
    } catch (FILE_NOT_EXISTS) {
    	$foo = file_get_contents('barbar');
     }
    is not an appropriate way to determine $foo.

    Subverting 404 can be practical but it is simply not a best-practice.

  21. #46
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Trent Reimer
    True. Just a thought on scalability: is SQLite able to serve session data to clustered servers if necessary? I have heard of MySQL being used for this purpose and would expect SQLite could too but it would be good to know that.
    As a file-based database, it doesn't scale well. But if a good db abstraction library is used -- such as the aforementioned ADOdb -- its should be trivial to switch to MySQL or another server-based database.

  22. #47
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ghurtado
    I think this is a rather crucial point that most PHP developers miss, and it hints at the reason why PHP has such an identity crisis. The majority of advanced PHP developers that have a strong influence in the usage of the language are too focused on making PHP more like other languages, when in reality what we need is more people wanting to (as you said) make PHP more like PHP.
    By this logic we should ignore the opinions of the "majority of advanced PHP developers" because they have missed "this is a rather crucial point" and are "mindless purists and think in only one midset", and instead find "more people wanting to (as you said) make PHP more like PHP" whatever that is?

    I think if there is and "identity crisis", it is about which direction makes "PHP more like PHP".
    Christopher

  23. #48
    SitePoint Guru BerislavLopac's Avatar
    Join Date
    Sep 2004
    Location
    Zagreb, Croatia
    Posts
    830
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Perhaps I misunderstood why you suggested the 404 hack? It seemed you were intending it as an alternative to either server level url handling logic (mod-rewrite) or application level logic (ForceType scripts). The point, though, is that if the server throws a 404, the idea of an error handler is to handle the error -- NOT to apply application production rules at that juncture. To give you a comparable pseudo-example:
    Code:
    try {
    	$foo = file_get_contents('bar');
    } catch (FILE_NOT_EXISTS) {
    	$foo = file_get_contents('barbar');
     }
    is not an appropriate way to determine $foo.

    Subverting 404 can be practical but it is simply not a best-practice.
    Actually, your example is a pretty good approach -- not to replace the regular if-clause, but to provide exceptional logic, i.e. logic that is performed in exceptional cases. If, in your example, the file 'bar' usually can be read for contents, the catch block provides the alternate course of action. Exceptions are not intended for simple echo $e->message error reporting; they sre used exactly for handling exceptional (i.e. erroneous) cases.

    That being said, as I said earlier, the problem with 404 hack is that all your regular page calls start returning 404 errors, which will mess up your logs and give you wrong stats.

  24. #49
    SitePoint Addict Trent Reimer's Avatar
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    228
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    (I don't like Rails convention that class names are singular while table names are plural)
    This sounds like a minor detail but it is important. "mice" is the plural of "mouse", "moose" is both singular AND plural, etc. By the time you have rules in place to handle the entire english language you have to think about the guy who wants to set up database objects in french If you get around that hurdle it means you're wasting computing resources on stuff that really is distracting from the job at hand. Often the simple way is the right way.
    Last edited by Trent Reimer; Oct 11, 2005 at 11:39. Reason: speling

  25. #50
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by BerislavLopac
    Actually, your example is a pretty good approach -- not to replace the regular if-clause, but to provide exceptional logic, i.e. logic that is performed in exceptional cases. If, in your example, the file 'bar' usually can be read for contents, the catch block provides the alternate course of action. Exceptions are not intended for simple echo $e->message error reporting; they sre used exactly for handling exceptional (i.e. erroneous) cases.
    No, it is not a good approach.

    This is not exceptional logic, it is application logic. If I want to conditionally show b if a is not available, I should test for a (file_exists) and then try to show b if it is not available. Catching a FILE_NOT_EXISTS represents something else: I *expected* that the file *ought* exist, but it did not.


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
  •