BitrixFramework：すべてを自分の手に

こんにちは！



Bitrixのトピックに関する私からの別の自殺記事は、今回はhabrabsocietyがより寛大になることを願っています 実際には、コード、スキーム、ホリバーなしですべてがここにあり、すべてが公平です。



この記事では、BitrixFrameworkの代替案を検討します。これは、開発者の作業を楽にし、Bitrix CMSの開発に何らかの形で正しい方向に影響を与えるように設計されています。



嫌いな人への対応：通常の批判と、カルマへのトピックに関するコメントを書く場合、個人的に送信します;-)。 種のVolfycha、内部のすべてが興味深い...

まず、すべての「i」にドットを付けましょう

以下に書かれていることはすべて私の個人的な意見であり、スリッパに落ち着いて投げることができますが、私は正しいと確信しています：

1. 「Bitrixには100万行のたわごとがあります」 -はい、間違いありません。 全体の問題は、Bitrixが下位互換性をサポートしていることです（バージョン12.0から16.5に更新すると、すべてが正常に機能するはずです）。 なぜ彼らがこれをするのか、私にはわかりません（私には誰も知らないようです）。 標準コンポーネントのソース（情報ブロック要素を表示するための2K行のコード-物事の順序）について話すと、連中はエンドユーザーが使いやすくすることを決定し、想定できるすべてのものを提供しました（これは事実ではありません）。必要なときに。 さて、追いつくために、最近のセミナーで、Bitrix開発者はPSRに対する態度を発表しました：「まあ、このPSRとは何か、私はそれを読んで、何人かの男が集まってゴミを書きました」（正確な引用ではありません）。 したがって、コードは常に臭いがします。
2. 「Bitrixにはひどい構造があります」 -そうではありません。 Bitrixはファイルベースであり、MVCの理解は一般に受け入れられているものとは異なり、多くの場合、「MVCではない」=「ホラーホラーとは何かの構造」です。 したがって、これは非常に物議をかもし、物議を醸す問題です。 そして、あなたはBitrix構造で生きることができます。
3. 「BitrixFrameworkは決して発展しない」 -これが私の意見であり、ここに理由があります。リリースごとに、Bitrixは「Shop」モジュールのみをファイナライズし、いくつかの変更を行いますが、それらはすべてストアを対象としています。 彼らは率直に言って残りを気にしません。 BFの開発は、下位互換性を放棄し、Shopモジュール以上のものを扱うようになったときに始まります。

ジャガーノートに会おう！

確かに多くの人がこのキャラクターに精通しています（Dotaからではなく、Marvelから）。彼は「やめられない」。 少し哀れな名前は、実際、このプロジェクトの本質を反映しています。それは、Bitrixの開発方法、導入されたイノベーション、ライブラリの存続と繁栄にまったく関係ありません。



Bitrixはユーザーを対象としています。 Juggernautは開発者向けです。

なぜこれが必要なのですか？

必要だから！ 実際にはすべてが非常に論理的です：

• Bitrixは新しいカーネルを開発しています（良い）が、彼らはまったく文書化したくない（悪い）;
• Bitrixは新しい機能を開発しています（良い）が、ストア専用です（悪い）。
• Bitrixは新しいコンポーネントを開発しています（良い）が、目からのコードの血から（悪い）;
• Bitrixは「新しい」技術「複合サイト」の特許を取得しました（悪い）。

バージョン14からは、バージョン14の古いカーネルのサポートを終了し、新しい「しかし、顧客への配慮」に重点を置く必要がありました。 でたらめ。 これは、Yii2がYii1をサポートして組み合わせた場合も同じです。



Bitrixは進歩を遂げていないため、コミュニティは（泣き言、Ideaサービスへの書き込み、標準コンポーネントを使用したねじれの代わりに）それを行います。



Scられたビトリックス、今、ジャガーノートのレビューを始めることができます。 次に、ライブラリの構成部分の概要とその使用方法の簡単な説明を開始します。

コンポーネント

コンポーネントは、Bitrix Webサイトの構築元となるブリックです。 コンポーネントは条件付きで2つのカテゴリに分類されます：ウィジェットとルーター（Bitrix表記では「通常」と「複雑」）。

ウィジェット

ウィジェットは、愚かなことに1つの基本的なタスクを実行する（フォーム、リスト、情報を表示する）コンポーネントです。 ウィジェットは入力を受け取り、何らかの方法でそれを変換します。 彼は他に何もするべきではありません。 ウィジェットはルーティングを制御しませんが、使用できます。



コンポーネント実行のデフォルトの順序：





順番に：

• init-初期データを初期化します。 入力パラメーター（$ arParams）をクラスプロパティに変換します。
• onBefore-アクションの可能性をチェックします。
• isCachedTemplate-キャッシュされたコピーがあるかどうかを決定するフラグ。 存在する場合はキャッシュデータを表示し、存在しない場合はキャッシュデータを形成します（コードでは見た目が少し異なりますが、図では簡単にするためにこれを示しています）。
• initResult-プレゼンテーション用のデータを生成（$ arResult）;
• run-ウィジェットを直接実行する機能。 データ（$ arResult）で何をする必要があるかを決定します。
• onBeforeRender-テンプレート出力の可能性をチェックし、変換を実行します（result_modifier.phpと同様ですが、同様に使用できます）。
• render-コンポーネントテンプレートの直接出力。
• onAfter-ウィジェットを実行した後のアクションの実行（component_epilog.phpのアナログ）。

ほとんどの場合、単にinitResultメソッドをオーバーライドし、コンポーネントテンプレートをスローします。



以下は、infoblock要素のリストを表示するコンポーネントクラス（class.php）の例です。 入力で、パラメーターの配列（$ params）を受け取ります。これは、データのフィルター処理と並べ替えに使用されます。

ルーター

ルーターのタスクは、ウィジェットを一緒に収集することです。 ルーター-ユーザー要求（REQUEST_URI）に基づいて、対応するアクションを呼び出すコントローラーです。 アクションは、情報を含むページ（ウィジェットを含む）か、何らかのロジックを含むことができます。



コンポーネント実行のデフォルトの順序：





順番に：

• init-初期データを初期化します。 入力パラメーター（$ arParams）をクラスプロパティに変換します。
• initUrlManager - UrlManagerをエイリアスで埋めます このアクションは、アクションによるルーティングとURLアドレスのさらなる生成を実行するために必要です。
• parseRequest -UrlManagerリクエストを解析し、ユーザーがリクエストしたアクションを決定します。
• existBeforeAction-個人のonBeforeハンドラーの存在を確認します。 「index」のアクションがあり、「onBeforeIndex」のメソッドがある場合、それが呼び出されます。それ以外の場合は、一般的な「onBefore」が呼び出されます。
• onBefore-アクションの可能性をチェックします。
• run-コンポーネントの直接実行の機能。 データ（$ arResult）で何をする必要があるかを決定します。
• existMethodAction-アクションハンドラーの存在を確認します。 アクション 'index'が要求され、メソッド 'actionIndex'がある場合、このメソッドが呼び出されます。そうでない場合、ルーターは 'index'という名前のビューを表示しようとします。
• onBeforeRender-テンプレート出力の可能性をチェックし、変換を実行します（アクション名はパラメーターで渡されるため、個人チェックを構成できます）。
• render-コンポーネントテンプレートの直接出力。
• onAfter-ウィジェットを実行した後のアクションの実行（component_epilog.phpのアナログ）。 「onBefore」メソッドでも同様に機能します。「index」アクションに「onAfterIndex」メソッドがある場合は呼び出され、それ以外の場合は汎用の「onAfter」が呼び出されます。

以下は、ディレクトリを実装するコンポーネントの例です。

• アイテムのリスト
• セクションのリスト
• 詳細なアイテムカード。

クラスの自動ロード

これは非常に必要なことであることはすでに明らかであるため、この問題についてはあまり話さないでしょう。



Juggernautによって実装されたとおり：



「lib」フォルダーでは、次の構造を確認する必要があります。クラスファイルの名前は、拡張子と上位名前空間を含まず、名前空間名と同じです。 たとえば、クラス「Iblock \ Property \ Table」は、ファイル「... / modules / Iblock / lib / Property / Table.php」に対応します。



「includeModule」を呼び出す必要がなくなりました 必要に応じて、すべてのクラスが必要なディレクトリから自動的にロードされます。

モジュールのディレクトリが名前空間の名前と異なる場合、またはその他の状況では、名前空間とディレクトリの対応を手動で設定できます。

 //  "Jugger\D7\Iblock"    "./lib/D7/Iblock.php" –      \Jugger\Psr\Psr4\Autoloader::addNamespace('Jugger', __DIR__.'/lib'); //  "Jugger\D7\Iblock"    "./classes/Iblock.php" \Jugger\Psr\Psr4\Autoloader::addNamespace('Jugger\D7', __DIR__.'/classes');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Bitrixにもオートロードがありますが、パスの形成方法が少し異なります。



クラス「Olof \ Catalog \ Tools \ File」は「/Olof.Catalog/lib/Tools/File.php」と翻訳されます。



クラス「Olof \ Catalog」が必要な場合は、すみません、手動でその存在を示します（以下を参照）。 モジュールディレクトリには、区切り文字「。」が必要です。それ以外の場合は、フォレスト内を歩きます。 ディレクトリ "olof.catalog.iblock"の内容-間違っています。



Bitrixの紳士は実際に通常のことをしました。彼らはモジュール名でベンダーを指定するのを面倒をみましたが、これはディレクトリに名前を付けるための余分な条件だと思います。



自動ロードは、接尾辞を削除して「element.php」ファイルに変換することにより、「ElementTable」タイプのクラスに暗黙的に応答します。 実際、このため、Tableというクラスを作成することはできません。



また、現在接続されていないモジュール（includeModule）からクラスをロードすることはできません。



Bitrixオプションの例を考えてみましょう。モジュール「olof.iblock」と対応するinclude.phpファイルがあります。

 namespace Olof\Iblock; use Bitrix\Main\Loader; //   Loader::includeModule("Olof.Iblock"); //      Api Loader::registerAutoLoadClasses("Olof.Iblock", [ "\Olof\Classes\Api" => ". /modules/Olof.Iblock/classes/api.php", ]); //    : // Olof\Iblock\Element -> ./modules/Olof.Iblock/lib/Element.php // Olof\Classes\Api -> ./modules/Olof.Iblock/classes/api.php // Olof\Classes\Help -> ./modules/Olof.Classes/lib/Help.php
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私の意見では、暗黙の事柄や条件が多すぎます。 そして、明日、Bitrixがどんな愚かさを思い付くのか誰も知らない。 そして、PSR-4のように、ネームスペースプレフィックスのディレクトリを示す必要があり、その後はクールになります。 それまでの間、ジャガーノートがいます;-)

アクティブレコード

エンティティ、特に情報ブロックを操作するために、ActiveRecordテンプレートが実装されています。 現時点では、ARはBitrix DataMappersに基づいており（実際にはアドオン）、将来的には完全に独立したORM / DAOに移行する予定です。



以下は、ARを介してインフォブロックを操作する例です。実際に現在利用可能なすべての方法がカバーされています。







メソッド： getPrimary 、 getRow 、 getRowByField 、 getList 、 getListByField-すべてのActiveRecordで同一です。



ARの機能は現在かなり貧弱です（たとえば、テーブルにクロスサーチはありません）が、それらは標準関数のラッパーであるため、getListおよびgetRowメソッドでBitrixバンを使用できます。 通常のDAOを作成/借用した後、この瞬間は完了します。

遺産

Bitrixの強みは、多くの人が同意すると思いますが、そのユーザーインターフェイス、つまりHermitageです。 非常に便利で柔軟です。



以下は、エルミタージュの使用例です。







非常に賞賛され、書かれていることはほとんどありません））実際、これはユーザーとの対話に十分です。 管理インターフェイスに関して多くの実装が必要ですが、これはもはやHermitageではなく、これはすべて計画に含まれています。

安全性

私がBitrixで知っている限り（そして、この問題でそれを隠しません、私は実際にそれを回避しませんでした）、それはサイトセキュリティ（コード内）で一般的に悲しいです（SI保護のみ）。 将来、このセクションには、さまざまな攻撃や悪意のあるアクション（XSS、ランダムデータ生成、さまざまな暗号化機能、フォーム検証、パスワードの操作など）から保護するためのツールが含まれます。 現時点では、CSRF保護ツールのみが実装されています。

 use Jugger\Security\Csrf; /* * ""  */ if (Csrf::validateTokenByPost()) { // ok } else { // error } echo Csrf::printInput(); /* * ""  */ $nameField = "csrf"; $token = Bitrix\Main\Context::getCurrent()->getRequest()->getPost($nameField); if (Csrf::validateToken($token)) { // ok } else { // error } $token = Csrf::createToken(); echo "<input type='hidden' name='{$nameField}' value='{$token}'>";
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各チェックの後（成功または失敗）-トークンはセッションから削除されるため、トークンは1回しかチェックできません。

Urlmanager

Bitrixへのルーティング、私は高度で、それゆえこのエリアはジャガーノートでも影響を受けているとは言いません。 このクラスを使用すると、URLルート（ルーターコンポーネントで使用）を動的に作成して使用できます。



URLの解析と生成の例を考えてみましょう。







将来的には、 urlRewrite.phpに接続することも計画されています 。

イベント

このクラスは、D7の機能の単なるラッパーであり、より便利に使用できます。

 use Jugger\Helper\Event; /* *   */ Event::on(" ", function(){ //  }); Event::on(" ", "\ClassName::MethodName", "moduleName"); /* *   */ Event::off(" "); Event::off(" ", 3); //  4-   ( )  /* *   */ Event::trigger(" "); /* *      () */ Event::trigger(" ", $this);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次は？

近い将来の計画：

• 通常のQueryBuilder
• 通常のキャッシング
• 通常のAssetsManager
• 管理インターフェースを作成および操作するためのコンポーネントのセット
• 通常のルーティング（HttpExceptionに関連付けられています）

おわりに

多くのことが計画されていますが、多くのことが行われていません。 ライブラリは必要に応じて開発されるため、現在の注文（多くの場合同じタイプ）と空き時間に大きく依存します。



冒頭で述べたように、プロジェクトはすべてにもかかわらず開発されます。開発の速度のみが、作成者と関係者の数に依存します。 したがって、選択はあなた次第です。

• 泣き言を言って、待って、Bitrixに調整します（そして、BitrixFrameworkの開発は明らかに優先事項ではありません）。
• すべてを自分の手に取り、ジャガーノートの開発を手伝ってください。

あなたが必要とするこのために、希望する慈善家は助けることができます（そうでなければ、方法はありません）：

• アイデアを共有する
• リファクタリング
• ペンで何かをする

このプロジェクトはGitHubにあるため、誰でも編集、追加、コメント、質問ができます。



ご清聴ありがとうございました！ 建設的な批判は大歓迎です:-)



PSは、「FIG Bitrixのはい」のような、書き込みをしないという巨大な要求をコメントしています。 私は人々がこのシステムで何をしなければならないかを知っています、そして、このプロジェクトはちょうどそれを改善することを目指しています。 したがって、「任意のフレームワークでプロジェクトを作成する方がより簡単で簡単だ」と思う場合、これを知っており、あなたにとって非常に満足しているので、あなた自身の意見を残してください。 よろしくお願いします！



リポジトリ： github.com/irpsv/juggernaut.bitrix_release

マーケットプレイス：近日公開