Sie sehen sich Hilfeinhalte der folgenden Version an:

Mit dem Dialogfeldkonvertierungs-Tool können Sie vorhandene Komponenten erweitern, für die nur ein Dialogfeld für die klassische Benutzeroberfläche auf Grundlage von ExtJS oder der Granite-Benutzeroberfläche und Coral 2 definiert ist. Das Tool verwendet das ursprüngliche Dialogfeld, um ein Dialogfeldduplikat zu erstellen, das für die Standardbenutzeroberfläche auf Grundlage der Granite-Benutzeroberfläche und Coral 3-basierten Benutzeroberfläche vorgesehen ist.

Ziel dieses Tools ist die weitestgehende Automatisierung der Aktualisierung, um die Effizienz zu steigern und Fehler zu vermeiden. Da das Tool jedoch nicht jedes Szenario abdecken kann, lässt sich der Prozess nicht vollständig automatisieren und die Benutzer müssen die konvertierten Dialogfelder überprüfen und eventuell weitere Anpassungen vornehmen. Das Tool soll Ihnen helfen, mit dem Konvertierungsprozess zu beginnen. Es zielt jedoch nicht darauf ab, die Konvertierung umfassend zu steuern.

Das Tool erstellt das neue Dialogfeld mithilfe der Standardbenutzeroberfläche, der Granite-Benutzeroberfläche und der Coral 3-basierten Benutzeroberfläche, überspringt jedoch alles, was es nicht konvertieren kann. Wenn keine Regel mit der spezifischen Komponente übereinstimmt, kann daher das resultierende Dialogfeld möglicherweise Knoten aus dem ursprünglichen Dialogfeld enthalten. Außerdem kann eine konvertierte Komponente einige nicht konvertierte Eigenschaften aufweisen, da keine geeignete Regel für deren Konvertierung vorlag.

Vorsicht:

Das Tool kann nicht jedes Szenario abdecken, da die zugehörigen Konvertierungsregeln nicht erschöpfend sind und nach bestem Wissen und den bestehenden Möglichkeiten angewendet werden.  Es konvertiert die am häufigsten verwendeten Elemente und Eigenschaften. Die Konvertierung ist jedoch unvollständig, wenn Anpassungen oder hochspezialisierte Dialogfelder verarbeitet werden. Konvertierte Dialogfelder müssen ggf. zusätzlich angepasst werden. Darüber hinaus müssen alle Konvertierungen überprüft werden.

Hinweis:

Da die klassische Benutzeroberfläche nicht mehr weiterentwickelt wird, empfiehlt Adobe die Aktualisierung auf die Granite-Standardbenutzeroberfläche, um von den neuesten Technologien zu profitieren.

Obwohl die Umstellung auf die neueste Plattform im Allgemeinen ratsam ist, ist die Migration von Coral 2 auf Coral 3 nicht kritisch. Allerdings sollten sämtliche neuen Projekte auf Grundlage von Coral 3 gestartet werden.

Herunterladen und Installieren des Dialogfeldkonvertierungs-Tools

Das Dialogfeldkonvertierungs-Tool steht als Open-Source-Lösung über GitHub zur Verfügung.

CODE AUF GITHUB

Den Code dieser Seite finden Sie auf GitHub

Hinweis:

Das Dialogfeldkonvertierungs-Tool ist nicht standardmäßig in AEM enthalten. Sie müssen es herunterladen und installieren, um es verwenden zu können.

Führen Sie folgende Schritte aus, um das Tool zu installieren.

  1. Laden Sie das Paket aus dem Projekt Dialog Conversion Tool (Dialogfeldkonvertierungs-Tool) auf GitHub herunter.

  2. Installieren Sie das Paket auf Ihrer Instanz. Weitere Informationen zur Paketverwaltung finden Sie unter Arbeiten mit Paketen.

Konvertieren von Dialogfeldern

Das Tool konvertiert Dialogfelder, indem es ein entsprechendes Dialogfeld für die Granite-/Coral 3-basierte Benutzeroberfläche an derselben Stelle wie das ursprüngliche Dialogfeld im Inhaltsbaum erstellt. Granite-/Coral 2-Dialogfelder werden an einen Backup-Speicherort kopiert (dabei wird das Suffix .coral2 an den Namen des Dialogfeldknotens angehängt), damit sie nicht überschrieben werden. Das Tool kann Designdialogfelder und Bearbeitungsdialogfelder konvertieren.

Führen Sie zum Konvertieren von Dialogfeldern die folgenden Schritte aus:

  1. Öffnen Sie die über Globale Navigation > Tools > Vorgänge zugängliche Dialogfeldkonvertierungskonsole:

    http://<Hostname>:<Port>/libs/cq/dialogconversion/content/console.html

    chlimage_1
  2. Geben Sie den erforderlichen Pfad ein, beispielsweise /apps/geometrixx/components. Sie können auch einen direkten Pfad zu einem einzelnen Dialogfeld eingeben, beispielsweise /apps/geometrixx/components/lead.

    chlimage_1
  3. Wählen Sie Dialogfelder anzeigen aus, um alle Dialogfelder unter diesem Speicherort anzuzeigen.

    chlimage_1

    Die Tabelle listet alle vorhandenen Legacy-Dialogfelder unterhalb des eingegebenen Pfades auf. Für jedes Dialogfeld ist der entsprechende Typ aufgeführt. Dazu zählen die folgenden Typen: 

    • Klassische Benutzeroberfläche: Konten des Typs cq:Dialog mit dem Knotennamen dialog oder design_dialog
    • Coral 2: Knoten mit dem Namen cq:dialog oder cq:design_dialog, die einen Granite-/Coral 2-Ressourcentyp auf ihrem untergeordneten Inhaltsknoten aufweisen

    Jede Zeile enthält einen Link zum Anzeigen des Dialogfelds und einen Link zu CRXDE Lite zum Anzeigen des Knotenbaums.

    Hinweis:

    Komponenten, die überhaupt kein Dialogfeld für die klassische Benutzeroberfläche oder Coral 2 haben (d. h. mit der Granite-Benutzeroberfläche/Coral 3 entworfen wurden), werden nicht aufgeführt.

  4. Wählen Sie ein oder mehrere Dialogfelder für die Konvertierung aus und klicken oder tippen Sie auf X Dialogfeld(er) konvertieren, um den Konvertierungsvorgang zu starten.

    chlimage_1
  5. Die ausgewählten Dialogfelder werden mit den Ergebnissen ihrer Konvertierungen aufgeführt. Wenn die Konvertierung erfolgreich war, enthält die Zeile Links, über die die konvertierten Dialogfelder angezeigt oder in CRXDE Lite geöffnet werden können.

    Klicken oder tippen Sie auf Zurück, um zum Dialogfeldkonvertierungs-Tool zurückzukehren.

    chlimage_1
  6. Dort werden die konvertierten Dialogfelder anschließend nicht mehr in der Liste aufgeführt. Beachten Sie jedoch, dass die Gesamtanzahl der gefundenen Dialogfelder weiterhin aufgeführt wird, einschließlich der bereits konvertierten Dialogfelder, d. h. die Anzahl der Zeilen in der Tabelle stimmt nicht notwendigerweise mit der Anzahl der gefundenen Dialogfelder überein.

    chlimage_1
  7. Aktivieren Sie das Kontrollkästchen Konvertierte Dialogfelder anzeigen, um die Dialogfelder anzuzeigen, die sich unter dem angegebenen Pfad befinden und bereits konvertiert wurden.

    chlimage_1

    Wenn das Dialogfeld bereits konvertiert ist, werden auch Links zum konvertierten Dialogfeld bereitgestellt. Ein Dialogfeld gilt als konvertiert, wenn bereits ein gleichrangiges Dialogfeld für die Granite-Benutzeroberfläche/Coral 3 verfügbar ist.

Neuschreibungsregeln für Dialogfelder

Das Dialogfeldkonvertierungs-Tool basiert auf dem Konzept der Graphenneuschreibung. Hierbei wird ein Kategoriegraph durch die Anwendung von Neuschreibungsregeln konvertiert. Mit einer Neuschreibungsregel wird ein Muster mit einem Ersatzgraphen abgeglichen. Die Regel gleicht die Vorkommen eines bestimmten Teilgraphen im Kategoriegraphen ab und ersetzt sie anschließend. Weitere Informationen zur Graphenneuschreibung finden Sie unter https://de.wikipedia.org/wiki/Graphersetzungssystem.

Das Dialogfeldkonvertierungs-Tool verwendet diesen Ansatz zum Neuschreiben eines vorhandenen Dialogfeldbaums, der für die klassische Benutzeroberfläche oder die Granite-Benutzeroberfläche/Coral 2 entworfen wurde, als Entsprechung für die Granite-Benutzeroberfläche/Coral 3. Dies hat den Vorteil, dass die Konvertierung äußerst flexibel ist und auch komplexe Komponenten berücksichtigen kann, da der Abgleich nicht nur auf einzelne Knoten oder Eigenschaften, sondern auch für tatsächliche Unterbaumstrukturen erfolgt.

Algorithmus

Der Neuschreibungsalgorithmus zieht als Parameter den umzuschreibenden Baum und eine Reihe von Neuschreibungsregeln heran. Er durchläuft den Baum vorab und prüft für jeden Knoten, ob eine Regel für die Unterbaumstruktur gilt, die sich an dem Stammknoten befindet. Die erste Regel, die übereinstimmt, wird auf diese Unterbaumstruktur angewendet, um sie neu zu schreiben. Der Durchlauf erfolgt dann vom Stamm ausgehend erneut. Der Algorithmus stoppt, sobald der gesamte Baum durchlaufen wurde und keine Regel mit einer Unterbaumstruktur übereinstimmt. Als Optimierungsmaßnahme erfasst der Algorithmus Knoten, die endgültig sind und daher bei nachfolgenden Durchläufen nicht erneut auf Übereinstimmungen überprüft werden müssen. Welche Knoten des neugeschriebenen Baums endgültig sind und welche durch zukünftige Durchläufe des Algorithmus überprüft werden sollen, wird durch die Neuschreibungsregeln definiert.

Der Einstiegspunkt für die Konvertierung ist das DialogConversionServlet, das für POST-Anforderungen an /libs/cq/dialogconversion/content/convert.json registriert ist. Es akzeptiert einen Pfadanforderungsparameter, bei dem es sich um ein Array mit den Pfaden zu den Dialogfeldern handelt, die konvertiert werden sollen. Für jedes Dialogfeld schreibt das Servlet dann den entsprechenden Dialogfeldbaum neu, indem es alle definierten Neuschreibungsregel für Dialogfelder anwendet.

Neuschreibungsregeltypen

Die Neuschreibungsregeln können auf zwei verschiedene Arten definiert werden:

Einige sind bereits im Standardumfang enthalten. Sie können jedoch auch Ihre eigenen benutzerdefinierten Regeln definieren. Beispielneuschreibungsregeln sind ebenfalls verfügbar.

Für gewöhnlich ist eine Neuschreibungsregel für ein einzelnes Dialogfeld verantwortlich für das Neuschreiben eines einzelnen Dialogfeldelements, beispielsweise des Pfadbrowser-Eingabefelds.

Vorsicht:

Neuschreibungsschleifen werden vom Algorithmus nicht erkannt, daher dürfen Neuschreibungsregeln Bäume nicht zirkulär neuschreiben.

Knotenbasierte Neuschreibungsregeln

Eine Neuschreibungsregel für Dialogfelder kann in puncto Knoten und Eigenschaften definiert werden.

rule
  - jcr:primaryType = nt:unstructured
  - cq:rewriteRanking = 4
  + patterns
    - jcr:primaryType = nt:unstructured
    + foo
      - ...
      + ...
    + foo1
      - ...
      + ...
  + replacement
    + bar
      - ...
      + ...

In diesem Beispiel werden eine Regel mit zwei Mustern (die Bäume befinden sich bei foo und foo1) und eine Ersetzung (der Baum befindet sich bei bar) definiert. Bei den Muster- und Ersetzungsbäumen handelt es sich um arbiträre Bäume mit Knoten und Eigenschaften. Die Regel gleicht eine Unterbaumstruktur ab, wenn eines der definierten Muster übereinstimmt. Damit es zu einer Übereinstimmung kommt, muss der Kategoriebaum dieselben Knoten enthalten wie das Muster (übereinstimmende Namen) und alle im Muster definierten Eigenschaften müssen mit den Eigenschaften des Baums übereinstimmen.

Im Falle einer Übereinstimmung wird die übereinstimmende Unterbaumstruktur (der ursprüngliche Baum) entsprechend ersetzt. Der Ersetzungsbaum kann zugeordnete Eigenschaften definieren, die den Wert einer Eigenschaft im ursprünglichen Baum übernehmen. Sie müssen vom Typ String sein und das folgende Format aufweisen: 

${<path>}

Wenn die referenzierte Eigenschaft im ursprünglichen Baum nicht vorhanden ist, wird die Eigenschaft ausgelassen. Alternativ kann für diesen Fall (nur möglich für Eigenschaften vom Typ „String“ (Zeichenfolge)) ein Standardwert angegeben werden:

${<path>:<default>}

Eigenschaften, die das Zeichen „:“ enthalten, können in einfache Anführungszeichen gesetzt werden, um Probleme mit der Angabe eines Standardwerts zu vermeiden. Boolesche Eigenschaften werden negiert, wenn dem Ausdruck „!“ vorangestellt wird. Zugeordnete Eigenschaften können mehrwertig sein. In diesem Fall wird ihnen der Wert der ersten Eigenschaft zugewiesen, die im übereinstimmenden Baum vorhanden ist.

Beispielsweise wird der folgenden Eigenschaft one der Wert der Eigenschaft ./two/three des übereinstimmenden ursprünglichen Baums zugewiesen. 

...
  + replacement
    + bar
      - one = ${./two/three}
      - negated = !${./some/boolean/prop}
      - default = ${./some/prop:default}
      - multi = [${./prop1}, ${./prop2}]

Regeln unterstützen auch die folgenden optionalen Eigenschaften.

  • cq:rewriteOptional (boolescher Wert)
    Ändern Sie den Wert der Eigenschaft in einen Musterknoten, um anzugeben, dass der Knoten nicht für eine Übereinstimmung mit dem Muster vorhanden sein muss.

  • cq:rewriteRanking (Ganzzahl)
    Ändern Sie den Wert der Eigenschaft des Regelknotens, um Einfluss auf die Reihenfolge zu nehmen, in der die Regeln angewendet werden. Dies kann nützlich sein, um sicherzustellen, dass Regeln, die spezifischere Strukturen behandeln, nicht durch allgemeinere Regeln überschrieben werden. Regeln mit einem niedrigeren Rang haben Vorrang vor denen mit einem höheren Rang. Alle Regeln erhalten standardmäßig Integer.MAX_VALUE als Rang.

Der Ersetzungsbaum unterstützt außerdem die folgenden Spezialeigenschaften (beginnend mit cq:rewrite):

  • cq:rewriteMapChildren (Zeichenfolge)
    Der Knoten, der diese Eigenschaft enthält, umfasst eine Kopie der untergeordneten Elemente des Knotens im ursprünglichen Baum, auf den der Eigenschaftswert (beispielsweise cq:rewriteMapChildren=./items) verweist.

  • cq:rewriteFinal (boolescher Wert)
    Dies ist eine Optimierungsmaßnahme, mit der dem Algorithmus mitgeteilt wird, dass der Knoten, der diese Eigenschaft enthält, endgültig ist und nicht erneut auf übereinstimmende Neuschreibungsregeln überprüft werden muss. Bei Platzierung auf dem Ersetzungsknoten selbst wird der gesamte Ersetzungsbaum als endgültig erachtet.

  • cq:rewriteCommonAttrs (boolescher Wert)
    Ändern Sie diese Eigenschaft des Ersetzungsknotens (rule/replacement), um relevante Eigenschaften des ursprünglichen Stammknotens Entsprechungen allgemeiner Attribute von Granite im Stamm der Kopie zuzuordnen. Damit werden Datenattribute verarbeitet, indem der Unterknoten granite:data ans Ziel kopiert bzw. am Ziel erstellt wird und dort die data-*-Eigenschaften geschrieben werden.

  • cq:rewriteRenderCondition (boolescher Wert)
    Ändern Sie diese Eigenschaft des Ersetzungsknotens (rule/replacement), um einen beliebigen untergeordneten Knoten einer Granite-Renderbedingung (rendercondition oder granite:rendercondition) vom ursprünglichen Stammknoten in einen untergeordneten granite:rendercondition-Knoten des Stamms der Kopie zu kopieren.

Darüber hinaus kann der Knoten cq:rewriteProperties zu einem Ersetzungsknoten hinzugefügt werden, um Zeichenfolgenneuschreibungen für zugeordnete Eigenschaften im Ergebnis zu definieren. Der Knoten wird aus der Ersetzung entfernt. Die Eigenschaften des Knotens cq:rewriteProperties müssen dieselben sein wie die, die sie neu schreiben, und ein Zeichenfolgen-Array mit zwei Parametern akzeptieren:

  • pattern: RegEx für den Abgleich, beispielweise "(?:coral-Icon–)(.+)"
  • replacement: Wird für die Matcher-Funktion replaceAll bereitgestellt, beispielsweise "$1".

Im Folgenden finden Sie ein Beispiel für die Neuschreibung von Coral 2-Symboleigenschaften in Coral 3-Entsprechungen:

...
  + replacement
    + bar
      - icon = ${./icon}
      + cq:rewriteProperties
      	- icon = [(?:coral-Icon--)(.+), $1]

Definieren eigener knotenbasierten Neuschreibungsregeln

Die bereitgestellten Neuschreibungsregeln werden definiert unter:

/libs/cq/dialogconversion/rules

Die Regeln sind an dieser Stelle weiter unterteilt in Ordner für Neuschreibungsregeln für die klassische Benutzeroberfläche und Neuschreibungsregeln für Coral 2:

/libs/cq/dialogconversion/rules/classic

/libs/cq/dialogconversion/rules/coral2

Diese Regeln können durch das Bereitstellen einer Regelgruppe unter dem folgenden Pfad überschrieben werden:

/apps/cq/dialogconversion/rules

Sie können /libs/cq/dialogconversion/rules nach /apps kopieren und anschließend die vorhandenen bzw. neuen Regeln für diese neue Instanz ändern.

Java-basierte Neuschreibungsregeln

Komplexere Neuschreibungsregeln können als Java-Klassen definiert werden, die einen OSGi-Dienst der Schnittstelle com.adobe.cq.dialogconversion.DialogRewriteRule verfügbar machen.

Eine derartige Klasse muss die folgenden Methoden implementieren:

boolean matches(Node root) throws RepositoryException;
Node applyTo(Node root, Set<Node> finalNodes) throws DialogRewriteException, RepositoryException;
int getRanking();

Die Methode matches muss true zurückgeben, wenn die Regel die Unterstruktur abgleicht, die sich im angegebenen Stammknoten befindet. Wenn die Regel übereinstimmt, ruft der Algorithmus für das Neuschreiben der Struktur nachfolgend die Methode applyTo auf, die die Unterstruktur neuschreiben muss, die sich am angegebenen Stammknoten befindet. Durch diese Methode wird der ursprüngliche Baum für gewöhnlich umbenannt. Zudem werden dadurch der neue Baum als ein neues untergeordnetes Element des übergeordneten Knotens des ursprünglichen Baums erstellt (unter Verwendung der zugehörigen Knoten und Eigenschaften) und der ursprüngliche Baum schließlich entfernt. Ausführlichere Informationen finden Sie im Javadoc der Schnittstelle com.adobe.cq.dialogconversion.DialogRewriteRule.

Weitere Informationen – Javadocs

Weitere Informationen finden Sie unter Javadocs für com.adobe.cq.dialogconversion.

Definieren eigener Java-basierter Neuschreibungsregeln

Die folgende Klasse zeigt ein Beispiel einer benutzerdefinierten Neuschreibungsregel, die die Schnittstelle com.adobe.cq.dialogconversion.DialogRewriteRule implementiert.

@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() {
        // ...
    }

}

Alternativ können Sie com.adobe.cq.dialogconversion.AbstractDialogRewriteRule wie unten gezeigt erweitern. Die abstrakte Klasse implementiert die Methode getRanking und verwendet die OSGi-Eigenschaft service.ranking des Diensts zum Bestimmen des Regelrangs.

@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 {
        // ...
    }
 
}

Bereitgestellte Neuschreibungsregeln

Das Paket cq-dialog-conversion-content enthält mehrere vordefinierte Neuschreibungsregeln. Weitere Informationen zu Widgets für die klassische Benutzeroberfläche finden Sie unter Arbeiten mit xtypes.

Regel Legacy-Komponente Ersetzung für die Granite-Benutzeroberfläche/Coral 3
com.adobe.cq.dialogconversion.rules.CqDialogRewriteRule Knoten des Typs cq:Dialog, verarbeitet unterschiedliche Unterstrukturen

Ein granite/ui/components/foundation/container, der entweder ein fixedcolumns- oder tabs&-Layout verwendet

Die eigentlichen Komponenten des Dialogfelds werden kopiert und in nachfolgenden Durchläufen des Algorithmus neu geschrieben.

com.adobe.cq.dialogconversion.rules.IncludeRule xtype = cqinclude Der Knoten, auf den verwiesen wird, wird in das Dialogfeld für die Granite-Benutzeroberfläche/Coral 3 kopiert und ggf. anschließend durch den Algorithmus neu geschrieben.
com.adobe.cq.dialogconversion.rules.MultifieldRewriteRule xtype = multifield

granite/ui/components/coral/foundation/form/multifield

Der untergeordnete Knoten fieldConfig  (sofern vorhanden) wird separat neu geschrieben. Dadurch werden die unterstützten Komponenten nicht eingeschränkt.

/libs/cq/dialogconversion/rules/classic button
checkbox
colorfield
combobox
componentselector
datetime
fieldset
fileupload
hidden
numberfield
panel
password
pathfield
radio
radiogroup
select
sizefield
tabpanel
tags
textarea
textfield
 
/libs/cq/dialogconversion/rules/coral2 actionfield
autocomplete
button
checkbox
collapsible
colorpicker
container
datepicker
fieldset
fileupload
fixedcolumns
heading
hidden
hyperlink
include
multifield
nestedcheckboxlist
nestedcheckboxlist-checkbox
numberfield
password
pathbrowser
radio
radiogroup
reset
select
submit
switch
tabs
tags
text
textarea
textfield
userpicker
well
 

Beispielneuschreibungsregeln

CODE AUF GITHUB

Den Code dieser Seite finden Sie auf GitHub

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie