PHPとExtJSの組み込みインターフェイスデザイナーを使用してIDEを記述しています

この記事では、ExtJSとPHPを使用してIDEとインターフェイスデザイナーを作成する概念について説明します。 一方では、そのようなエディターの作成はかなりまれなタスクですが、他方では、概念や手法を使用してさまざまなビジュアルコンフィギュレーターを作成できます。









組み込みのインターフェイスデザイナーを使用してIDEを記述する方法、最小限の労力で迅速に行う方法 このような質問は、ExtJSとPHPの束を使用したプロジェクトで一度発生しました。 土壇場の用語、成長するタスクのライン。 タスクのリストには、膨大な数の入力フォーム、テーブル、レポートが毎日補充されます。これらはすべて、ユーザーに対して処理、フィルタリング、表示する必要があります。



このプロジェクトではORMを使用しました。これは、類似のインターフェイスを自動的に生成する可能性を明確に示唆しましたが、多くの類似点があるため、各フォームとレポートは一意であり、迅速で簡単な構成が必要でした。



簡単な検索で、Ext Designer（Sencha Architect）-興味深い便利なツールが明らかになりました（Ext MVCはまだ存在していませんでした）。 Ext Designerはタスクを解決するのに役立ちませんでしたが、すべてを詳細に説明しました。



同時に、PHP-Extプロジェクトに注目しました。PHPで記述されたExtJSの興味深いラッパーです。 この無限のインターフェイスストリームを生成するために使用できますが、もっと欲しいのは、Ext DesignerとExtJS上のPHPラッパーの混合物です。これにより、データベースを「覗き」、テーブルに基づいてフォームを構築することができます。 さらに良いのは、ORMオブジェクトの構造に基づいています。フィールドの名前、タイプ、バリデーターがすべてあるためです。



そのようなツールの検索は成功しませんでした。











IDEの構成：

コンポーネントコードを生成する方法を「知っている」ExtJSの1つのラッパー。

2 ExtJSラッパー要素を追加するシンプルなAPIを含むプロジェクトファイル。

要素を配置し、結果をキャッシュする3つのコードコレクター。

プロジェクト設定を簡素化する4つのインターフェイスデザイナー、コードエディター;

日常的なタスクを自動化するための既製のコンポーネント形式の5つの「グッズ」：

5.1初心者向けのExtJの継承の非自明な機能。

5.2エディターの再定義。

5.3 2回のクリックでAjaxリクエストのURLを生成します。

5.4データベースからの構造のインポート、フォームの自動作成。

5.5外部ファイルとプロジェクトの接続。

5.6インターフェイスのローカライズ。

5.7イベントおよびメソッドのエディター。

6フロントエンドのリクエストをチームAPIに変換するバックエンドデザイナーは、プロジェクトで作業します。

8プロジェクトジェネレーター。

1ラップ

このタスクでは、アイデアのニーズに合わせてExtJSの独自のラッパーを作成する必要があります。 ライブラリのボリュームは十分に大きいため、ライブラリコンポーネントのプロパティセットを動作の説明から分離することで時間を節約します。 すべてのExtJsオブジェクトがPHPコードでミラーリングされるわけではありません。 グリッド、ストア、ウィンドウなど、限られた数のオブジェクトのクラスについて説明します。 他のすべてのオブジェクトは、コード内に物理的に存在することはできませんが、階層で記述された一連のプロパティに基づいて作成されます。



したがって、数日でExtJSコンポーネントのプロパティの階層が再作成され、同時にバージョン3（数十個のクラス）が作成されました。 その後、必要に応じて、必要なコンポーネントの動作を記述することができました。主要なコンポーネントはjson-configレベルで生成されました。



次の形式の階層を取得します（グラフの一部、Zend_Framework 1の倍数）：











Ext_Objectとその子孫は、コンポーネントの動作を担当します。

Ext_Configは、プロパティの保存、検証、シリアル化を行います。

Ext_Propertyとその子孫は、特定のExtJSコンポーネント（パブリックプロパティを持つクラス、ExtJsライブラリの階層をある程度繰り返す）の特性を記述する責任があります。

Ext_Virtualはクラスです。 コンポーネントの動作を記述するExt_Objectの直接の子孫がない場合、このクラスのオブジェクトはファクトリによって作成されます。 Ext_Property_xxxプロパティの説明に基づいて作成されます。 ライブラリコンポーネントに対して表す名前を使用して、エミュレーションのためにクラスの名前を受け入れるという点で異なります。



Ext_Objectは__toStringメソッドを実装し、コンポーネントのExtJSコードを返します。 必要に応じて、このメソッドは相続人でオーバーライドできます。 オブジェクトが互いに入れ子になっている場合、ルートオブジェクトの文字列にルートする瞬間に、チェーン全体が簡単に解凍されます（Jsコードの文字列になります）。



実践が示しているように、このソリューションは頭痛を回避しました。

2プロジェクトファイル

ExtJSのインターフェイスは、チェーンに配置され、レイアウトにあるコンポーネントで構成されます。



プロジェクトコンポーネントの接続設定を何らかの方法で保存する必要があります。 XMLまたは他の同様の形式を構成ファイルとして使用できます。

この場合、プロジェクトをロードするたびに、構成を分析し、オブジェクトを初期化する必要があります。これには時間がかかる場合があります。 シンプル、高速、簡単なフォーマットが必要です。

プロジェクト自体を表すDesigner_Projectクラスを宣言し、要素を追加するための単純なAPIを持ち、要素自体をツリー構造に格納するとします（内部にはツリー構造で動作するオブジェクトがあります）。

当時、 Treeクラスはすでに記述されていました。これは、ツリー構造で非常に迅速に機能し、最大25,000〜30,000のネストされた要素の階層を1秒未満で簡単に管理しました。



このようなプロジェクトのオブジェクトは、シリアル化してディスクに保存できます。 さらに、シリアル化された文字列から、変更があった場合にのみハッシュを取得してインターフェイスコードを再構築できます。 インターフェイスを再初期化すると、検証のためにプロジェクトをロードせずにファイルキャッシュを使用できます。



当時のExt Designerの主な問題は、コードを変更するたびに、アプリケーションを再構築し、スクリプトを公開する必要があることでした。



構造Designer_Project（プロジェクトファイル）：

-コンテナのシステム記述（移動可能なクラス、ネストされた要素などを含むことができる）。

-現在のプロジェクトの設定（名前、名前空間、接続されたファイルなど）;

-API（プロジェクトを操作するための一連のメソッド）;

-ツリー（要素のツリー、プロジェクト構造）。



コンポーネントクラスが拡張され、プロパティのリストが増加する可能性があることは注目に値します。 ほとんどすべての場合、これは古い形式との互換性の問題を引き起こしません。



そのため、プロジェクトファイルが表示されました。 その過程で、Designer_Storageアダプターなど、いくつかの補助クラスが作成されました（プロジェクトをファイルに保存するという考えが突然変わりました）。 いくつかのパフォーマンステストが実施され、結果は楽観的で、アイデアはうまく機能しました。 プロジェクトツリーは要素の入れ子の構造のみを知っているが、オブジェクト自体は実際にはお互いに存在しないことに注意することが重要です。 デザイナー/ Project.php

3コードコレクター

Designer_Projectクラスは単純なAPIを備えたコンテナであり、その内容をどう処理するかまったくわからないため、目的のシーケンスで要素のコードを正しく配置できる補助メカニズムが必要です-これはDesigner_Project_Codeクラスです。 おそらく、さまざまな条件とブランチの数の点で最も複雑なコンポーネントです。 入力としてプロジェクトオブジェクトを受け取ると、インターフェイスのJSコードを返す必要があります。 プロジェクトツリーを再帰的に通過して、コンポーネントコードを受け取り、目的の順序で要素を配置します。 ExtJSのラッパーがコンポーネントコードを直接発行し、コレクター自身がこのコードを正しい順序で配置することに注意することが重要です。 最初に宣言するコンポーネントを決定し、コードを取得して、依存コンポーネントにリンクを挿入する必要があります。



コードは非常に複雑でわかりにくく、何度もリファクタリングされ、新機能の登場によりさらに複雑になりました。











時間が経つにつれて、彼は寛容な外観と構造を獲得しました。 デザイナー/プロジェクト/ Code.php



コアExtJSコンポーネントの拡張であるJSオブジェクトの場合、入れ子になった要素のレイアウトを簡素化するためにトリックが使用されました。 childObjectsプロパティが作成されました。これは、ネストされたすべての要素のリストであるため、アイテム内の要素へのアクセスとリンクは非常に簡単です。



プロジェクト構造の再帰的走査におけるDesigner_Project_Codeの動作原理、関連コンポーネントの検索、および相互に関連する有限要素のコードの正しい位置。



ポール完了。 PHP-EXTラッパーの単純化された類似物が作成されており、プロジェクトに組み込むことができ、はるかに高速に動作します。 機能は限られていますが、誰もそれを開発することを気にしません。

4デザイナー

最も興味深いのは、インターフェイスデザイナーを作成するときです。 概念的には、次のようになります。

-プロジェクトに配置できるコンポーネント（ボタン、フォーム、ウィンドウ、パネル）のリストが配置されるツールバーのあるパネル。

-プロジェクトのレンダリングの結果を表示するメインフォーム。

-コンポーネント階層（TreePanelを使用）;

-プロパティエディター（プロパティグリッド）。



現時点では、デザイナーの外観は次のとおりです（最初のものとは大きく異なります）。







1.プロジェクト設定パネル（ロード、保存、デザイナー/コードエディターモードの切り替えなど）;

2.プロジェクトに追加できるコンポーネントのリストを含むツールバー。

3.プロジェクト構造を表示するパネルは、要素のドラッグアンドドロップ移動をサポートし、要素を選択すると、個々のプロパティ設定パネルがロードされます。

4.コンポーネントのプロパティを設定するためのパネル（イベントとメソッドを編集するための追加のパネルが含まれています）。

5.中央のパネル（このスクリーンショットでは、プロジェクトのレンダリングの結果を表示します-ローカライズエディター）。 プロジェクトがロードされると、サーバーはそのオブジェクトのコピーをセッションに保存し、すべての操作を実行します。 したがって、インターフェースが落ちた場合、ウィンドウをリロードでき、変更は失われません。 [保存]ボタンをクリックすると、プロジェクトがディスクにフラッシュされます。



変更を行った後、インターフェイスはサーバーに要求を送信し、目的のコントローラーが要求を受け入れ、Designer_Projectに変更を加えます。 変更を正常に適用した後、デザイナーはJSの再構築を要求します。



プロジェクト内の要素の配置を担当するデザイナーのメインパネルは、ドラッグアンドドロップをサポートするツリーです。











ツリーはサーバーに要素のリストを要求し、サーバーはAPIを使用してプロジェクトから構造を抽出します。 要素をドラッグしている間、どのコンポーネントを移動するかという指示とともにリクエストがサーバーに送信されます。 Designer_Project APIには、ツリー内のアイテムを移動するためのメソッドが含まれています。 ツリーノードをクリック（目的のオブジェクトを選択）すると、itemSelectedイベントがトリガーされ、このコンポーネントのプロパティパネルが表示されます。



エディターコンポーネントの相互作用はイベントレベルで発生し、個々のパーツやコンポーネントは、外部にあるものを把握していないことがよくあります。 各要素には、親コンポーネントが通常サブスクライブする定義済みの生成済みイベントセットがあります。



プロパティグリッドの拡張コンポーネントはプロパティエディターとして使用され、サーバーとの通信方法によって補完されました（フィールドのリストを要求し、プロパティの変更を送信し、イベントをトリガーします）。



私たちの場合、このコンポーネントはdesigner.properties.Panelと呼ばれていました











1つのプロパティパネルが不可欠です;場合によっては、エディターとウィンドウであるプロパティを追加で構成する機能が必要です。 このタイプのオブジェクトの設定リストを展開する必要がある場合は、 デザイナーが割り当てられ、 designer.properties.Panelから継承されます。



デザイナーの初期機能ではすべての問題を解決できなかったため、「actionJs」ファイルがプロジェクトに添付されました（JavaScriptコードを含むファイルは、標準ツールでは実行できないものに使用され、JSプロジェクトの後に接続されます）。



Codemirror.netは 、コードエディターとして使用されます。



デザイナーの最初のバージョンでは、インターフェイスを簡単かつ迅速に構築できましたが、他のすべては開発者の負担になりました。 それ以降のバージョンでは、デザイナーにイベントが表示され、オブジェクトを展開したり、メソッドを追加したりできます。



結果を表示する方法は？ 開いているページのDOMでプロジェクトを直接レンダリングできます。非常に高速で、ツリーを介して要素をスローした後、再構築の遅れはほとんど見えません。 このソリューションには重大な問題が1つあります。開発中のプロジェクトで問題が発生した場合（プロパティが正しく設定されていないなど）、JSエラーによりデザイナー全体がクラッシュします。 開発したインターフェースをiframeに転送する方が良いですが、応答は遅くなりますが、プロジェクトコードの崩壊はグローバルな崩壊にはつながりません。 iframe自体を中央パネルに配置し、必要に応じてコンテンツの更新をリクエストできます。



すべての「大人」のデザイナーのように、要素をフォームに投げて、開発中のプロジェクト内で直接移動/移動できると便利ですが、単純な理由でこの質問は解決できません。 私はしばらくこのベンチャーを放棄しなければならなかった、締め切りが尽きていました。

その後、デザイナーのメインインターフェイスとプロジェクト自体の相互作用のメカニズムが登場しました。 移動、テーブルの列の拡大、ウィンドウのサイズ変更ができます。これはすべて保存されます。 操作の原理は非常に単純です。イベントハンドラーは、開発モードで開発中のインターフェイスに追加され、デザイナーのチームを形成し、デザイナーのコントローラーとの対話を支援します。デザイナーの外部インターフェイスはコマンドを予期し、表示されたときに反応します たとえば、テーブルの列を移動すると、リクエストがサーバーサイドAPIに送信され、メインのデザイナーインターフェイスに通知されます。

既製のコンポーネントの形の5個のパン、日常的なタスクの自動化

5.1初心者向けのExtJの継承の非自明な機能。

コンポーネントのファイナライズのトピックに触れる前に、初心者には明らかではない継承機能に注目したいと思います。

Ext.define('mypanel',{ extend:'Ext.Panel', someProperty:{ a:1,b:2,c:3 }, someProperty2:[1,2,3] }); Ext.define('mypanel2',{ extend:'mypanel' }); var a = Ext.create('mypanel'); var b = Ext.create('mypanel2'); b.someProperty.a = 100; b.someProperty2.push(100); console.log(a.someProperty); console.log(b.someProperty); console.log(a.someProperty2); console.log(b.someProperty2);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクト{a = 100、b = 2、c = 3}

オブジェクト{a = 100、b = 2、c = 3}

[1、2、3、100]

[1、2、3、100]



これらの機能は、次のように覚えておくことが重要です。 それはあなたの多くの神経を救います。 これが唯一の落とし穴ではありません。注意してください。

5.2エディター

基本的なプロパティのエディターを再定義します。たとえば、テキストフィールドのストアエディターを、プロジェクトで作成されたすべてのストレージのドロップダウンリスト（サーバーから要求され、Designer_Project APIが指定されます）、および他の同様のプロパティ（レイアウト、位置合わせなど）に置き換えます。

5.3 2回のクリックでAjaxリクエストのURLを生成する

システムのURLは動的です。たとえば、パネルのアドレスが変わると、コントローラーが切り替わります。 これを行うために、コードアセンブリの段階で処理される実際のパスを置き換えるトークンが発明されました。



URL（ajaxリクエスト、プロキシURL）の割り当てを簡素化するために、ファイルとコード構造を分析するコンポーネントが記述されています。 Reflectionを使用すると、コントローラで使用可能なアクションのリストを取得および分析できます。マウスで突くだけで、手で書く必要がなくなりました。



仕組み：ファイルシステムがスキャンされ、目的のクラスが選択され、メソッドのリストが要求され、メソッドのコメントがインターフェイスの説明として使用されます。 目的のURLは、プロパティとしてテンプレートとして自動的に登録されます。





同様の方法を使用してアイコンを割り当てることができます。

5.4データベースからの構造のインポート、フォームの自動作成

プログラマにとって生活を楽にする他の方法は？ もちろん、データベースまたはORMの構造に基づいて、フォーム、ストレージ、テーブルにフィールドをインポートします。



フィールドをインポートするテーブル/オブジェクトを選択します。 システムはその構造とデータ型に基づいて、セル内の必要な値を自動的に置き換え、フォームの階層を埋めます。







例えば、Ext.form.field.Numberはintに、Ext.form.field.Textはvarcharに使用されます。

途中で、フィールドフィールドまたは日付形式の場合、フィールドフィールドおよびその他のプロパティの場合、fieldLabelが追加されます。



要素を記述するための退屈な手順は、数回クリックするだけです。

5.5外部ファイルとプロジェクトの接続

外部のJSファイルや他のプロジェクトをプロジェクトに接続する機会を与えてはどうですか。 特定のコンポーネント（エディター）を記述するプロジェクトを作成できます。後で、必要な場所に接続します。 主なことは、プロジェクトネームスペースを分離して、コードジェネレーターが各プロジェクトを独自のネームスペースに配置することです。これはそれほど難しくありません。











必要なのは、ファイルとプロジェクトのリストをDesigner_Project apiに追加し、名前空間を割り当てるためのサポートを追加することだけでした。 Designer_Project_Codeは、名前空間内のコードを分解し、プロジェクトを再帰的にレンダリングするために、数時間でトレーニングされました。



次第に、デザイナーは、編集ウィンドウ、フィルター、オブジェクトへのリンクのフィールド、オブジェクトのリストなど、既成のコンポーネントを補充し始めました。

5.6インターフェイスのローカライズ

長い間、インターフェイスをローカライズするタスクは未解決のままでした。 彼女の決定にどのようにアプローチするかは明確ではありませんでした。 プロジェクト全体はシンプルなソリューションに基づいて構築されたので、私は庭をフェンスで囲みたくはありませんでしたし、時間もあまりありませんでした。 ある時点で発見されました。

プラットフォーム自体はローカライズファイルを使用しました。これらのファイルは、ローカリゼーション管理インターフェイスの変更時に再生成されました。 その結果、ページ上にフォームの特定のJSオブジェクトがありました。

 appLang = { yes:””, no:””, cancel: '', ... };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アイデアは単純です-開発者が文字列プロパティの値としてJs-codeを入力できるようにするため。これを行うために、トークン「[js：]」が発明されました（コード生成中、そのようなトークンを持つプロパティはjs-codeとして発行されました）。



それは：



それが可能になりました：



ローカリゼーション管理インターフェースの準備がすでに整っていることを考えると、それを使用できることは喜びでした。 ソリューションの実装は、その強さで20分かかりました。 これで、ファイルの内容を変更せずにプロジェクトをローカライズできます。

5.7イベントおよびメソッドエディター

次のブレークスルーは、オブジェクトを展開する機能の追加でしたが、メソッドとイベントを追加できるようになりました。 イベントの実装は、プロパティの実装に非常に似ています。 同様に、メソッドが実装されました。 この時点で、システムはExtラッパーに記述されている標準イベントとユーザーが作成したイベントに分割されているように見えました（メソッドは「拡張」（isExtended属性）オブジェクトのユーザーのみが作成できます）。







設計者は、明確で読みやすいコードの波を生成し始めました。



この後、イベント、メソッド、リアクションが要素全体に散らばっており、それらを編集する場所を見つけるのが難しいという明らかな問題が現れます。 オブジェクトごとにグループ化されたイベントとメソッドのリストを持つ個別のタブをデザイナーに追加します。 Designer_Projectにオブジェクトのリストを要求し、グループ化されたグリッドの形式でそれらを表示します。

6バックエンド

バックエンドの観点からは、すべてが非常に単純であり、任意のフレームワークを使用できます。 プロジェクトを操作するためのコントローラーとアクションのセットが必要です。 アプリケーションを起動し、デザイナーのプロジェクトを読み込み、Designer_Project APIにアクセスするメソッドのリストを記述し、プロジェクトでさまざまな操作を実行します。 機能のうち、組み立てられたプロジェクトをインターフェイスに出力し、必要なJSファイルを接続できるコントローラーが必要です。



また、このケースでは、デザイナー自身のソースコードをビルドおよび縮小するアクションが作成されました。これにより、エディターの読み込みを高速化することができました。

7プロジェクトジェネレーター

ジェネレーターは、プロジェクトファイルに対する一連のアクションを含むテンプレートです。



簡略化された形式：

 //    $project = new Designer_Project(); //    Ext_Panel    Ext.panel.Panel $panel = Ext_Factory::object('Panel',array( 'width'=>100, 'height'=>200, 'title'=>'My Panel', 'layout'=>'fit' )); //    $panel->setName('myPanel'); //     $project->addObject(0, $panel); //   $designerStorage = Designer_Factory::getStorage($config); //   $designerStorage->save($projectFile , $project);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

同様のプロジェクト構造を持つことで、ORMベースのプロジェクトジェネレーターを作成することは難しくありませんでした。 日中、標準インターフェースを生成するためのいくつかのテンプレートが作成されました。標準インターフェースを作成するのに数回クリックするだけで、残りの時間はカスタム設計と改良に費やされました。



デザイナーの最初のバージョンの実装には3週間の休暇が必要でした。これは、このようなグローバルな目標を達成するためのかなり短い期間でした。

受け取った利益：

-標準インターフェースはワンクリックで生成され、デザイナーでさらに開発されました。

-JSコードのエラー数を大幅に削減しました。

-若い開発者はExtJSと複雑なプロジェクトの開発を掘り下げます。

-インターフェースの変更がはるかに簡単で面白くなり、要素をマウスを1回動かすだけで移動できます。コードの一部を取得して別の要素との接続を忘れる心配はありません。

-製品およびプロトタイプの開発速度が向上しました。

-ボタンまたは列の名前を変更するなど、目的の項目を初期化してコードを検索するときに問題が発生しなくなりました。

-「ひざの上で」独自の開発環境を開発することで、興味深い経験が得られました。

-PHP開発は、まったく新しい便利な形式を獲得しました。

-ExtJSの多くの複雑さを学ぶことができましたが、今まで対処する必要はありませんでした。

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

ExtJSで長年作業してきた私は、同じことを書くのにうんざりしています。 コンポーネントを初期化し、構成します。コンマをスキップしたり、何かをリンクしたりすることを恐れます。 判明したように、このタスクは簡単に自動化され、空き時間にもっと面白いことができます。



このツールは非常に有用であることが判明したため、OpenSourceに貢献するために、コミュニティと共有したいという要望がありました。 設計者およびその他のいくつかの開発が再設計され、1つのDVelumプラットフォームに組み込まれました。その開発は数年間継続されています。 結果は公式サイトdvelum.netで見つけることができます