
We are still working on the third version of the
PHPixie framework, but we can already say for sure that it will change a lot for the better (as for me):
- Full transition to PSR-2 standard
- Since the framework will be a set of libraries, its components can be used in any project without PHPixie itself.
- 100% code coverage tests. In this case, 100% is not just a figurative word, but actually calculated “code coverage”, that is, the ratio of the lines that are called when executing the tests to all the lines of code, by the way, Laravel is only 53% .
Yesterday, two libraries became available that will be included in PHPixie 3, they are fully ready and you can already use them with any project. This is done. You can read more about this in a
post on the site , and here I will describe what I like most about them.
')
By the way, the libraries are really covered with tests for 100%, you can make sure
here and
here .
PHPixie Config
Config Slices
Allow to separate options for parts of the system from the system itself, thereby making them more agnostic and independent. For example, consider the following settings of the level of a game which player tries to capture the castle:
array( 'battlefield' => array( 'background' => 'forest', 'castle' => array( 'turrets' => array( 'amount' => 5 ) ) ), 'attackers' => array( 'knight' => array( 'attack' => 6 ), 'paladin' => array( 'attack' => 4, 'spell' => 'heal' ) ) );
We are already used to using '.' to read such arrays, for example using $ config-> get ('battlefield.castle.turrets.amount'), but it would be incorrect to use such code in the Castle class, since it needs to know then all the way to the place where its configuration begins . Of course, in the parent class, you can pass all turrets_amount directly into the constructor, but there is a better way:
class Level { public function __construct($slice){ $this->battlefield = new Battlefield($config->slice('battlefield'); } } class Battlefield { public function __construct($slice){ $this->background = new Background($config->get('background')); $this->castle = new Castle($config->slice('castle')); } } class Castle { public function __construct($slice){ $this->background = new Background($config->get('turrets.amount')); } } $level = new Level($config);
As you can see, all classes are now completely independent of the configuration path itself, just for this slice () was invented.
Splitting configuration into folders
The ability to create separate files for parts of the configuration allows, for example, to easily commit only the settings of the application itself and include in the .gitignore file with the configuration of something specific (for example, a connection to the database). As written on the site, PHPixie allows you to easily create files with text translation on the site into different languages ​​on your base. For example, take the following file structure:
config.php
config /
+ -forest.php
+ -forest /
+ -meadow /
+ -fairy.php
Now, if we search for the
forest.meadow.fairy.name option, the search will go in such places:
1) 'name' in config / forest / meadow / fairy.php
2) 'fairy.name' in config / forest / meadow.php
3) 'meadow.forest.name' in config / forest.php
4) 'forest.meadow.forest.name' in config.php
By the way, there is support for writing information back to the configuration file, for example, if you have a ban system that will write banned aipishka to the config file.
PHPixie Database
Firstly, the promised support for MongoDB was added, examples of its use can be found in the same article on the site, the resulting interface is very similar to the MySQL access interface, therefore it will allow MongoDB to try even to those who have never encountered it. But I will focus on other possibilities:
Condition Placeholders
We all know different query builders, which allow us to add conditions like this:
$query ->where('type', 'elf') ->orWhere(function($q){ $q ->_and('name', 'Trixie') ->_and('type', 'fairy') });
There is nothing new here, but they have a small problem: what to do if then you need to add one more condition to that OR (), in another place / class? In PHPixie, you can create a control point to which you then add conditions, for example:
$placeholder = null; $query ->where('type', 'elf') ->orWhere(function($q){ $q ->_and('name', 'Trixie') ->_and('type', 'fairy'); $placeholder = $q->addPlaceholder('and'); }); $placeholder->_and('status', 'active');
For the construction of complex queries the use of such points is very useful.
Simplified Addition
Since for SQL queries, in addition to WHERE conditions, you can also add HAVING and ON conditions, each of them has its own set of methods: orWhereNot, xorHaving ... and so on. To speed up the writing of conditions, you can use abbreviated versions, which will add the conditions of the last type added:
Support for nested $ or for MongoDB
A known bug that MongoDB will not use indexes if you write a very complex query using nested $ or. PHPixie itself will fix this for you by turning such queries into a expanded form that will already use indexes. It all works out of the box.
Special operators for comparison
Often you have to compare one column with another, the problem is that if you write like this:
$query ->where('amount','>', 'minAmount');
in fact, the value of the amount column will be compared with the string “minAmount”, in order to indicate that the value is the name of the column in the database, you just need to attach an asterisk to the operator:
$query ->where('amount','>*', 'minAmount');
Simple, understandable and concise.
If you're interested ...
To see how this all works in action
, here is an example of code that works with MongoDB and MySQL and also shows how to set it up without the framework itself with just a few lines of code.