ダイアログ変換ツールは、ExtJS に基づくクラシック UI 用のダイアログが 1 つしか定義されていない既存のコンポーネントを拡張する場合に役立ちます。このツールでは、元のダイアログを使用して、Granite UI／CoralUI に基づくタッチ操作向け UI 用の複製のダイアログを作成します。
このツールの目的は、アップグレードを（できる限り）自動化して効率を高め、エラーを削減することです。
警告：
変換結果を検証してください。場合によっては追加の調整が必要です。このツールはあらゆるシナリオに対応できるわけではありません。これは、変換ルールが包括的なものではなく、ベストエフォート型であるためです。このツールは、大部分のダイアログを変換することによって変換を促進するための補助用ツールです。
このツールは最も頻繁に使用される要素およびプロパティを変換しますが、カスタマイズまたは非常に特殊なダイアログを処理する際は変換が不完全になります。このツールはタッチ操作向け UI 用の新しいダイアログを作成しますが、変換できない項目はスキップします。そのため、作成されたダイアログには、コピー元のクラシックダイアログのノードがそのままの状態で含まれている可能性があります（その特定のウィジェットに一致するルールがない場合）。または、変換後のウィジェットで一部のプロパティが失われる可能性があります。これは、そのプロパティの変換に適したルールが存在しないためです。
-
パッケージマネージャーまたはパッケージ共有からパッケージをダウンロードします。
このツールは、クラシック UI 用のダイアログしか設計されていない既存のコンポーネントを拡張します。そのために、タッチ操作向け UI 用の対応するダイアログをコンテンツツリー（コンポーネント定義）内の同じ場所に作成します。
- クラシック UI 用のダイアログ：
- 名前：dialog
- タイプ：cq:Dialog
- 名前：dialog
- タッチ操作向け UI のダイアログ：
- 名前：cq:dialog
- 名前：cq:dialog
-
指定したパスの下にある（全レベルの）すべてのダイアログが表に示されます。
- ダイアログ (クラシック UI)
タイプが cq:Dialog で名前が dialog のすべてのノードが表示用に選択されます。 - 各行には、次の用途のリンクがあります。
- クラシック UI でダイアログを表示する
- crxde（CRXDE Lite）でノード構造を確認する
- クラシック UI でダイアログを表示する
- ダイアログ (タッチ UI)
タッチ操作向け UI 用のダイアログが作成済みの場合はここに表示されます。表示されるのは、タッチ操作向け UI のダイアログのリンクです。これは、dialog ノードに cq:dialog という名前の兄弟ノードがあるかどうかによって判断されます。タッチ操作向けのダイアログが存在する場合は、変換する項目を選択できません。
注意：
クラシック UI 用のダイアログがないコンポーネント（タッチ操作向け UI 用にのみ設計されているコンポーネント）は表示されません。
- ダイアログ (クラシック UI)
変換ツールの実装は、グラフの書き換えの概念に基づいています。この概念では、一連の書き換えルールを適用してグラフが変換されます。あるルールが特定の部分グラフに一致する場合は、そのルールを適用して、部分グラフを置換用のグラフに置き換えます（http://en.wikipedia.org/wiki/Graph_rewriting も参照）。
通常は、1 つのダイアログの書き換えルールで 1 つのダイアログ要素（pathfield ウィジェットなど）を書き換えます。アルゴリズムによってダイアログツリーがトラバースされ、（ルールのランキングで指定された）優先順位に従って、一致する書き換えルールが適用されます。この処理は、一致するルールがなくなるまで繰り返されます（そのため、書き換えのループが作成されないように注意してください）。
書き換えルールは、次に示す 2 つの異なる方法で定義できます。
- JCR ノード構造 - ノードベースの書き換えルール
- 特定のインターフェイスを実装する Java クラス - Java ベースの書き換えルール
一部のルールは標準提供されていますが、独自にカスタマイズしたルール（ノードベースと Java ベースの両方）を定義することもできます。
ダイアログ変換ツールには、定義済みの書き換えルールがいくつか含まれています。これらのルールは、以下のクラシック UI ウィジェット（詳しくは、xtype の使用を参照）に対応しています。
button、checkbox、combobox、cqinclude、datetime、dialog、dialogfieldset、fieldset、fileuploadfield、hidden、numberfield、hidden、multifield、numberfield、panel、password、pathfield、radio、radiogroup、select、sizefield、tabpanel、tags、textfield、textarea
rule
- jcr:primaryType = nt:unstructured
- cq:rewriteRanking = 4
+ patterns
- jcr:primaryType = nt:unstructured
+ foo
- ...
+ ...
+ foo1
- ...
+ ...
+ replacement
+ bar
- ...
+ ...
この例では、2 つのパターン（foo および foo1 をルートとするツリー）と 1 つのリプレースメント（bar をルートとするツリー）を含むルールを定義します。このパターンとリプレースメントのツリーは、ノードとプロパティを含む任意のツリーです。定義済みのいずれかのパターンが一致すると、ルールがサブツリーに一致します。パターンを一致させるには、そのパターンと同じノードが対象となるツリーに含まれている（ルートを除いて名前が一致する）必要があります。また、パターンで定義されたすべてのプロパティがツリー上のプロパティに一致する必要があります。cq:rewriteOptional を true に設定することで、パターン内のノードをオプションとしてマークできます。この場合、ツリーを一致させるためにそのノードを指定する必要はありません。
一致したサブツリー（元のツリー）はリプレースメントに置き換えられます。リプレースメントツリーでは、元のツリーのプロパティの値を継承するマップ先のプロパティを定義できます。このようなプロパティは String タイプにする必要があります。形式は次のようになります。
${<path>}
参照先のプロパティが元のツリーに存在しない場合、そのプロパティはリプレースメントで省略されます。または、そのような場合のためのデフォルト値を指定できます（String タイプのプロパティの場合のみ）。
${<path>:<default>}
マップ先のプロパティには複数の値を指定できます。この場合は、元のツリーに存在する最初のプロパティの値が割り当てられます。次の例は、プロパティのマッピングを示しています。
...
+ replacement
+ bar
- prop = ${./some/prop}
- default = ${./non/existing:default string value}
- multi = [${./non/existing}, ${./some/prop}]
さらに、リプレースメントツリーでは以下の特殊なプロパティ（cq:rewrite... で始まるプロパティ）がサポートされます。
cq:rewriteMapChildren（String）
元のツリーの参照先のノードの子を、このプロパティを含むノードにコピーします（例えば、cq:rewriteMapChildren=./items は ./items の子を現在のノードにコピーします）。- cq:rewriteIsFinal（Boolean）
最適化の方法として残りの変換で無視できる最終のノードでこのプロパティを設定します。リプレースメントノード（rule/replacement）自体に設定すると、リプレースメントツリー全体が最終であると見なされます。
提供されている書き換えルールは次の場所で定義されます。
/libs/cq/dialogconversion/rules
次の場所に一連のルールを指定して、これらのルールを上書きできます。
/apps/cq/dialogconversion/rules
/libs/cq/dialogconversion/rules を /apps にコピーしてから、既存のルールを変更するか、新しいルールをこの新しいインスタンスに追加できます。
インターフェイスの OSGi サービスを公開する Java クラスとして、さらに複雑な書き換えルールを定義できます。
com.adobe.cq.dialogconversion.DialogRewriteRule
このようなクラスでは次のメソッドを実装する必要があります。
boolean matches(Node root) throws RepositoryException; Node applyTo(Node root, Set<Node> finalNodes) throws DialogRewriteException, RepositoryException; int getRanking();
指定されたルートノードをルートとするサブツリーにルールが一致する場合に、matches メソッドが true を返す必要があります。ルールが一致する場合、ツリーの書き換えアルゴリズムは続いて applyTo メソッドを呼び出します。このメソッドでは、指定されたルートノードをルートとするサブツリーを書き換える必要があります。通常、このメソッドは元のツリーの名前を一時的に変更して、元のツリーの親ノードの新しい子として（元のツリーのノードとプロパティを使用して）新しいツリーを作成し、最後に元のツリーを削除します。詳しくは、com.adobe.cq.dialogconversion.DialogRewriteRule インターフェイスの Javadoc を参照してください。
詳しくは、com.adobe.cq.dialogconversion の Javadoc を参照してください。
@Component
@Service
public class CustomDialogRewriteRule implements DialogRewriteRule {
public boolean matches(Node root) throws RepositoryException {
// ...
}
public Node applyTo(Node root, Set<Node> finalNodes) throws DialogRewriteException, RepositoryException {
// ...
}
int getRanking() {
// ...
}
}
または、com.adobe.cq.dialogconversion.AbstractDialogRewriteRule を次のように拡張できます。この抽象クラスは getRanking メソッドを実装し、サービスの OSGi プロパティである service.ranking を使用してルールのランキングを決定します。
@Component
@Service
@Properties({
@Property(name="service.ranking", intValue = 10)
})
public class CustomDialogRewriteRule extends AbstractDialogRewriteRule {
public boolean matches(Node root) throws RepositoryException {
// ...
}
public Node applyTo(Node root, Set<Node> finalNodes) throws RewriteException, RepositoryException {
// ...
}
}
GitHub のコード
このページのコードは GitHub にあります
- GitHub の aem-touchui-dialogconversion-samples プロジェクトを開きます
- プロジェクトを ZIP ファイルとしてダウンロードします
Twitter™ および Facebook の投稿には、Creative Commons の規約内容は適用されません。