* .gwt.xmlを介したGWT順列の正確な制御

Question

GWT順列を正確に指定し、それらの中のバリエーションを制御する必要があります（それぞれがサポートするプロパティ値の組み合わせ）。

私の実験では、set-propertyの作成を監視する必要があることを知りました。これらのサイクルは安定していますが、サイクルのどの部分も変更しない"それを確認します。それは私が何ができるかを制限し、私は別の方法を試してみることにしました - （ちょうど）例えば、ブランドの新しいプロパティを定義します。

<define-property name="precise.permutation" values="webkit,gecko,ie,unsupported"/> 

を...そしてのようなものがあります。

<set-property name="precise.permutation" value="webkit"> 
    <!-- ... custom conditions ... --> 
    </set-property> 
    <set-property name="precise.permutation" value="gecko"> 
    <!-- ... custom conditions ... --> 
    </set-property> 
    <set-property name="precise.permutation" value="ie"> 
    <!-- ... custom conditions ... --> 
    </set> 
    <set-property name="precise.permutation" value="unsupported"> 
    <!-- ... custom conditions ... --> 
    </set-property> 

を

<set-property name="precise.permutation" value="webkit,gecko,ie" /> 

Iはまた、他の特性を崩壊しなければならなかった：それは上記と同じセットのプロパティタグを使用するよう...私はその後、例として使用され、サポートされていないが、すべてにこれを制限する試みたが、完全に反直感的ですそれらが追加の並べ替えを引き起こさないことを確認する。

残念ながら、それは意図したとおりに動作していないようです（GWT 2.8 RC2で試してみました）。 「サポートされていない」パーミュテーションが表示されない（これが望ましい）場合でも、それからのプロパティの組み合わせは他の順列に再現されます（これは望ましくありません）。

誰かが私に正式なを見つけさせて、これについてのドキュメントを完成させることができますか、それともどうすればいいですか？

ありがとうございます！

Answer 1

私はまだhave't詳細なドキュメントを見つけましたが、私は実験のトンを行っているし、次のように結論している...

（注意：私の例では、私が開発し煎茶GXTからいくつかの概念を使用します）

< define-property >は、プロパティとその可能な値を定義するために使用されますが、実際に使用される値の最後の単語ではありません。 * .gwt.xmlファイルの階層には、プロパティごとに1つのこのような定義が正確に存在する必要があります。

<セットプロパティ値にプロパティを設定するが、（理想的& ltdefine-性>で定義されているもののサブセットに）そのプロパティの可能な値の集合とルールの並べ替えを作成しません>。指定されたプロパティの最後の宣言が<のセットプロパティ>になります。注意してください！ <が>（モジュールを継承）を継承した後にセットプロパティーを使用すると、継承したルールを上書きすることができます。条件付きルールと無条件ルールがあることに注意してください。例えば、

<set-property name="gxt.user.agent" value="ie10, ie11, gecko1_9, safari5, chrome"/> 

は...無条件の順列を決定する際に、プロパティ「gxt.user.agent」はリストされた値のいずれかを持つことができる、と述べているだろう。逆に、

<set-property name="user.agent" value="safari"> 
    <any> 
    <when-property-is name="gxt.user.agent" value="safari5" /> 
    <when-property-is name="gxt.user.agent" value="chrome" /> 
    </any> 
</set-property> 

は「gxt.user.agentは」「safari5」または「クローム」のいずれかであるときuser.agentのみ「サファリ」できる状態だろう。順序は重要と思われるので、依存関係の規則の後に宣言された依存プロパティの規則が必要になります。サイクリック依存関係はコンパイルに失敗します。お互いに矛盾しない限り、多くの条件付きルールを作成できます。彼らがいたら何が起こるのかまだ分かりませんが、最後に宣言されたものが勝つと思います。

条件付きルールでは、複数の値を指定することもできます。例えば（イラストのみ、あなたのニーズと一致しない場合があります）：

<!-- On desktops we do all browsers including IE --> 
<set-property name="gxt.user.agent" value="safari5, chrome, gecko1_9, ie11"> 
    <when-property-is name="gxt.device" value="desktop" /> 
</set-property> 
<!-- ... but on tablets and phones we exclude IE --> 
<set-property name="gxt.user.agent" value="safari5, chrome, gecko1_9"> 
    <any> 
    <when-property-is name="gxt.device" value="tablet" /> 
    <when-property-is name="gxt.device" value="phone" /> 
    </any> 
</set-property> 

あなたは、複雑な/複合基準を作成するために、すべての> <任意の>と<を使用することができます。これらは相互にネストすることができます。

どのようにして順列の正確な制御を得ることができますか？あなたはこれを必要としないかもしれないが、それはこれらのような2つのプロパティを定義することによって開始するために私を助け：

<define-property name="custom.use.case" values="case1, case2, ..."/> 
<property-provider name="helix.product.mode"><![CDATA[ 
    var useCase = ...; // JavaScript code to determine the use case 
    return useCase; 
    ]]> 
</property-provider> 
<define-property name="custom.permutation" values="perm1, perm2, ..."/> 

最初のプロパティは、ユースケースを定義します。上記の私は実行時にそれを決定する方法があります。あなたはそれをスキップすることはできません。また、ユースケースに基づいて他のすべてのプロパティを定義できるので、他のすべてを定義するための出発点としても機能します。たとえば：

​​

：行うには

<!-- Case 1 restrictions --> 
<set-property name="gxt.device" value="desktop"> 
    <when-property-is name="custom.use.case" value="case1" /> 
</set-property> 
<set-property name="gxt.user.agent" value="chrome, safari5, gecko1_9, ie11"> 
    <when-property-is name="custom.use.case" value="case1" /> 
</set-property> 
... 

<!-- Case 2 restrictions --> 
<set-property name="gxt.device" value="tablet, phone"> 
    <when-property-is name="custom.use.case" value="case2" /> 
</set-property> 
<set-property name="gxt.user.agent" value="chrome, safari5, gecko1_9"> 
    <when-property-is name="custom.use.case" value="case2" /> 
</set-property> 
... 

<!-- Case 3 restrictions --> 
<set-property name="gxt.device" value="tablet, phone"> 
    <when-property-is name="custom.use.case" value="case3" /> 
</set-property> 
<set-property name="gxt.user.agent" value="safari5"> 
    <when-property-is name="custom.use.case" value="case3" /> 
</set-property> 
... 

etc. 

次の事は、我々は唯一の順列を駆動するcustom.permutationをしたいので、custom.permutationため除くすべてプロパティを折りたたむことですこの手法では、「順列」とその内部の複雑さを非常に細かく制御することができます。可能な "custom.permutation"プロパティ値ごとに正確に1つの順列があります。上記のルールを設定するのがうまくいく場合、各パーミュテーションは必要な「ソフトパーミュテーション」を持つだけです。

実際の順列とソフト順列の両方がコストになります。多くのソフトパーミュテーション（実際の順列にグループ化されているかどうかにかかわらず）は、それらがグループ化されている順列のパフォーマンスと実行時コードサイズをコンパイルします。特に、多くのプロパティがある場合は無視しないでください。実際の順列は、コンパイルとリンクの時間コストがさらに高くなります（ただし、多数のソフト順列をグループ化した実際の順列に組み合わせるのではなく、各順列のサイズが小さくなります）。

GXTを使用している場合は、バージョン4から、デスクトップ、タブレット、電話などの値を持つgxt.deviceプロパティが追加されています。これにより、GXT 4へのアップグレード後に約6〜7回のコンパイル時間が増加しました。なぜなら、順列が制御不能になったからです。 Mac OSのタブレット上で実行されているInternet Explorer用に作られたものもあります。あなたは、存在しないユースケースのための時間の無駄が何であるかを理解することができます。上記を実装することで、GWTのコンパイル時間を元の時間の約半分、またはGXT 4をアップグレードした直後の約10〜12倍に短縮することができました。