One of the features that would make FuelPHP 1.6 unique is the introduction of temporal models. Temporal models enable you to determine the state of a model at a point in time rather than the current state. Think of it as a kind of versioning. If you have used a Wiki, you are probably aware of the ability to view each of the different edits, which is along the lines of walking backward through time to determine how the Wiki page came into its current state of being.
Two other features of FuelPHP’s ORM package are Entity-Attribute-Value (EAV) containers and soft-deletion. EAV containers are used to store attributes about a model when you cannot determine beforehand what those attributes may be, thus removing the rigidity of having a schema. Soft-deletion, as the name implies, is when you do not actually delete data from a table but instead mark a field that indicates that the row should not be displayed. Both the EAV container and soft deletion features are already available in FuelPHP 1.5.
Sure, design patterns are good but there are times when they seem excessive. One particular example that I was pointed to recently is the following Java class:
That is quite a large class name to type, but right there, from the name of the class, you can guess that it uses the singleton, proxy, and abstract factory (assume an abstract factory) design patterns. So, how did they come up with something like that? Programming contest on who could write the most design patterns in a single class?
If you have used oil in FuelPHP 1.5.1, you may have noticed that the controllers generated by the oil scaffolding do not use the configurer controller prefix. What this means is that if you are using namespaces or something other than the default controller prefix, the scaffolding controllers will not work.
The good news, however, is that Harro (WanWizard) commited a fix to the oil git repo last week so you will see a fix to the issue soon, perhaps in the FuelPHP 1.6 or 2.0 release. Until then, try to stick to the default prefix (fuel/app/classes/controller directory and no namespaces) or you will have to refactor the code generated by oil to get it to work with the rest of your application.
While you are learning FuelPHP, consider getting a copy of the FuelPHP Guide from the Kindle Amazon eBook store.
With migrations, FuelPHP provides an easy way to manage database changes. It is typically used in combination with the oil utility to make changes to the database. Migrations are PHP files that push database changes in a versioned form. The generation of migration scripts is also simplified by the oil utility, which treats the name of the migration as an indicator of the activity to be performed, such as creating or renaming database tables.
Every migration script provides the ability to move up or move down a version so you do not have to keep multiple databases running to test your app across different versions of the database, at least in theory.
If you had a go at switching to CakePHP, you are probably aware of the conventions to follow to get the framework to provide its ORM features. Sure, FuelPHP has conventions too but they are simpler, and the ability to configure what conventions you would like to use or even override those conventions are well-documented.
There still is a bit of rigidity in naming controllers but you can name your database tables and columns as you please and then define how FuelPHP should treat those columns. Having said that, I should also mention that FuelPHP does not make the configuration of the ORM as complex as Hibernate does.
There is also the ability to have FuelPHP auto-discover columns and leave most of the heavy lifting to the framework while you are prototyping.
The FuelPHP Auth package provides the ability to authenticate users and determine if the have the rights to access a particular resource using roles. Think of roles as the distinction between editors and journalists in a news agency. Journalists can create articles but they do not make it to print till editors approve the articles. Pages are the resources protected by resources and call the Auth package to authorize users.