So far 0.1 is looking in pretty good shape. There are still a few rough edges that need to be dealt with namely documentation (still) and unit tests. During the updates and bug fixes a few issues have come to light though that are going to be address in upcoming releases.
1. Integration of the admin system
At the time it seemed like a good idea to integrate the basic admin functionality into the base distribution, but now that is looking like a mistake. For 0.2 the admin system and all the classes used within it will become a component separate to the base. This will make the base smaller and lighter and not tie down some of the working - it can be used if needed, instead of perhaps not being of any use at all.
2. Sites System
The current implementation of the sites within the admin system is rather awkward - it works, but needs a lot of manual configuration and while the CLI mvcGenerator does a good job of compiling new components, it is not very consistent or straight forward. The whole tool will be re-built to be more useful and more intelligent in it's approach. Currently you cannot use it without first having created a site in the database - but what if you just want to start building a new site? The tool will not be like the symfony or rails tools that attempt to build an environment etc, but will be more powerful than it currently is.
3. Multi-language support
With the successful abstraction of Smarty from the mvcView system, it is time to look more closely at how best to implement a multi-language layer into the framework. There are a number of possibilities, however the requirements are pretty tight:
- It must not be tied to any one template engine (rules out Smarty prefilters)
- It must be able to handle UTF-8 character sets
- It must not be difficult to implement within a template (i.e. it would be better to not have LANG_X_Y_Z_1 type constants littered through templates)
- It must not place too large an overhead on the system
A library of either an array of values or constants is one possiblity but that does make the templates hard to read and does not give a sense of how they will look. It also places a strain as all text has to be removed and added and unique references given.
There is always gettext which may be useful.
4. Extensions to the controllerMap
The controllerMap is proving to be an extremely good investment both in terms of handling site permissions (as in the controllers that are available to the current site) but also as a method for generating sitemaps. What it is lacking, however, is an ability to define the site root e.g. if multiple languages are in use should the first block of the / after the domain be the language? If so how far in until we reach the first part of the routing information? This could be added to the controllerMap or could be handled via the site config. It is something being considered.
5. Switch all "dates" to DateTime objects
A bigger change to the framework would be re-working all handling of dates to use the systemDateTime object. The benefit of this would be to put timezone / direct date manipulation straight into the data rather than having to either create date objects from existing date strings - that may or may not be compatible.
Additional benefits from doing this include better validation and error handling. That would make date-checking easier both from user-input as well as code output.
The downside is an additional object for each date-time which could massively increase the memory requirements. This would be most noticeable when dealing with recordsets that contain create, update and/or access dates as each would need to be an individual object. Of course they could be lazy loaded.
As other items come up they will be added to this page.