Roadmap

Seperate concerns by splitting the core up into feature specific packages

The current framework core is a collection of classes supporting features that actually warrant a separate package. For example Event, the Query Builder, Session, etc. These classes need to be split off the core, to make the core more compact and manageble.

Refactor Tasks and Migrations

Both currently do not follow the cascading file system, which means the autoloader can not load these classes. Loading is done hardcoded in oil, app classes can not use them unless they use the same code.

This has to be changed so the normal loading mechanisms are used and the classes can be called from app controllers too.

Refactor the Profiler

Current profiler is pretty static, monolithic, and from a layout point of view not very handy as it overlays your webpage. We will probably offer a basic profiler in the core offering just the information, and an add-on package that provides visualization.

Refactor Unzip

Refactor the current Unzip class into a driver based archive class, so other compression and package algorithms can be used.

Refactor "oil generate"

A lot of the functionality related to generation is still hardcoded in the different oil classes. To make this as flexible as possible, the code needs to be refactored so that all variable code is in templates and generation logic in tasks that can be replaced or augmented by the user.

Rewrite Form/Validation/Fieldset classes

The current trio is one tangled mess, which needs to be sorted out.

Admin package

The ability to generate an admin section for an application, much like the Django administration module.

Replace current Query Builder

New and more flexible query builder classes, PDO driven, and with better support for different RDBMS engines.

New package based loader that does both file & classloads

Everything in Fuel should become a package (including app & core) and modules should be allowed in every package. PSR-0 will become the default but each package can be set to use its own autoloader logic. This will also unify fileloading & classloading as those shouldn't be seperated.

Along with this the concept of Modules in FuelPHP will be simplified and no longer be tied to the Application. Modules will be a way of structuring you code and its non class files will fully cascade into its package, the package files themselves taking precedence over the module files when conflicts arise.

Reimplement Fuel init logic separating Environment and App logic

The environmental settings should be static/singleton as they should be considered such (ignoring that fact is just foolish). All non environmental logic should go into an App class that is instantiated for the app to run and sets up your application and handles the necessary bootstrapping.

Implement inversion of control throughout the core

Statics will be used way less in 2.0 and dependencies will be build and managed by the dependency package.

All other core packages will contain service provider to provide functionality to the framework.

Decentralize config & language

Config values and language will no longer be in one huge container but instead they'll be put into config/lang objects that are linked to the class that uses them. With this should also come specific validations and rewrite rules for config settings to be set with each class - thus unifying the way config parsing happens throughout Fuel.

Make FuelPHP Composer compatible

The Fuel components, like core and all packages, will be based upon the Composer/Packagist structure to be installable through Composer. This should also add support for installing non-Fuel packages from Packagist. Fuel based packages are still required to return a loader object and must be loaded in order to be available. All non-Fuel packages with PSR-0 autoloader support can be made available by adding a single Fuel-Composer loader to the stack.

Refactor Pagination

Remove all application specific code from the current Pagination class, and replace it by callbacks and app templates.

Asset and Theme refactoring

The current Asset class required you to use groups, and options. The usage should be simplified by making the groups optional. The class will be converted into an instance based model which will allow for multiple Asset instances each with their own configuration.

The usability of the Theme class is going to be improved with support for widgets and widget chrome. It will use an Asset instance to access theme specific assets.

Refactor Sessions

Session drivers are too complicated, and too much information in the session cookie that should be stored server-side.

Replace Log by the Monolog library

The current Log class allows simple logging to files only, and only in a static way. It has to be replaced by the Monolog library, which allows for multiple handlers, message preprocessors and formatters, so you will have the flexibility to log to whatever you want.

Refactor Upload

The class has to be rewritten so that in creates an upload class instance per file uploaded, and every file uploaded can be treated individually, instead of the current "batch" mode.