Upcoming 0.2 release
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.
Posted by: Dave Redfern (Writer), in Roadmap on 18 Jan 2009 @ 04:42
Contents:
This
work is licenced under a
Creative Commons Licence.