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 terms of modularity, things have changed. 1.x had modules, which were like mini-applications in their own namespace, inside the application. In 2.0, these are now called packages, and are completely separate from the application itself, which is also a package. Per package you can define whether or not they are publicly routable.
1.x also had packages, which were defined as core extensions, but were also widely used for front-end functionality, although that wasn't the idea. In 2.0, the framework is extended by means of libraries, which are separate composer packages. Any composer package can be used in FuelPHP, but to integrate them in the framework they need a loader.php in the ./src folder.
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.