Tired of non-standards? Take a look.

[thr]

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:

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:

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:

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.

[NeverMind]

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?

$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

[{RainmakeR}]

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.

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:

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

vs

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.

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.

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.

[thr]

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.

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:

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

vs

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.

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.

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

[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. To illustrate to example doing the same thing:

<?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?

[BerislavLopac]

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.

[BerislavLopac]

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:

[group1]
    var1 = value1
    var2 = value2

[group2]
    var1 = value1
    var2 = value2

which translates to:

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).

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.

[BerislavLopac]

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...

[dagfinn]

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.

[BerislavLopac]

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:

Session::store('object', $object);
$object = Session::retrieve('object'); 

simpler and easier than:

$_SESSION['object'] = $object;
$object = $_SESSION['object'] 

(except in a OO purity way)?

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:

// --- 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.

[BerislavLopac]

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.

[thr]

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.

[thr]

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 ?

[jayboots]

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.

[thr]

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
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);
}
?>

[BerislavLopac]

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...

[Trent Reimer]

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.

[arborint]

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.

[ghurtado]

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.

[jayboots]

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:

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.

[BerislavLopac]

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.

[arborint]

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".

[BerislavLopac]

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:

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.

[Trent Reimer]

(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.

[jayboots]

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.