Sam Moffatt

So what is JRegistry exactly? Well its a simple registry system aimed at providing flexibility in storing its data. It is designed to expose a simple interface for general usage (JRegistry class) with a read/writer class (JRegistryStorageEngine) and a parser (JRegistryStorageFormat).

 Originally I wrote a simple registry system for a 4.6 CVS over a year and a bit ago now. It used a simple XML schema and wasn't very extendable. It worked into the database and used the element system that was being implemented in 4.6 (and subsequently dropped). It was a single class/file infrastructure and it was locked to one database. I rewrote it recently to use INI with the same database format.

 Now I'm redesigning it to make it more flexible. The end game is to allow you to store your 'registry' in a file, a directory or a database. And you can use either INI or XML format to do it. I'm writing this done almost for my sake so that I can have something that I won't want to try and change later.

 JRegistry has your usual set of getter and setter functions, but also holds a JRegistryStorageEngine object which handles the real manipulation. JRegistryStorageEngine stores a copy of the loaded 'registry' information where possible. This was originally going to be cached by JRegistry, but design issues with the Engine system meant that a namespace can be split up into multiple rows in a database or multiple files. This would obviously require more than one look up for searches on multiple namespaces, but in 90% of cases this will provide slightly better performance.

 Stepping mildly to the side here, what I'm trying to do on the storage side is segregate namespaces. Why? Well if we put them all together the 'master' or global registry object (which hopefully will be used by default, but this can be used in a similar fashion to $database). This global $registry will use the database #__registry and will default to the INI storage format. I'm hoping this will become popular as people will create their own namespace inline with their Joomla!Forge project's unique name (e.g. phpbb_tools is one of my projects so any entries would be like phpbb_tools.database.name or similar). Keep in mind that JRegistry isn't aimed at replacing ALL of the param system in place at the moment, but to provide a system to reduce duplication. For example if you have three different modules and a mambot sharing a similar configuration (e.g. phpbb's work) then this would be a very useful solution for common configuration. Moving along.

JRegistryStorageFormat is used to serialize and reserialize the data. It has three functions to implement: objectToString, stringToObjet and getFormatName. Namespace dumping should be optional.