将来のPHPixie 3の2つの新しいライブラリを既に使用できます。

これまでのところ、 PHPixieフレームワークの3番目のバージョンで作業が進行中ですが、（私にとっては）より良い方向に大きく変化することは確かです。

• PSR-2標準への完全な移行
• フレームワークはライブラリのセットになるため、そのコンポーネントは、PHPixie自体がなくても任意のプロジェクトで使用できます。
• テストによる100％のコードカバレッジ。 さらに、この場合、100％は単なる比fig的な言葉ではなく、実際に計算された「コードカバレッジ」、つまり、テストを実行するときに呼び出される行とコードのすべての行の比率です。

PHPixie 3に含まれる2つのライブラリは昨日利用可能になりました。完全に準備が整っており、すでに任意のプロジェクトで使用できます。 これについては、サイトの投稿で詳細を確認できますが、ここで私が最も気に入っている点を説明します。







ところで、ライブラリは実際にテストで100％カバーされています 。 こちらとこちらをご覧ください。

PHPixie Config

構成スライス

システムの各部分のオプションをシステム自体から分離できるため、より不可知論的で独立したものになります。 たとえば、プレイヤーが城を攻略しようとしているゲームのレベル設定を考えてみましょう。

array( 'battlefield' => array( 'background' => 'forest', 'castle' => array( 'turrets' => array( 'amount' => 5 ) ) ), 'attackers' => array( 'knight' => array( 'attack' => 6 ), 'paladin' => array( 'attack' => 4, 'spell' => 'heal' ) ) );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちはすでに「。」の使用に慣れています このような配列を読み取るには、たとえば$ config-> get（ 'battlefield.castle.turrets.amount'）を使用しますが、Castleクラスでこのようなコードを使用するのは正しくありません。構成が開始される場所へのパス全体を知る必要があるからです。 。 もちろん、すべてのturrets_amountを親クラスのコンストラクターに直接渡すことができますが、より良い方法があります。

 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);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、このスライス（）が考案されたため、すべてのクラスは構成パス自体から完全に独立しています。

パーティション構成

構成の各部分に個別のファイルを作成する機能により、たとえば、アプリケーション自体の設定のみを簡単にコミットし、特定の構成（たとえば、データベースへの接続）で.gitignoreファイルに含めることができます。 また、サイトに記載されているように、PHPixieを使用すると、サイト上のテキストをベースの異なる言語に翻訳したファイルを簡単に作成できます。 たとえば、次のファイル構造を考えます。

 config.php
 config /
 + -forest.php
   +-フォレスト/
       + -meadow /
            + -fairy.php

ここで、 forest.meadow.fairy.nameオプションを探すと、そのような場所で検索が行われます。



1）config / forest / meadow / fairy.phpの 'name'

2）config / forest / meadow.phpの「fairy.name」

3）config / forest.phpの「meadow.forest.name」

4）config.phpの「forest.meadow.forest.name」



ところで、たとえば、禁止されたIPを構成に書き込む禁止システムがある場合、構成ファイルに情報を書き戻すサポートがあります。

PHPixieデータベース

まず、MongoDBの約束されたサポートが追加されます。その使用例はサイトの同じ記事にあります。結果のインターフェイスはMySQLアクセスインターフェイスに非常に似ているため、MongoDBに出会ったことのない人でも試せるようになります。 しかし、私は他の可能性に焦点を当てます。

条件プレースホルダー

さまざまなクエリビルダーに慣れているので、次のような条件を追加できます。

 $query ->where('type', 'elf') ->orWhere(function($q){ $q ->_and('name', 'Trixie') ->_and('type', 'fairy') }); // WHERE type = 'elf' OR (name = 'Trixie' and type = 'fairy')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここには新しいものは何もありませんが、小さな問題があります。そのOR（）に別の条件を追加する必要がある場合は、すでに別の場所/クラスにありますか？ PHPixieでは、条件を追加するブレークポイントを作成できます。次に例を示します。

 $placeholder = null; $query ->where('type', 'elf') ->orWhere(function($q){ $q ->_and('name', 'Trixie') ->_and('type', 'fairy'); $placeholder = $q->addPlaceholder('and'); }); $placeholder->_and('status', 'active'); // WHERE type = 'elf' OR (name = 'Trixie' and type = 'fairy' and status='active')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

複雑なクエリを作成するには、このようなポイントを使用すると非常に便利です。

単純化された追加条件

SQLクエリでは、WHERE条件に加えてHAVING条件とON条件を追加できるため、それぞれに独自のメソッドセットがあります：orWhereNot、xorHaving ...など。 条件の記述を高速化するために、最後に追加されたタイプの条件を追加する短縮バージョンを使用できます。

 // $query ->where('type', 'elf') ->orWhere('id', 5) ->having('count', 5) ->xorHaving('max', 6); // $query ->where('type', 'elf') ->_or('id', 5) ->having('count', 5) ->_xor('max', 6);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ネストされた$またはMongoDBのサポート

よく知られているバグは 、ネストされた$ orを使用して複雑すぎるクエリを記述した場合、MongoDBはインデックスを使用しないことです。 PHPixieは、このようなクエリを、既にインデックスを使用するデプロイ済みフォームに変換することにより、これを修正します。 それはすべて箱から出して動作します。

比較のための特別な演算子

多くの場合、ある列を別の列と比較する必要があります。問題は、次のように書く場合です。

 $query ->where('amount','>', 'minAmount');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際、値列の値は文字列「minAmount」と比較され、値がデータベース内の列の名前であることを示すために、演算子にアスタリスクを付けるだけです。

 $query ->where('amount','>*', 'minAmount');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

シンプル、明確、簡潔。

興味があるなら...

すべてがどのように動作するかを確認するために、MongoDBおよびMySQLで動作するコードの例を示します。また、わずか数行のコードで、フレームワーク自体なしですべてを構成する方法も示します。