コハナ3の料理

どういうわけか、約1か月間、このすばらしいフレームワークの開発をフォローしなかったことが判明しました。 バージョン2.4の開発速度を見るのは悲しかった。 しかし、昨日、私はそのサイトを見て、息を切らしました。 開発者は、バージョン2.4の準備が整うのを待たずに、候補バージョン3の2つのリリースをリリースすることができました 。 ソーステキストを見て、フォーラムを少し読んで、 09/09/09以前を待たずに喜びを分かち合うことにしたので、今後の変更に心から幸せを感じました。

トピック外コメント:ちなみに、私は明らかにRCと呼ばれる予定のバージョンに反対です。なぜなら、それらがリリースにならないことは明らかであるからです。



最初に注意したいのは、バージョン2.3との互換性がないことです。プロジェクトをそこから転送する場合は、主にクラス名に多くの変更を加える必要がありますが、ほとんどの場合、これはこれに限定されません。



新しいエンジン機能



ファイルシステム階層


ファイルシステムの構成が完全に改訂され、それに伴いクラスの命名規則が変更されました。 また、システムは多層のままで、次の各層が前の層のファイルと重なります( )。 変更点は次のとおりです。ヘルパー、モデル、コントローラー、その他に明確な区分がなくなりました。 これで、すべてのクラスがクラスフォルダーに保存されます。 私たちもエンジンも、すべてのクラスについて、システムが同じディレクトリに移動することを決定するために奇妙な命名規則を使用する必要はありません。 したがって、クラス自体の命名規則が変更されました;名前は、ファイルが置かれているクラスディレクトリのすべてのサブディレクトリとファイル自体の名前で構成される必要があります。 たとえば、クラスDatabase_Query_Builderは、ファイル/classes/database/query/builder.phpにあります。 したがって、すべてのコントローラーをコントローラーフォルダーに配置すると、コントローラーの名前付け規則が自動的に取得されます。コントローラーのプレフィックスは "Controller_"で始まる必要があります。



基本的なシステム機能の拡張


以前に話したことは、厳密なphp5 OOPフレームワークがevalを介してクラスをその場で生成するということです。 ブランチ2.0のcohanaでは、_Core接尾辞を持つmythicクラスから継承するベースクラスを拡張できることを説明します。 これらの同じ_Coreは実際のクラスであり、_Coreのない名前のクラスは、ユーザーが定義していない場合、その場で生成されました。 このような不名誉は発生せず、拡張機能全体がはるかに単純です。すべてのシステムファイルは、クラス「Kohana_%classname%」から継承された空のクラスです。 たとえば、同じDatabase_Query_Builderの定義は次のとおりです。



抽象クラス Database_Query_Builder Kohana_Database_Query_Builderを拡張します{ }




名前が示すとおり、基本クラスは単にclasses / kohanaフォルダーにあります。 したがって、自動ロードメカニズムは大幅に簡素化され、クラスのタイプを区別してその場で何かを生成する必要がなくなり、すべてのクラスは同じ概念内で命名されます。 さらに、NetBeansまたはEclipseのオートコンプリート用の松葉杖は不要になります。



フレームワークは「見た」


システムフォルダーから不要なものをすべて削除することにしました。 さらに、同じ配布パッケージ(データベースとormなど)に含まれる別のモジュールに何かを投げ、そうでないもの(captchaとmysqlとpdo以外のすべてのデータベースドライバーの場所はありませんでした)。 しかし、心配しないでください。これらはすべて追加のパッケージでダウンロードできます。



起動プロセスを完全に制御


システムの一部を動作メカニズムに収集するbootstrap.phpファイルは、システムからアプリケーションに移行されました。 これは、システムがロードされる前であっても、システムのあらゆる側面に介入できることを意味します。 特に、ログや構成の独自のアダプターを追加できます。これは、たとえばデータベースやxmlで機能します。 以前は個別の設定にあった多くの設定もここに移動しました。 たとえば、使用済みモジュール、ルーティング。 ところで、ルーティングは特筆に値します。 彼らはそれがRoRに似てきたと言っていますが、私はRoRを見たことがないので、自分で見てください:

ルート:: set 'default' '(<controller>(/ <action>(/ <id>)))'

-> デフォルト 配列

'controller' => 'welcome'

'アクション' => 'インデックス'

;




データベース層の変更


私の意見では、これが最もジューシーな部分です。 データベースレイヤーは完全に置き換えられました。 クエリビルダーがすべての必要なクエリの70%をカバーする前に、この数字は99に近づいています。新しいクエリビルダーの助けを借りて、次のことができるようになりました。

ここに新しい層の構文が何であるかのかなり多くの例を見ることができます



ORMレイヤーの変更


たぶん何かが足りないかもしれませんが、私が理解しているように、ORMの変更はそれほどグローバルではありません。 最も重要な変更は遅延読み込みであり、データベースクエリは必要な場合にのみ行われます。 これにより、たとえば、削除時に2つのクエリを回避できます。

ORM :: factory 'user' 'homm86@gmail.com' -> delete ;




さらに


変更は、エンジンの作業の他の側面にも影響を及ぼしました。たとえば、国際化、メッセージメカニズムの導入、RESTコントローラーの登場、ロギングおよび構成システムは、ディスク上のファイルだけでなく、ビューフラグメントキャッシングの追加だけでなく、すべてのことを伝える他の何か、または私が、リリース後:)



便利なリンク


バージョン2.4および3.0の状況



All Articles