-
Notifications
You must be signed in to change notification settings - Fork 55
Introduction
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 php composer.phar install from the commandline in the directory where you put FuelPHP. That will also clone the required packages into the vendor directory, and it will install the demo application.
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 folder, you'll find Controller, Model, Migration and Task folders, which are now separate namespaces, and all autoloadable. The Routing engine can route to controllers (default), tasks and migrations. The last two will be used by the oil front controller. 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.
Like in 1.x, most classes are accessable via a static interface. Unlike 1.x, this interface doesn't provide just static (and therefore global) methods, it operates on an instance of either the same class, or the class it is designed to be a facade for. Which instance depends on the type of instance being called, and the context in which you call it.
In 2.0, core classes are layered by context. Every class lives in a one or more specific context(s). 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 automatic 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 current context, and will not impact data stored at higher levels.
When you use one of the Facade classes in your application, they will detect the current context when you call them, and will use the correct object for that context. For example, if you would use \Input::get() in your Controller, it will know it operates in the Request context, it will know which Request, and will give you all GET variables assigned to that request, merged with whatever GET variables were present in higher layer contexts.
Version 2 will be completely driven by a very versatile and fast Dependency container. It allows you to store class references, define identifiers (aliases) for classes, and define the type (singleton, multiton, etc). It also supports specific and generic extensions that you can hook into a class definition, and will run upon instantiation of a class. This can for example be used to inject external dependencies at runtime, completely transparent to your application.
Every FuelPHP specific composer library can be equiped with a ServiceProvider class. It replaces the current package bootstrap mechanism, and can be used to run specific setup code for the library. The ServiceProvider can also contain a provide() method that will inform the Dependency container which classes or identifiers are provided by the library, and can contain the class registration and extension code required to instantiate such a class.
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 similar to the MVP (Model-View-Presenter) concept, which we think 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. 2.0 will introduce a new Query Builder or DataBase Abstraction Layer (DBAL), more object oriented, more and more advanced features, and fully platform independent. Upon release there will be support for MySQL, PostgreSQL, MSSQL and SQLite, but more will follow.
2.0 will also come with a new version of Fuel's famous ORM. Completely refactored, and event driven to allow you to plug optional functionality in without problems. Need a model that supports both Nested sets, versioning, and soft-delete? No problem, you can mix-and-match.
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 front controller. We're thinking about giving oil a web interface, so you can run commands and generate code without needed a commandline. This will probably not be available from day one though.
Tasks have been reimplemented as Controllers in the "Tasks" namespace, which means their methods require an 'action_' prefix and they're inside a subnamespace of the Application. The routing to these Tasks works through the normal routing mechanism, but requires switching the Routing engine from "Controller" to "Task" mode. When using the oil front controller, this will happen automatically.
All Oil command-classes will be reimplemented as Tasks.
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.