このプロジェクトの主な目標は、Webアプリケーション、データベース管理インターフェイス、CRMシステム、およびワークステーションを開発するための便利なRADプラットフォームを作成することです。 プラットフォームの機能は、日常的な開発プロセスを可能な限り自動化し、創造的な自己実現のためのスペースを解放します。
昨年、 「DVelum-PHP + ExtJS4 Development Platform」という出版物でDVelumプラットフォームを紹介しました。
その時点では、この出版物が多くの有用なヒントとレビューを受け取った後、プラットフォームはかなり粗雑でした（ベータリリース）。 提案されたものの多くが実装され修正されました。この間に行われたことを紹介したいと思います。 プロジェクトはより強力になり、より調和のとれた外観を獲得し、日常の開発に十分なツールセットが含まれました。
変更および新機能の詳細なリストは、プロジェクトのWebサイトhttp://dvelum.ru/timeline.htmlにあります。
興味深い重要なイノベーション
プラットフォームのパフォーマンスが大幅に向上しました。 辞書、構成、ローカリゼーションの「遅延」ロードが導入されました。 最適化および再設計されたシステムアーキテクチャ。 多くのサードパーティコンポーネントは、独自の軽量な実装に置き換えられています。 エラーメッセージの情報内容の改善、追加のログ。
オートローダー
Autoloaderクラスは、PSR-0標準と互換性があります。
インターフェイスデザイナーの更新
プラットフォームの基本的な部分であるインターフェイスデザイナーは、大幅な変更と改善を受けています。
イベントのサポートが追加され、ハンドラーを割り当てる機能が実装され、受信したパラメーターのリストとタイプが強調表示されます。
ネストされたプロジェクトを接続する機能を実装しました。 したがって、インターフェイスデザイナーでは、他のプロジェクトに含める独自のコンポーネントを作成できます。
プロパティを埋めるための既製のコンポーネントと補助インターフェースのリストが拡張されます。次に例を示します。
- アイコンセレクター
- 関連アイテムグリッド（オブジェクトのリストへのリンクを編集するためのコンポーネント）
- フィールドオブジェクト参照用のコンポーネント
- オブジェクトのリストへのフィールドリンクのコンポーネント
 |  |  |  |
Tree.Panel、ストレージフィルターなど。
AJAXリクエストURLパターン
既製のソリューションの移植性を向上させるために、AJAXリクエストURLテンプレートが導入されました;現在、インターフェイスは特定のファイル構造、管理パネルアドレス、添付ファイルの深さ、またはローカライズに関連付けられていません。
コードジェネレーターの改善
コード自動生成機能が改善され、オブジェクトへのリンク、オブジェクトのリスト、ライブラリ項目など、オブジェクトのすべてのプロパティのエディターが自動的に生成されるようになりました。 レコードの編集に必要なものはすべて自動的に作成されます（インターフェイスプロジェクト、コントローラー、javascript）。 これにより、作業が大幅に簡素化され、エントリのしきい値が下がります。
CSRF攻撃からの保護
CSRF攻撃から管理パネルを保護するための自動化されたシステムが統合されています。これは、ExtJSのインターフェイスを持つプロジェクトにとって非常に重要です。 現在、この種の脆弱性について考え、フォームに非表示のトークンフィールドを追加する必要はありません;システムはトークンと必要なAjaxリクエストヘッダーを個別に作成します。
ORMとモデルの改善。
外部キーを使用して、個々のORMオブジェクトをさまざまなリモートデータベースに接続できるようになりました。 システムはストリクトモードで安定して動作し、可能であればトランザクションを使用します。
編集コンポーネントが統合されたORMデータエディターが追加されました（開発モード）。 これで、インターフェイスの作成を開始する前に、データベースにテストデータを入力できます。 いつでも、ORMオブジェクトのプロパティの値を簡単に表示および調整できます。
 |  |
開発者の生活を簡素化する多くの追加の詳細
プラグイン
フレームワークに基づいた開発の問題の1つは、既製のモジュールの配布です。 ライブラリクラスをコピーして簡単に転送できる場合、有限機能のファイルはファイルシステム全体で「ぼやけ」ていることがよくあります（コントローラー、テンプレート、モデルなどは異なるフォルダーに散在しています）。
プラットフォームにプラグインメカニズムが含まれるようになりました。これにより、サードパーティのソリューションを別のフォルダーに保存できますが、アプリケーションのメインディレクトリにあるファイルを操作できます（まだ実験的です）。
個別のインターフェイスを使用すると、モジュールを接続/切断できます（後でダウンロード、インストール/アンインストール、アプリケーションディレクトリすることができます）。 サードパーティモジュールへのアクセス権は透過的に配布されます。 クラスファイル、設定、インターフェイスデザイナープロジェクトは、システムの「ネイティブ」になります（これらはスタートアップに追加され、さまざまなシステムリストに表示され、ルーティングに使用できます）。
新しいHTML5マルチローダー
Uploadifyのフラッシュマルチローダーを放棄して、html5 + jsに基づく独自のソリューションを採用しました。サーバーにファイルを送信する前に画像のプレビューを利用できるようになりました。ブートローダーAPIはより柔軟です。
質問-私たちは答えます
- なぜPSR-1,2コーディングスタイルを使用しないのですか？
最初は、PSR-1,2勧告よりもずっと前に登場したZend Framework 1.xスタイルに準拠しようとしました。 コードベースは非常に広範囲に及ぶため、一般的なコード形式を使用していると言うだけでは、一度に新しいスタイルに書き換える方法はありません（これは、空き時間があるときに将来のバージョンで行われる可能性が高いです）。
- DIは使用されていますか？
多くのハードコード部分は、依存関係注入（セッター経由）を使用して書き換えられます。 依存性注入のコンテナーは、大量のコードを処理する複雑さのために使用されません。コンテナーの使用は、パフォーマンスの損失につながり、コードジェネレーターとインターフェイスデザイナーのロジックを複雑にすることが避けられないため、この段階では実装しないことに決定しました。 （たとえば、DIコンテナーがないからといって、YIIが悪い判断になることはありません）
- なぜ名前空間がないのですか？
名前空間はプラットフォームのコアでは使用されませんが、最終的なソリューションに適用できます。 カーネルに名前空間を埋め込むと、既製のアプリケーションの互換性に必然的に悪影響が及びます。 おそらく、それらは後で、おそらく既製のアプリケーションとの互換性を維持するためのスペア/代替モードで導入されます。
- アレイ内の構成？
誰かは、PHP配列は構成を保存するのに悪いトーンであると言うかもしれませんし、このトピックに関する興味深い記事へのリンクさえ提供します。 はい、おそらくそうです。 私たちのシステムはphp配列に基づいた構成ファイルを使用しますが、それらの大部分はビジュアルインターフェイスを使用して編集されるため、この事実はあまり混乱しないはずです。 これを最善としてではなく、特定の問題に対する最適な解決策として扱う価値があります。 テスト結果によると、opcodeキャッシュを使用したプラットフォーム構成ファイルのキャッシュは、memcachedストレージよりもはるかに効率的であることが判明しました。 さらに、作業に慣れている形式で追加の構成を使用できます。
- APIドキュメント
APIドキュメントはプラットフォームコードを完全にはカバーしていませんが、一方で、さまざまな機能の例と頻繁に発生するタスクのソリューションを使用して、ほとんどの可能性を説明しようとしました。 ドキュメントのセクションを可能な限り補充および翻訳します。
- DocumentRootの要件はなぜですか？
この要件は、インターフェイスデザイナーの実装機能に関連しています。
一部のユーザーにとって、これは問題です。 現在、AJAXリクエストのURLパターンの出現により、サブディレクトリにインストールする機能を導入するために必要なベースを実装しました（おそらくすぐに実装されるでしょう）。
- DocumentRootのプラットフォームファイルが選ばれる理由
プラットフォームのファイル構造の一部は、ホストの外部に簡単に移動できます。そのためには、構成ファイルのパスを修正する必要があります。 このような「デフォルト」のファイル配置により、初心者の生活が簡素化され、プラットフォームを初めて知った人に必要なジェスチャの数が減ります。
- Composerはサポートされていますか？
サポートを実装することは素晴らしいことですが、今のところ考えられません。
- GITプロジェクトリポジトリはありますか？
計画中です。
- 他のDBMSのネイティブサポートはありますか？
プラットフォームのカーネルにはMySQLが必要ですが、これはアプリケーションから他のDBMSへの接続を使用することを妨げるものではありません。また、個々のモデルを他のアダプターに手動で切り替えることも可能です（おそらく、将来的にはカーネルレベルで他のDBMSがサポートされるでしょう）。
このプラットフォームは理想とはほど遠いですが、自由時間のほとんどを改善するために費やし、そのようなプログラミングではなく、ビジネスでプログラミングしようとします。
比較性能試験
伝統に従い、システムパフォーマンステストを紹介します。
システムのパフォーマンスを少なくともある程度把握できる、より深刻なテスト：「ブログ」、「ポータルホーム」、「ネストされたコメントのリスト」（ツリー構造の300要素）：
プラットフォームの開発とテストに参加したすべての人、およびフォーラムでのディスカッションの参加者に感謝します-彼らのサポートと関心。
私たちは建設的な批判を受け入れ、提案や提案を聞いて喜んでいます。 このプラットフォームがあなたにとって興味深く有用なソリューションになることを願っています。
プロジェクトチーム
