1

Flex / Flash Builder を何年も使用しています。Flash Builder の最新リリース (4.7) にはかなりの数の問題があるようですが、その最大のものは次のとおりです。

  • IDMXML でcomponent を検出しません。たとえば、コンポーネントの ID の使用箇所を見つけることはできません。コンポーネントの ID にカーソルを置いたままにしても、ID の出現はマークされません。代わりに、MXML 内の実際の単語の出現をマークします。id
  • 非常に遅い。

IntelliJ IDEA 12 への移行を真剣に検討しています。特に、多くの経験豊富な Flex 開発者が IntelliJ IDEA 12 について絶賛し、推奨しているのを読んだ後です。

私はそれを試してみました。IDE の新しい用語を理解するのにしばらく時間がかかりました (このドキュメントと JetBrains の非常に親切なサポート担当者によって簡単になりました)。

Adobe Flex 4.6 SDK を使用して IDEA で (大規模な) プロジェクトをセットアップし、正常にコンパイルすることができました。しかし、AS ファイルで強調表示されている多くの「エラー」に気付きましたが、これらはすべて実際には誤報です。

ActionScript エディターは、MXML で定義されたオブジェクトを認識していないようです。どうやら、これは IDEA の既知のバグです (追跡はこちら)。そして、このバグは 2 年以上存在していました。

JetBrains サポート担当者の引用:

クラスを含まないが、代わりにmxmlasに含まれる ActionScript ファイルの強調表示は<fx:Script source="some_file.as"/>、おそらく IntelliJ IDEA コードの強調表示の唯一の弱点であることを認めなければなりません。<fx:Script/>外部*.asファイルとして参照するのではなく、CDATA 内に AS コードを埋め込むと、誤ったエラーの強調表示がなくなります。これが常に望ましいとは限らないことは理解していますが。

残念ながら、リリースが非常に早く、修正はリスクが高すぎるため、修正は 12 リリースには含まれません。問題の優先度は、投票とユーザーからのフィードバックによって異なります。これまでのところ、2 票しかありません (http://youtrack.jetbrains.com/issue/IDEA-52598)。修正は非常に複雑であるため、これはまれな使用例であると考えて、まだ実装していません。12.x アップデート リリースの 1 つで修正したいと考えています。

私のプロジェクトは巨大なもので、巨大な MXML ファイルと、各 MXML 用のさらに巨大な AS コードがあります。したがって、整理するために、それらをより小さなファイルに論理的に分割する必要があります。したがって、AS コードを MXML とマージすることは実用的ではありません。誤ったエラーの強調表示は、コードの可読性を大幅に低下させます。また、AS コード内のコンポーネント ID をControl / Command キーを押しながらクリックしても、MXML 内のコンポーネントの定義にすばやく移動できません(ちなみに、これは FB 4.7 でも機能しなくなりましたが、FB 4.6 ではうまく機能しました)。

残念ながら、IDEA のこのバグは、私にとって大きな問題です。しかし、他の Flex 開発者がこの一見重大なバグをどのように克服/回避できるのか疑問に思っています。

特に IDEA を推奨する非常に多くの Flex開発者がいるにもかかわらず、このバグの影響を受けたのは 2 人だけというのは信じられないことです。多分私は何か間違ったことをしていますか？

Flex 開発者の皆様、ご意見をお待ちしております。

アップデート

これは、RIAStar の優れた詳細な回答に対する回答です。しかし、それは私を完全に助けるわけではありません。を使用する理由と方法を説明しましょう<fx:Script source>。Flex 4.x を使用しており、ほとんど Spark コンポーネントのみです。

  • まったく新しい Flex プロジェクトがあるとします。主なアプリケーションは MXML ファイルです。
  • この MXML ファイルに、サインアップ フォームがあるとします。
  • フォームを (各フィールドで) 編集するときに、検証を実行し、フォームが完全に有効な場合にのみ [送信] ボタンを有効にする必要があるとします。これは、変更イベント ハンドラをフォーム アイテムに割り当てる必要があることを意味します。イベント ハンドラは AS コードです。
  • サーバーを非同期的に呼び出すことにより、型の一意性チェックが必要なユーザー名フィールドがあるとします。サーバー通信コードもASコードです。
  • そしてもちろん、送信ボタン ハンドラーもあり、これも AS コードです。

私は通常、すべての AS コードを別々の.asファイルに入れ、.xml を使用して MXML に含めます<fx:Script source>。通常、この AS コードは非常に重く、多くの機能ロジックと動作ロジックが含まれています。多くの場合、ユーザーの操作に基づいて、MXML 内のコンポーネントや要素のレイアウトでさえ、この AS コードによって変更されます。

皆さんの理解が正しければ、このイベント ハンドラー コードは、これらの MXML スクリプト ファイルに含めるべきではありません。それで、それはどこにあるべきですか？皆さんはどのようにしますか？Spark Skinning アーキテクチャがこれにどのように関係しているかはわかりません。

4

2 に答える 2

14

これを穏やかに表現する方法が思い浮かばないので、率直に言います。残念ながら、これを重大なバグだと考える人が 2 人しかいないのは、経験豊富な Flex 開発者のほとんどが、Flex の使用<fx:Script source="some_file.as"/>は悪い習慣であることに同意するからです。 .
1 つのクラスを表す 2 つのファイルを効果的に作成します。あなたが心配しているように見える可読性のPOVから、それは良い動きではありません。これらのファイルの 1 つ (.as ファイル) は、それ自体では存在できない単なる関数の集まりです。それらは別のファイル/クラスと密接に結合されていますが、.as ファイルを見るだけでは、どのクラスかを知る方法はありません。に結合されています。もちろん、ある種の命名規則を使用してこれを回避することもできますが、最終的に ActionScript/Flex は、ミックスインや命名規則に依存するスクリプト言語ではなく、静的に型付けされた言語として使用されることになっています (誤解しないでください)。 : スクリプト言語が悪い習慣だと言っているのではありません; それは ActionScript がどのように考えられたかではないだけです)。

それで、あなたの選択肢は何ですか？
この構成の背後にある主な理由は、MXML を ActionScript コードから分離したい、またはより抽象的な言葉で言えば、ロジックからビューを分離したいからだと思います。幸いなことに、これは他のいくつかのよりクリーンな方法で実現できます。どのソリューションを利用できるかは、Flex 3 (またはそれ以前) か Flex 4 かによって異なります。コードを提案されたソリューションの 1 つにリファクタリングする時間がないかもしれないことは理解していますが、私はあなたを置き去りにしたくありませんでした。 「それは良い習慣ではありません」という答えだけで。

フレックス 3 (mx)

コード ビハインド:多くの開発者は、いわゆる「コード ビハインド」パターンを使用して、ロジックをビューから分離しました。"flex code behind" をグーグルで検索すると、このトピックに関する多くの情報を見つけることができます。ここですべてを繰り返す必要はありません。この概念は継承に大きく依存しており、結果として得られる 2 つのクラスは依然としてかなり緊密に結合されているため、私はこの概念のファンではありませんが、少なくとも 2 つのクラスについて話している. アーキテクチャを適切に設計すれば、基本クラスの一部を再利用できる場合もあります。

Compose model en controller:以前は、MXML ビューごとに個別の「プレゼンテーション モデル」クラスと「コントローラー」クラスを作成し、次のように使用していました。

<!--MyView.mxml-->
<mx:VBox>
    <m:MyModel id="model"/>
    <c:MyController model="{model}" view="{this}"/>
    ...
</mx:VBox>

MVC の純粋主義者はこれを好まないでしょうが、当時の Flex アプリケーションのコンテキストではうまく機能しました。
後でダイレクト インジェクションをサポートするフレームワーク (Parsley など) が登場したとき、この例のように直接接続するのではなく、インジェクションを使用してそれらすべてのクラスを接続することができました。

MVC フレームワーク:このトピックに関する私の知識はまばらです (私の意見では、Flex はサードパーティの追加を必要としない非常にまともな MVC フレームワークですが、それは別の議論です)。きれいな方法。

フレックス 4 (スパーク)

Flex 4 では、Spark スキニング アーキテクチャが導入されました。これにより、ビューとロジックをうまく分離できます。すべての動作コードを含むいわゆる「ホスト コンポーネント」クラスをプレーンな ActionScript で作成し、MXML でコンポーネントの視覚的表現を定義する「スキン」クラスを作成します。これにより、再利用可能なコンポーネントの設計が非常に簡単になります。

ご要望に応じて、Spark スキニングを使用してサインアップ フォームを作成する方法の簡単な例を次に示します。
分かりやすいのでスキンクラスから始めましょう。これは、いくつかの入力フィールドを持つ単なるフォームです。メタHostComponentデータは、スキンがサインアップ ホスト コンポーネントと連携して動作することを伝えます。

<!--SignUpSkin.mxml: the visual representation-->
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark">

    <fx:Metadata>
        [HostComponent("net.riastar.view.SignUp")]
    </fx:Metadata>

    <s:Form>
        <s:FormHeading label="Sign up"/>

        <s:FormItem label="User name">
            <s:TextInput id="userInput"/>
        </s:FormItem>

        <s:FormItem label="Password">
            <s:TextInput id="passwordInput" displayAsPassword="true"/>
        </s:FormItem>

        <s:Button id="submitButton" label="Submit" 
                  enabled="{hostComponent.canSave}"/>
    </s:Form>

</s:Skin>

そして、純粋な ActionScript のホスト コンポーネントになりました。SkinnableComponentスキンを使用できるように拡張する必要があります (SkinnableContainerこの質問で最近説明したものもあります: Flex mxml custom component - how to add uicomponents? ですが、ここでは必要ありません)。

public class SignUp extends SkinnableComponent {

    [SkinPart(required="true")]
    public var userInput:SkinnableTextBase;

    [SkinPart(required="true")]
    public var passwordInput:SkinnableTextBase;

    [SkinPart(required="true")]
    public var submitButton:IEventDispatcher;


    [Bindable]
    public var canSave:Boolean;


    override protected function partAdded(partName:String, instance:Object):void {
        super.partAdded(partName, instance);

        switch (instance) {
            case userInput:
                userInput.addEventListener(TextOperationEvent.CHANGE, 
                                           handleUserInputChange);
                break;
            case passwordInput:
                passwordInput.addEventListener(TextOperationEvent.CHANGE, 
                                               handlePasswordInputChange);
                break;
            case submitButton:
                submitButton.addEventListener(MouseEvent.CLICK, 
                                              handleSubmitButtonClick);
        }
    }

    private function handleUserInputChange(event:TextOperationEvent):void {
        validateUsername(userInput.text);
    }

    ...

}

ここで何が重要ですか？
としてマークされた変数SkinPartには、作成したばかりのスキンに存在する同じ ID を持つコンポーネントが自動的に割り当てられます。たとえば、<s:TextInput id="userInput"/>に注入されpublic var userInput:SkinnableTextBase;ます。タイプが異なることに注意してください:SkinnableTextBaseの基本クラスですTextInput。TextAreaこれにより、たとえば a の代わりに aを使用して別のスキンを作成できTextInput、ホスト コンポーネントに触れることなく機能します。
partAdded()SkinPart が表示リストに追加されるたびに呼び出されるため、ここでイベント リスナーを接続します。この例では、値が変更されるたびにユーザー名を検証しています。
検証が完了したら、canSaveプロパティをtrueまたはに設定するだけです。false. このプロパティのスキンのバインディングは、ボタンのenabledプロパティを自動的に更新します。

そして、これらのクラスの両方を一緒に使用するには:

<v:SignUp skinClass="net.riastar.skin.SignUpSkin"/>
于 2012-12-27T00:22:03.787 に答える
0

私は実際、RobotLegs を使うのがとても好きになりました。

私の MXML ビューでは、すべてのロジックを MXML の外部に保持し、単にイベントをメディエーターにディスパッチするようにしています。そこから、必要に応じてより重い AS へのコードをメディエーターに入れることができます。

于 2013-01-08T00:04:07.367 に答える