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 old 'frontend' package (fuel/fuel) has been split into a new 'frontend' (fuelphp/fuelphp) and an 'application' (fuelphp/demo-application) package.
- In a package folder itself you'll find the typical Fuel folder structure: classes, config, lang, modules, views.
- In the classes folder, 'view' has been renamed to Presenter. Besides this foler, you'll find Controller, Model, Migration and Task, which are now separate namespaces, and all autoloadable. In Application Packages you'll also have folders for 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 (currently labeled PSR-X by the FIG), but it is fully compatible with PSR-0.
We also decided to adopt PSR-1, which means that instead of snake_case names the methods & variablenames are now camelCased.
And just to be complete, we have not adopted PSR-2, which is not a standard in our opinion, it's a religion. As a coding standard, we continue using the current standard, taken PSR-1 into account.
In FuelPHP v1.x, you had modules, and you had packages. Modules were defined as extensions to the frontend, the application, and packages were defined as extensions of the backend, the framework core. This will change.
In 2.0, a new concept of Application is introduced. A single installation can contain multiple applications, which can have separate frontloaders, but can also call each other. You can for example decide to have a frontend application and a RESTful API driven backend application, installed in the same FuelPHP installation. When you need to scale, simply move one of the two to a second server. Or you want to split the frontend of your application from the admin interface, but still allow them to talk to each other. Oil, the current commandline tool for code generation and batch operations, will be rewritten as a separate application.
Every application will have it's own configuration, environment settings, etc. You can even run one in 'development' mode, and one in 'production' mode, of the same FuelPHP installation!
Within an application, you can have modules. They will have much more functionality then they have now, so there will be no need anymore to put frontend code elsewhere.
A module can:
- have a configurable base namespace that is not related to the modules folder name
- have a base URI segment prefix that is not related to the modules folder name
- be installed anywhere, and is no longer confined to a 'modules' folder
- be defined as routable or non-routable (for the main request)
- have a bootstrap for module initialisation
The features of the current module system, such as fallback to the application for config, lang and views, will remain.
Packages will no longer exist in the current sense of the work. They will be replaced by Composer libraries (which a lot of people call packages, probably due to their repository being called packagist.org, but according to the composer documentation, you should use the word "library". So we will).
Composer libraries may contain a PackageProvider class, which serves two purposes. One is to replace what is now the bootstrap, so initial setup and preparation for when the package is loaded (by composer in this case). Within the application, you can enable or disable a library. The provider class also contains methods to perform construct or destruct actions when you enable or disable a library. Note that happens per application, so make sure nothing is done globally!
A library can contain the standard composer functionality, adding classes to enrich the backend or framework functionality, but can also contain a 'classes' folder structure in which you can place a module. Or a 'modules' folder with multiple modules. It is the task of the PackageProvider to inform the application that the module exists, where to find it, how to call it, etc.
In 2.0, the classes layering is dictated by context. Every class lives in a specific context. Any FuelPHP installation will have the following contexts:
- Global (all global or PHP settings, global Input and Config)
- Application (Environment, Session, Log, Cache, the View system, Routing, Lang, etc)
- Request (Input, Config, Lang)
2.0 will have full multi-lingual support. That starts with the framework itself, where Exception messages will be shown in your servers system locale. Every application will keep separate language containers for every language you activate. Which means that contrary to version 1.x, you can use multiple languages within a single request. Loading a language file for one language will no longer overwrite one previously loaded for another language.
Language operates within the Application and Request context. Everything you load at the application level will be available to all requests, languages you load within the context of a Request will only be available inside that request.
Configuration now operates within the Global context and the Application context. Within the global context you will find all configuration related to the server, the PHP installation, or the framework installation as a whole. Think about locale, timezones, etc. Within the application context you'll have all your application specific settings, like security, routing specifics, etc.
Input operates in the Global context and the request context. In the global context, all external input (GET/POST/PUT/DELETE/PATCH) will be processed and stored. Every request will have it's own Input environment, to which you can pass the HTTP method to simulate, and the all input you want to pass on, up simulating cookie data and file uploads.
For all classes that operation in multiple contexts, an inheritance system is implemented, which will allow you to transparently access data available in a higher layer context. Updating such a value will only update the correct context, and will not impact data stored at higher levels.
todo
todo
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.