Crudder in action

It took a while.. a long while actually.. but I finally made a new release of Crudder. This new release 0.50 has a lot of new features and bugfixes, to name a few;

• New Field-type: HTML-editor
• New Field-type: File-upload
• New Field-type: Enum
• Export to CSV
• Adding records from the many-2-many-editor
• Bugfixes; language-support works better, datefield has been fixed, the many-2-many-editor should work better

Check out the DEMO or read more

There are some pretty good uses for a Singleton though; a registry and the database-connection;

Download example code here

Database-connection

I use ADODB to access databases, don’t ask me why, I just do. ADODB uses a DSN to connect to a database, which looks something like:

mysql://dbUser:dbPass@localhost/someDb

Normally you’d use $connection = &ADONewConnection($DSN) to connect to the database and run your query ($rs = $connection->execute($sqlQuery) ). The problem here; you keep creating new connections anywhere you run a query, you need to pass the value for $DSN into your objects,  you’ve made your class depend on ADODB and it take 2 lines of code   You can bypass these ‘problems’ by using a Singleton to connect to your database and run a query:

$rs = basicDBConn::getConnection()->execute($sqlQuery);

Now, what is wrong here? Did you see $DSN anywhere?
Nope… This statement assumes you’ve passed $DSN already somewhere before, in fact the first time you call getConnection() from this singleton you must pass $DSN as argument in getConnection(). The first time you call getConnection() is the moment the singleton creates an instance of itself, and uses $DSN to connect to the database (&ADONewConnection($DSN)). After this initialization the connection is kept within the Singleton, and $DSN isn’t needed anymore. Take a look at the files, basicDBConn.php in particular to get an idea of how the Singleton creates an instance of itself and the database-connection.

Registry

Another good use for Singletons is a Registry-object; A registry-object is used for configuration; global settings that you might need in your code (path’s, DB-configuration etc.). Since I’m infected by the XML-virus my configuration-files always are XML :

<config>
    <item index="DSN">mysql://dbUser:dbPass@localhost/singletondemo</item>
    <item index="someKey">someValue</item>
</config>

There is a drawback though; these XML-files are not protected by Apache by default, anyone can open them from a browser (if they are somewhere in the public root of the website). There are 2 solutions for this; prefix the file with .hta (in which case Apache will protect them just as .htaccess files are protected) or add the following lines to your Apache-configuration :

<Files ~ "configuration_filename.xml">
   Order allow,deny
   Deny from all
</Files>

The registry-object works the same as the Database-object; it needs a reference to a XML-file the first time you call it, after that it’s fully initialized and doesn’t need that reference anymore.

The first call to a registry object (and get the value for ’some_key’):

$someValue = basicRegistry::getInstance('/path/to/configuration/file.xml')->get("some_key");

Any call after that:

$someValue = basicRegistry::getInstance()->get("some_key");

Why is a singleton a good thing?
Getting configuration-values or a $DSN-string from within objects should be simple, you do not want to pass the path and filename to your configuration file or $DSN to a database every time you create an instance of an object. It will create dependencies and spaghetti in your code. If you make sure the registry and/or database-object are created before your other objects start doing something you do not need to worry about file-names and/or $DSN’s. They have been safely put away in a singleton.

Another very nice side-effect ; you’ve decoupled database-connections and configuration-settings. In my examples I use XML to setup the values in the registry, if you want to use some other method of keeping key-value-pairs, just modify the inner workings of the Registry-singleton, the objects using the registry won’t notice and work just as well. I usually keep session-variables in the registry, if I can’t use PHP’s $_SESSION, I can fall back onto Cookies, my classes won’t notice.

Download example code here