Home
This is the next generation of the FuelPHP framework. It is in early development state, and should not be used for production usage. While this is written anew from the ground up, much of the code was ported from v1.x., and much effort has been put into making the migration as seamless as possible.
Clone or download this repository and run composer.phar install from the commandline in the directory where you put FuelPHP. That will also clone the required packages into the vendor directory.
Below you'll find a list of important techniques/patterns implemented.
The number of subdirectories used has been increasing and we felt this has become less clear. We have decided to move to reorganise the structure, and move the less edited/used files into a 'resources' subdirectory.
- The old 'frontend' package has been split into a 'frontend' and an 'application' package.
- In a package folder itself you'll find: classes, config, lang, vendor, modules, resources and views.
- In the resources folder you'll find: migrations, tests and vendor. In Application Packages you'll also have: cache, logs and tmp.
Version 2.0 will include and have its packages setup to be installable using Composer. Also allowing you to easily include other packages from Packagist.
By default FuelPHP will now use the PSR-0 standard for classloading. Its implementation is actually a superset, but it is fully compatible with PSR-0. For convenience and speed each Fuel-specific Package can be given a base namespace that will be required and stripped before any class to path conversion takes place (these are not loadable through the Composer autoloader). The same goes for modules inside the Package, those will have subnamespaces that are required and stripped before conversion as well.
We also decided to adopt PSR-1, which means that instead of snake_case names the methods & variablenames are now camelCased.
In v1.x the Application, Core and the Oil package weren't normal packages and didn't follow the same rules as other packages. Packages were also not routeable. As of 2.0, everything follows the rules of a package, and (if configured) will be routeable. The v1.x Core will be divided up into different components, with a compact kernel, and additional packages that will introduce extra functionality to the framework.
Defining of the routes has also been moved outside the config dir and into the Application root.
todo
todo
The initialization of FuelPHP has been divided up into setting up the Environment and initializing the Application. The environment settings entail all those settings that should not or cannot be changed while an Application is running but should instead be considered fixed.
The concept of Modules has been simplified into a way of structuring your files inside the Package directory. All Views, Configs and Language files from a Module are considered the same as those from the parent Package (the latter taking precedence). The concept of an 'active' Module has been removed (of which the filepath took precedence over the Application).
They're also no longer limited to the Application directory and can be put into any Package. They must be a
subnamespace inside that Package and be a subdirectory in the modules directory of that Package.
Oil is now an Application within the new setup. This means it has an Application wrapper class and its own internal routing. Its own Front Controller is still named oil (without extension) and has almost no differences with the normal index.php FC.
Tasks have been reimplemented as specialized Controllers which means their methods require an 'action_' prefix and they're inside a subnamespace of the Application. The routing to these Tasks works through normal routing means but requires specialized Route objects that route to Tasks instead of Controllers.
All Oil command-classes have been reimplemented as Tasks.
Even though both Config and Language had a concept of 'groups' they were just 1 massive container per Application. This is no longer the case. Each Application will have a main Config object that can access its 'children' much like before, but those children will be separate objects which can be accessed on their own and are part of the class that loaded them.
The Config and Language classes have also both become extensions of the new Data superclass as they share a lot of their functionality. Among which are a new default values convention and very basic settings validation.
As the name lead to much confusion and discussion about CamelCasing of the name we decided that it is time for a better name. ViewModel is the name the concept has in MVVM (Model-View-ViewModel), but it is about as similar to the MVP (Model-View-Presenter) concept and that provides better clarity about its function. They will remain very much optional though and FuelPHP will remain MVC.
The old v1.x. Query Builder needed to go, we have been unsatisfied with it for some time - especially its lack of real platform independence. FuelPHP will not be tied to any Query Builder or DataBase Abstraction Layer (DBAL), but we will have drivers for them. Currently Doctrine2's DBAL has a bit of support, and we'll add support for FrenkyNet's new DBAL named Cabinet.
The v1.x ORM package will remain the preferred ORM, and will be converted to use Cabinet as DBAL.
The Framework packages will no longer contain any static classes at all as those break encapsulation. We are
however aware of how popular they are and how much they facilitate rapid development. For those who do not mind the limitations (which will be no bigger than those currently imposed by them in 1.x) there is a static interface package available. This will allow usage like Validation::forge() but more importantly they will support all methods available on an instance as a static interface. Thus any method available
on the Fuel\Core\Validation object will be available on the Validation class through a singleton instance of Validation inside it. This will be done using __callStatic() and thus always keep up with any changes to the Core, never lagging behind.
We'll also provide as much backwards compatibility for 1.x as is possible. Some things will need a bit of search & replace, though doable project wide if your IDE/texteditor is capable of that. Other things will require a little bit of rewriting, migrations are an example of that as mentioned. Any Core extensions will not and cannot be backwards compatible for the most part.
Migration guide, on how to migrate an existing v1.x application to 2.0.