Upcoming 0.2 release

Posted by Dave Redfern (Writer), Roadmap on 18 Jan 2009 @ 04:42

New CLI Layer

No sooner is 0.1.4 out for general availability, but 0.2 rears its head again. While some of the features planned for 0.2 are already implemented (they will be covered soon), a very extensive and un-expected enhancement has been made.

New CLI Layer

The biggest change coming in 0.2 is the complete re-design of the CLI layer. This will only affected command line programs and daemons.

First the bad news: Unfortunately owing to the nature of the re-design 0.2 is not compatible with 0.1.X. Any applications or daemons will need to be re-built.

BUT - good news! Re-building is not as bad as it sounds. The existing Scorpio CLI tools have been re-built in only a few days. At the time of writing both generator and mvcGenerator remain but all the others have been ported already. In fact the re-design highlighted many issues with the existing apps and have allowed them to be refactored far more efficiently than would have otherwise been possible.

So what are the major changes?

Well, instead of a hierarchy like: cli -> cliApplication -> yourApp or cliApplication -> cliDaemon -> yourDaemon, there is now a concrete cliApplication class. This does not need to be extended anymore - but it is for daemons. cliApplication now contains all the signal handling code. cliProcessControls remains largely un-affected. cliDaemon has been totally overhauled and now has an execute() method which has to be extended.

And now the really interesting part: the CLI has acquired the cliRequest (previously cliArguments) and cliCommand. cliRequest now differentiates between switches (-T -b -v) parameter toggles (--my-var=foobar) and arguments (action name something). While parameters and arguments are handling together, switches are held distinctly separate. The cliRequest is passed to a cliApplication and is dispatched. This is where the cliCommandChain and cliCommand come in.

cliCommandChain is as it sounds, a set of cliCommands. This is what now makes up the cliApplication. Each command is a small compact unit that can be switched into and out of an application making it possible to share similar tasks between apps. cliCommand is the execution unit. Ideally it performs only a single action, but it can easily forward to another command (if it is available). Further a cliCommand can have its own command chain of further actions.

Lastly: cliApplication has a cliApplicationListeners object that can have additional listeners attached. A cliApplicationEvent can be fired to these listeners to engage some other activity. Currently planned are an emailer and a logger - yes the cli layer is no longer dependent on systemLog (except for cliProcessControls which are outside the scope of cliApplication) for logging. Logger is already implemented and is used byt the existing apps.

A whole set of default commands will be available including a 'Help' command that formats help information including aliases (triggers), arguments and more. Help has been extended and can now provide additional information about a command such as if it has a command chain, then these commands are the parents possible values so will be presented when the help is called. Help can now be called as myApp.php help to list further information on a command. Log and LogToConsole handle the previous verbose, very verbose and output. Null and Switch are generic commands that do nothing themselves but can be used to provide additional help and command values.

All in all it is a major enhancement that provides for much richer, lighter applications with a far higher ability to re-use code. For example: the testSuite.php had many methods that should not have been in the app, but in library objects. Now that this refactoring has been done that code could be used to power a web-based test suite. It is similar to the wurflParser and the other tools.

Already present and correct

Several outstanding items are on the roadmap, as has already been mentioned. I will just touch on these to give an overview of where progress has got to.

Enhanced Autoload System

In a previous roadmap article, I discussed several possibilities for enhancing the autoload system, well all of these changes have now been incorporated into the main 0.1.X line and therefore are already in 0.2.

Just to recap, all autoload cache files are now entirely lowercase. This removes part of the casing problem. The second item, was to make the autoload mechanism more flexible. This was done by replacing the existing regular expression match with a string utility method that breaks apart strings into far more components. Together with some additional logic to handle PEAR style Class_Names (or Zend Framework) the autoload system can now handle not only those classes, but if no cache file is located it will attempt to locate the class via the file system.

While not perfect (no system will ever be!) it is certainly a big improvement. As yet another improvement it is now possible to add autoload cache file locations. By default both libraries/autoload and classes/autoload are pre-assigned but any number of locations can be used.

Multi-Language Support

Multi-language support has been on the list of requirements for a long time. Ideally it would have been in 0.1 but due to the lack of time to research options, it was left out. Recently (and coinciding with a related work project), I was able to investigate solutions in use in a number of other applications and frameworks. This list was not complete but included: Zend Framework, Symfony, Cake, Prado, Yii, Solar, PEAR Translate (1 and 2), ezComponents, Drupal, Wordpress, ezPublish, Moodle, phpMyAdmin, phpPgAdmin and the Smarty Il8n pre-filter and the Smarty pre-filter by John Coggeshall that was published way back in 2004 in phpArchitect.

Some solutions were rather, brute force (php(My/Pg)Admin and not really workable. Others were very heavily integrated Symfony, Cake. And a couple only supported gettext for translation. The Smarty pre-filters were discounted as they are (obviously) only tied to Smarty.

In the end the most elegant and least tightly coupled solution was Zend Frameworks. This had yet another ace up its sleeve: multiple adaptors for many different formats of language file including some that can be edited using full blown desktop applications. Unfortunately it required the use of Zend_Locale, which itself includes an enormous amount of additional libraries.

So the implementation was adapted from Zend Framework (full credit and comments given) but it was simplified for use in Scorpio. Documentation needs updating to cover it, but this was implemented for 0.1.4. The usage is not mandated in any component and it is not fully tested yet, but this is slowly being covered. Additional methods will be added to the mvcView layer to provide the necessary hooks for translation. All in, this should be the best approach.

Sites System

This tool is being completely rebuilt for the new cliApplication system. The current thinking is to replace it and the generator with a single tool that can handle the needs of both. The new cliCommand architecture will allow this to be done much more simply.

As the redesign is already in progress, the location of the template files is going to be addressed. They have always been uncomfortably sat in the tools folder. Instead the default templates will be moved back to the libraries while custom templates will be moved to the data folder. This should prevent any mix-ups. The config will be extended to allow the 'default' templates to be specified as well.

With regards to the data structures, well at present they will have to remain as is until the CLI tool work is completed.

Controller Map Extensions

As the multi-language implementation has not been hard wired into the MVC layer yet, this decision is still pending. It would likely be a good idea to set the locale, but this could be easily done outside the controllerMap at the dispatch and resolver level. Currently there is no immediate requirement to make a decision so when the time comes with a proper deployment that will probably influence the ultimate design.

Dates

Switching all the internal dates to date objects is a rather large task. New objects can be handled by template changes in the generators but changing the return types right now would be a lot of work. It is still in the planning, but out of all the features is the most likely to be delayed to 0.2.X or even 0.3.

< Return to article