It so happened that for about a month I did not follow the development of this
wonderful framework . Observing the speed of developing version 2.4 caused melancholy. But yesterday I looked at the site and gasped. It turns out that the developers, without waiting for the readiness of version 2.4, had already managed to release as many as
2 releases of the candidate of version 3 . I looked into the source code, read the forum a little and it became so joyful to me from the coming changes that I decided not to wait until
09/09/09 or earlier and to share the joy.
Off-topic note: By the way, I am opposed to versions that are clearly still
planned to be finalized to be called RC, because it is clear that they will not become a release, what could be a candidate.
The first thing I would like to note is that there will be no compatibility with version 2.3, if you want to transfer a project from it, you will have to make a large number of changes, mainly to the names of classes, but most likely this will not stop there.
New features of the engine
File system hierarchy
The file system organization has been completely revised, and with it the class naming rules have changed. The system also remained multi-layered, where each next layer overlaps the files of the previous one (
picture ). What has changed is this: there is no more explicit division into helpers, models, controllers, and anything else. All classes are now stored in the classes folder. No longer do we or the engine need to apply strange naming rules to determine that in front of us, behind all classes, the system goes to the same directory. The naming rules for the classes themselves have changed accordingly; the name should consist of all the subdirectories of the classes directory that contains the file and the name of the file itself. For example, the Database_Query_Builder class will be in the file /classes/database/query/builder.php. Thus, if we add all controllers to the controller folder, we automatically get the controller naming rule: they must begin with the prefix “Controller_”.
')
Expansion of the basic functionality of the system
What we talked about before, how so strict php5 OOP framework generates classes on the fly through eval, no more. I explain, Kohana branches 2.0 allowed to expand the base classes, inheriting from the mythical classes with the postfix _Core. These _Core were real classes, and classes with names without _Core, if they were not defined by the user, were generated on the fly. More such ugliness does not occur and the entire extension is much simpler: all files of the system are empty classes, inherited from the classes "Kohana_% classname%". For example, here is the definition of the same Database_Query_Builder:
abstract class Database_Query_Builder extends Kohana_Database_Query_Builder { }
The base classes, as the name suggests, simply lie in the classes / kohana folder. Thus, the autoload mechanism is greatly simplified, it no longer needs to distinguish between the types of classes and generate something on the fly, all classes are named within the same concept. In addition, you will no longer need crutches for autocomplete in NetBeans or Eclipse.
Framework "drank"
From the system folder decided to throw out all unnecessary. With that, something was thrown into separate modules that go in one distribution (for example, database and orm), and something that is not there either (there was no space for captcha and all database drivers, except for mysql and pdo). But do not worry, all of this can be downloaded in additional packages.
Full control over the boot process
The bootstrap.php file, which is responsible for collecting pieces of the system into the working mechanism, migrated from the system to the application. And this means that we can now intervene in any aspect of the system before it is loaded. In particular, we can add our own logs and configs adapters that will work, for example, with a database or with xml. Many settings that previously were in separate configs moved here. For example, modules used, routing. By the way, routing deserves a separate mention. They say he looked like RoR, but I did not see RoR, so see for yourself:
Route :: set ( 'default' , '(<controller> (/ <action> (/ <id>)))' )
-> defaults ( array (
'controller' => 'welcome' ,
'action' => 'index' ,
) )
Changes in the database layer
This, in my opinion the most juicy part. The database layer has been completely replaced, and I must say very knowingly. If earlier the query builder covered about 70 percent of all the necessary queries, now this figure tends to 99. Judge for yourself, with the help of the new query builder, you can now:
- Use arbitrary functions for fields, not only defined by developers.
- Use parentheses in where clauses
- Specify several conditions for join, and they no longer have to be fields of linked tables, you can specify values ​​or functions from fields.
- Use arbitrary expressions in general if the functional is not enough with DB :: expr ()
- Use subqueries!
- Make inserts from selections (INSERT ... SELECT)
Quite a few examples of what the syntax of the new layer will be
here .
ORM layer changes
Maybe I’m missing something, but as I understand it, the changes in ORM are not so global. The most significant change is lazy loading, now the database query is done only when necessary. This allows, for example, to avoid two queries when deleting:
ORM :: factory ( 'user' , 'homm86@gmail.com' ) -> delete ( ) ;
Besides
The changes were touched and other aspects of the engine, such as internationalization, a message mechanism was introduced, a REST controller appeared, logging and configs systems were able to work with different adapters, not only files on disk, added view fragment caching, but let all something different, or me, but after the release :)
useful links
The situation with versions 2.4 and 3.0