Erstellen von Websites für Mobilgeräte creating-sites-for-mobile-devices

Last update: Sun Mar 31 2024 00:00:00 GMT+0000 (Coordinated Universal Time)

NOTE

Adobe empfiehlt die Verwendung des SPA-Editors für Projekte, für die ein Framework-basiertes Client-seitiges Rendering für einzelne Seiten (z. B. React) erforderlich ist. Weitere Informationen

Das Erstellen einer mobilen Website ähnelt dem Erstellen einer Standardwebsite, da auch Vorlagen und Komponenten erstellt werden müssen Weitere Informationen zum Erstellen von Vorlagen und Komponenten finden Sie auf den folgenden Seiten: Vorlagen, Komponenten und Erste Schritte bei der Entwicklung von AEM Sites. Der Hauptunterschied besteht im Aktivieren der integrierten Mobile-Funktionen von Adobe Experience Manager (AEM) innerhalb der Site. Hierzu wird eine Vorlage erstellt, die auf der Mobile-Seitenkomponente basiert.

Sie sollten in Betracht ziehen, ein responsives Design zu verwenden und eine einzelne Site zu erstellen, die mehrere Bildschirmgrößen unterstützt.

Um zu beginnen, können Sie sich die We.Retail Mobile Demo-Site ansehen, die in AEM verfügbar ist.

Um eine Mobile-Site zu erstellen, gehen Sie folgendermaßen vor:

Erstellen Sie die Seitenkomponente:
- Legen Sie die Eigenschaft sling:resourceSuperType auf wcm/mobile/components/page fest.
  Auf diese Weise beruht die Komponente auf der Mobile-Seiten-Komponente.
- Erstellen Sie die Datei body.jsp mit der projektspezifischen Logik.
Erstellen Sie die Seitenvorlage:
- Legen Sie die Eigenschaft sling:resourceType auf die neu erstellte Seitenkomponente fest.
- Legen Sie die Eigenschaft allowedPaths fest.
Erstellen Sie die Design-Seite für die Website.
Erstellen Sie die Website-Root-Seite unter dem Knoten /content:
- Legen Sie die Eigenschaft cq:allowedTemplates fest.
- Legen Sie die Eigenschaft cq:designPath fest.
Legen Sie in den Seiteneigenschaften der Website-Root-Seite die Gerätegruppen auf der Registerkarte Mobile fest.
Erstellen Sie die Website-Seiten mithilfe der neuen Vorlage.

Die Mobile-Seiten-Komponente (/libs/wcm/mobile/components/page):

Fügt die Registerkarte Mobile zum Dialogfeld „Seiteneigenschaften“ hinzu.
Über ihre head.jsp ruft sie die aktuelle Mobilgerätegruppe aus der Anfrage ab und verwendet, wenn eine Gerätegruppe gefunden wird, die Methode drawHead() der Gruppe, um die zugehörige Emulator-Init-Komponente der Gerätegruppe (nur im Autorenmodus) und das Rendering-CSS der Gerätegruppe einzuschließen.

NOTE

Die Root-Seite der mobilen Website muss sich auf der Ebene 1 der Knotenhierarchie befinden. Es wird empfohlen, dass sie sich unterhalb des Knotens/Inhalt befindet.

Erstellen einer Mobile-Site mit dem Multi-Site-Manager creating-a-mobile-site-with-the-multi-site-manager

Verwenden Sie den Multi-Site-Manager (MSM), um eine mobile Live Copy von einer Standardseite zu erstellen. Die Standard-Site wird automatisch in eine Mobile-Site umgewandelt: Die Mobile-Site weist alle Funktionen von Mobile-Sites auf (z. B. die Bearbeitung in einem Emulator) und kann synchron mit der Standard-Site verwaltet werden. Siehe den Abschnitt Erstellen einer Live Copy für unterschiedliche Kanäle auf der Multi-Site-Manager-Seite.

Server-seitige Mobile-API server-side-mobile-api

Folgende Java™-Pakete enthalten die Mobile-Klassen:

com.day.cq.wcm.mobile.api – definiert MobileConstants.
com.day.cq.wcm.mobile.api.device – definiert Device, DeviceGroup und DeviceGroupList.
com.day.cq.wcm.mobile.api.device.capability – definiert DeviceCapability.
com.day.cq.wcm.mobile.api.wurfl – definiert WurflQueryEngine.
com.day.cq.wcm.mobile.core – definiert MobileUtil, das verschiedene Hilfsmethoden um WCM Mobile herum bereitstellt.

Mobile Komponenten mobile-components

Die We.Retail Mobile-Demo-Website verwendet die folgenden Mobile-Komponenten, die sich unter /libs/foundation/components befinden:

Name

Gruppe

Merkmale

mobilefooter

hidden

- Fußzeile

mobileimage

Mobilgerät

- basierend auf der „image foundation“-Komponente
– rendert ein Bild, wenn das Gerät dazu imstande ist

mobilelist

Mobilgerät

- basierend auf der „list foundation“-Komponente
– listitem_teaser.jsp rendert ein Bild, wenn das Gerät dazu imstande ist

mobilelogo

hidden

- basierend auf der „logo foundation“-Komponente
– rendert ein Bild, wenn das Gerät dazu imstande ist

mobilereference

Mobilgerät

- ähnlich der „reference foundation“-Komponente

- ordnet eine „textimage“-Komponente einer „mobiletextimage“-Komponente und eine „image“-Komponente einer „mobileimage“-Komponente zu

mobiletextimage

Mobilgerät

- basierend auf der „textimage foundation“-Komponente
– rendert ein Bild, wenn das Gerät dazu imstande ist

mobiletopnav

hidden

- basierend auf der „topnav foundation“-Komponente

- nur Text wird gerendert

Erstellen einer Mobile-Komponente creating-a-mobile-component

Mit dem mobilen Framework AEM können Sie Komponenten entwickeln, die für das Gerät, das die Anforderung ausgibt, empfindlich sind. Die folgenden Code-Beispiele zeigen, wie Sie die AEM-Mobile-API in einer Komponenten-jsp verwenden und insbesondere wie Sie:

das Gerät aus der Anfrage abrufen:
Device device = slingRequest.adaptTo(Device.class);
die Gerätegruppe abrufen:
DeviceGroup deviceGroup = device.getDeviceGroup();
die Funktionen der Gerätegruppe abrufen:
Collection<DeviceCapability> capabilities = deviceGroup.getCapabilities();
die Geräteattribute abrufen (Raw-Funktions-Schlüssel/-Werte aus der WURFL-Datenbank):
Map<String,String> deviceAttributes = device.getAttributes();
den Gerätebenutzeragenten abrufen:
String userAgent = device.getUserAgent();
die Gerätegruppenliste (Gerätegruppen, die der Seite vom Autor zugewiesen wurden) von der aktuellen Seite abrufen:
DeviceGroupList deviceGroupList = currentPage.adaptTo(DeviceGroupList.class);
Überprüfen Sie, ob die Gerätegruppe Bilder unterstützt.
if (deviceGroup.hasCapability(DeviceCapability.CAPABILITY_IMAGES)) {
…
ODER
if MobileUtil.hasCapability(request, DeviceCapability.CAPABILITY_IMAGES) {
…

NOTE

In einem jsp ist slingRequest über das Tag <sling:defineObjects> und currentPage über das Tag <cq:defineObjects> verfügbar.

Emulatoren emulators

Emulator-basiertes Authoring bietet Autoren die Mittel, Inhaltsseiten für mobile Clients zu erstellen. Das Authoring mobiler Inhalte folgt dem gleichen Prinzip der direkten WYSIWYG-Bearbeitung. Damit Autoren die Seitenerscheinung auf einem mobilen Gerät erkennen können, wird eine mobile Inhaltsseite mithilfe eines Geräteemulators bearbeitet.

Mobilgeräte-Emulatoren basieren auf dem generischen Emulator-Framework. Weitere Informationen finden Sie unter Emulatoren.

Der Geräteemulator zeigt das tragbare Gerät auf der Seite, während die übliche Bearbeitung (parsys, Komponenten) auf dem Gerätebildschirm erfolgt. Der Geräteemulator hängt von den Gerätegruppen ab, die für die Seite konfiguriert wurden. Mehrere Emulatoren können einer Gerätegruppe zugewiesen werden. Alle Emulatoren sind dann auf der Inhaltsseite verfügbar. Standardmäßig wird der erste Emulator angezeigt, der der ersten Gerätegruppe zugewiesen ist, die der Seite zugewiesen ist. Emulatoren können entweder über das Emulator-Karussell am oberen Rand der Seite oder über die Schaltfläche „Bearbeiten“ des Sidekicks geschaltet werden.

Erstellen eines Emulators

Informationen zum Erstellen eines Emulators finden Sie unter Erstellen eines benutzerdefinierten Mobile-Emulators auf der allgemeinen Seite zu Emulatoren.

Hauptmerkmale von Mobile-Emulatoren

Eine Gerätegruppe besteht aus einem oder mehreren Emulatoren: die Gerätegruppen-Konfigurationsseite, z. B. „/etc/mobile/groups/touch“, enthält die Eigenschaft emulators unterhalb des Knotens jcr:content.
Hinweis: Obwohl es möglich ist, dass derselbe Emulator zu mehreren Gerätegruppen gehört, hat das wenig Sinn.
Über das Konfigurationsdialogfeld der Gerätegruppe wird die Eigenschaft emulators mit dem Pfad der gewünschten Emulatoren festgelegt. Beispiel: /libs/wcm/mobile/components/emulators/iPhone4.
Die Emulator-Komponenten (z. B. /libs/wcm/mobile/components/emulators/iPhone4) erweitern die Basis-Komponente des Mobile-Emulators (/libs/wcm/mobile/components/emulators/base).
Jede Komponente, die den mobilen Basisemulator erweitert, kann beim Konfigurieren einer Gerätegruppe ausgewählt werden. Benutzerdefinierte Emulatoren können daher problemlos erstellt oder erweitert werden.
Zur Zeit der Anforderung im Bearbeitungsmodus wird die Emulatorimplementierung zum Rendern der Seite verwendet.
Wenn die Vorlage der Seite auf der mobilen Seitenkomponente basiert, werden die Emulatorfunktionalitäten automatisch in die Seite integriert (über die head.jsp der mobilen Seitenkomponente).

Gerätegruppen device-groups

Mobilgerätegruppen ermöglichen die Segmentierung von Mobilgeräten basierend auf den Gerätefunktionen. Eine Gerätegruppe stellt die Informationen bereit, die für das emulatorbasierte Authoring auf der Autoreninstanz und für das korrekte Rendern von Inhalten in der Veröffentlichungsinstanz erforderlich sind: Sobald Autoren der mobilen Seite Inhalt hinzugefügt und veröffentlicht haben, kann die Seite in der Veröffentlichungsinstanz angefordert werden. Dort wird die Inhaltsseite anstelle der Bearbeitungsansicht des Emulators mit einer der konfigurierten Gerätegruppen gerendert. Die Auswahl der Gerätegruppe erfolgt basierend auf der Erkennung mobiler Geräte. Die passende Gerätegruppe liefert dann die notwendigen Styling-Informationen.

Gerätegruppen werden als Inhaltsseiten unter /etc/mobile/devices definiert und verwenden die Vorlage Mobilgerätegruppe. Die Gerätegruppenvorlage dient als Konfigurationsvorlage für Gerätegruppendefinitionen in Form von Inhaltsseiten. Die wichtigsten Merkmale sind:

Speicherort: /libs/wcm/mobile/templates/devicegroup
Zulässiger Pfad: /etc/mobile/groups/*
Seitenkomponente: wcm/mobile/components/devicegroup

Zuweisung von Gerätegruppen auf Ihrer Seite assigning-device-groups-to-your-site

Wenn Sie eine mobile Seite erstellen, müssen Sie Ihrer Seite Gerätegruppen zuweisen. AEM stellt je nach den HTML- und JavaScript-Rendering-Funktionen des Geräts drei Gerätegruppen zur Verfügung:

Featurephones, für Feature-Geräte wie das Sony Ericsson W800 mit Unterstützung für einfache HTML, aber keine Unterstützung für Bilder und JavaScript.
Smartphones, für Geräte wie das BlackBerry® mit Unterstützung für einfache HTML und Bilder, aber keine Unterstützung für JavaScript.
Touchphones, für Geräte wie das iPad mit voller Unterstützung für HTML, Bilder, JavaScript und Gerätedrehung.

Da Emulatoren einer Gerätegruppe zugeordnet werden können (siehe Abschnitt Erstellen einer Gerätegruppe), können Autoren bei der Zuweisung einer Gerätegruppe zu einer Website zwischen den Emulatoren wählen, die der Gerätegruppe zugeordnet sind, um die Seite zu bearbeiten.

Zuweisen einer Gerätegruppe zu Ihrer Site:

Navigieren Sie in Ihrem Browser zur Siteadmin-Konsole.
Öffnen Sie die Stammseite Ihrer Mobile-Site unter Websites.
Öffnen Sie die Seiteneigenschaften.
Wählen Sie die Registerkarte Mobile:
- Definieren Sie die Gerätegruppen.
- Klicken Sie auf OK.

NOTE

Wenn die Gerätegruppen für eine Site definiert wurden, werden sie von allen Seiten der Site übernommen.

Gerätegruppenfilter: device-group-filters

Gerätegruppenfilter definieren funktionsgestützte Kriterien, um zu bestimmen, ob ein Gerät zu der Gruppe gehört. Wenn Sie eine Gerätegruppe erstellt haben, können Sie die Filter auswählen, um sie zur Gerätebewertung zu verwenden.

Zur Laufzeit, wenn AEM eine HTTP-Anforderung von einem Gerät empfängt, vergleicht jeder Filter, der einer Gruppe zugeordnet ist, die Gerätefunktionen mit bestimmten Kriterien. Das Gerät wird als zu der Gruppe gehörend betrachtet, wenn es über alle Funktionen verfügt, die von den Filtern benötigt werden. Die Funktionen werden aus der WURFL™-Datenbank abgerufen.

Gerätegruppen können null oder mehr Filter zur Erkennung von Funktionen verwenden. Außerdem kann ein Filter mit mehreren Gerätegruppen verwendet werden. AEM stellt einen Standardfilter bereit, der bestimmt, ob das Gerät über die Funktionen verfügt, die für eine Gruppe ausgewählt sind:

CSS
JPG- und PNG-Dateien
JavaScript
Gerätedrehung

Wenn die Gerätegruppe keinen Filter verwendet, sind die ausgewählten Funktionen, die für die Gruppe konfiguriert sind, die einzigen Funktionen, die ein Gerät benötigt.

Weitere Informationen hierzu finden Sie unter Erstellen von Gerätegruppenfiltern.

Erstellen einer Gerätegruppe creating-a-device-group

Erstellen Sie eine Gerätegruppe, wenn die von AEM installierten Gruppen Ihren Anforderungen nicht entsprechen.

Rufen Sie im Browser die Tools-Konsole auf.
Erstellen Sie eine neue Seite unter Tools > Mobile > Gerätegruppen. Tun Sie Folgendes im Dialogfeld Seite erstellen:
- Geben Sie Special Phones als Titel ein.
- Geben Sie special als Namen ein.
- Wählen Sie Vorlage für Mobilgerätegruppen aus.
- Klicken Sie auf Erstellen.
Fügen Sie in CRXDE eine Datei static.css hinzu, die die Stile für die Gerätegruppe unterhalb des Knotens /etc/mobile/groups/special enthält.
Öffnen Sie die Seite Spezielle Telefone.
Klicken Sie zum Konfigurieren der Gerätegruppe auf die Schaltfläche Bearbeiten neben Einstellungen.
Auf der Registerkarte Allgemein:
- Titel: Der Name der Gruppe von Mobilgeräten.
- Beschreibung: Beschreibung der Gruppe.
- Benutzeragent: user-agent-String, mit dem die Geräte abgeglichen werden. Dieser ist optional und kann ein regulärer Ausdruck sein. Beispiel: BlackBerryZ10
- Funktionen: Definiert, ob die Gruppe Bilder, CSS, JavaScript oder Gerätedrehungen verarbeiten kann.
- Minimale Bildschirmbreite und Minimale Bildschirmhöhe.
- Emulator deaktivieren: Zum Aktivieren/Deaktivieren des Emulators während der Inhaltsbearbeitung.
Auf der Registerkarte Emulatoren:
- Emulatoren: Wählen Sie die Emulatoren aus, die dieser Gerätegruppe zugewiesen sind.
Auf der Registerkarte Filter:
- Um einen Filter hinzuzufügen, klicken Sie auf „Element hinzufügen“ und wählen Sie einen Filter aus der Dropdown-Liste aus.
- Filter werden in der Reihenfolge ausgewertet, in der sie erscheinen. Wenn ein Gerät die Kriterien eines Filters nicht erfüllt, werden nachfolgende Filter in der Liste nicht ausgewertet.
Klicken Sie auf „OK“.

Das Konfigurationsdialogfeld für die Mobilgerätegruppe sieht folgendermaßen aus:

screen_shot_2012-02-01at22043pm

Benutzerdefiniertes CSS pro Gerätegruppe custom-css-per-device-group

Wie bereits zuvor beschrieben, ist es möglich, ein benutzerdefiniertes CSS mit einer Gerätegruppenseite zu verknüpfen, ähnlich wie das CSS einer Design-Seite. Dieses CSS wird verwendet, um das gerätegruppenspezifische Rendern des Seiteninhalts in der Autoren- und Veröffentlichungsinstanz zu beeinflussen. Dieses CSS ist dann automatisch wie folgt enthalten:

auf der Seite der Autoreninstanz für jeden Emulator, der von dieser Gerätegruppe verwendet wird
auf der Seite der Veröffentlichungsinstanz, wenn der Benutzeragent der Anfrage mit einem Mobilgerät in dieser bestimmten Gerätegruppe übereinstimmt

Server-seitige Geräterkennung server-side-device-detection

Verwenden Sie Filter und eine Bibliothek mit Gerätespezifikationen, um die Funktionen des Geräts zu bestimmen, das die HTTP-Anfrage ausführt.

Entwickeln von Gerätegruppenfiltern develop-device-group-filters

Erstellen Sie einen Gerätegruppenfilter, um eine Reihe von Gerätefunktionsanforderungen zu definieren. Erstellen Sie so viele Filter, wie Sie benötigen, um die erforderlichen Gruppen von Gerätefunktionen auszuwählen.

Entwerfen Sie Ihre Filter so, dass Sie Kombinationen von ihnen verwenden können, um die Gruppen von Funktionen zu definieren. In der Regel gibt es eine Überlappung der Funktionen verschiedener Gerätegruppen. Daher können Sie einige Filter mit mehreren Gerätegruppendefinitionen verwenden.

Nachdem Sie einen Filter erstellt haben, können Sie ihn in der Gruppenkonfiguration verwenden.

Weitere Informationen finden Sie unter Erstellen von Gerätegruppenfiltern.

Verwenden der WURFL™-Datenbank using-the-wurfl-database

AEM verwendet eine reduzierte Version der WURFL™-Datenbank, um Gerätefunktionen wie Bildschirmauflösung oder JavaScript-Unterstützung basierend auf dem Benutzeragenten des Geräts abzufragen.

Der XML-Code der WURFL™-Datenbank wird durch Analyse der Datei wurfl.xml in /libs/wcm/mobile/devicespecs/wurfl.xml. als Knoten unter /var/mobile/devicespecs dargestellt. Die Erweiterung auf Knoten erfolgt zum ersten Mal, wenn das Paket cq-mobile-core gestartet wird.

Gerätefunktionen werden als Knoteneigenschaften gespeichert, und Knoten stellen Gerätemodelle dar. Sie können Abfragen verwenden, um die Funktionen eines Geräts oder eines Benutzeragenten abzurufen.

Da sich die WURFL™-Datenbank weiterentwickelt, müssen Sie sie möglicherweise anpassen oder ersetzen. Ihnen stehen die folgenden Optionen zur Aktualisierung der Mobilgerätedatenbank zur Verfügung:

Ersetzen Sie die Datei durch die neueste Version, wenn Sie über eine Lizenz verfügen, die diese Verwendung zulässt. Siehe „Installieren einer anderen WURFL-Datenbank“.
Verwenden Sie die Version, die in AEM verfügbar ist, und konfigurieren Sie eine Regex, die Ihren Benutzeragenten-Strings entspricht und auf ein vorhandenes WURFL™ -Gerät verweist. Siehe Hinzufügen einer auf regulären Ausdrücken basierenden Benutzeragenten-Zuordnung.

Testen der Zuordnung eines Benutzeragenten zu WURFL™-Funktionen testing-the-mapping-of-a-user-agent-to-wurfl-capabilities

Wenn ein Gerät auf Ihre mobile Website zugreift, erkennt AEM das Gerät, ordnet es gemäß seiner Funktionen einer Gerätegruppe zu und sendet eine Ansicht der Seite, die der Gerätegruppe entspricht. Die passende Gerätegruppe liefert die notwendigen Styling-Informationen. Die Zuordnungen können auf der Testseite für Mobile-Benutzeragenten getestet werden:

https://localhost:4502/etc/mobile/useragent-test.html

Installieren einer anderen WURFL™-Datenbank installing-a-different-wurfl-database

Die reduzierte WURFL™-Datenbank, die mit AEM installiert wird, ist eine Veröffentlichung, die vor dem
30. August 2011 vorlag. Wenn Ihre WURFL-Version nach dem 30. August 2011 veröffentlicht wurde, vergewissern Sie sich, dass Ihre Verwendung Ihrer Lizenz entspricht.

So installieren Sie eine WURFL™-Datenbank:

Erstellen Sie in CRXDE Lite den folgenden Ordner: /apps/wcm/mobile/devicespecs
Kopieren Sie die WURFL™-Datei in den Ordner.
Benennen Sie die Datei in wurfl.xml um.

AEM analysiert die Datei wurfl.xml automatisch und aktualisiert die Knoten unter /var/mobile/devicespecs.

NOTE

Wenn die vollständige WURFL™-Datenbank aktiviert ist, kann das Analysieren und die Aktivierung einige Minuten dauern. Sie können die Protokolle zu Fortschrittsinformationen ansehen.

Hinzufügen eines Regex-basierten Benutzeragenten-Abgleichs adding-a-regexp-based-user-agent-matching

Fügen Sie einen Benutzeragenten als regulären Ausdruck unter /apps/wcm/mobile/devicespecs/wurfl/regexp hinzu, um auf einen vorhandenen WURFL™-Gerätetyp zu verweisen.

Erstellen Sie in CRXDE Lite einen Knoten unterhalb von „/apps/wcm/mobile/devicespecs/regexp“, zum Beispiel apple_ipad_ver1.
Fügen Sie dem Knoten folgende Eigenschaften hinzu:
- regexp: regulärer Ausdruck, der Benutzeragenten definiert, zum Beispiel:*Mozilla.*iPad.*AppleWebKit.*Safari.*
- deviceId: Die Geräte-ID, wie in wurfl.xml definiert, zum Beispiel apple_ipad_ver1

Die obige Konfiguration führt dazu, dass Geräte, für die der Benutzeragent dem angegebenen regulären Ausdruck entspricht, der WURFL™-Geräte-ID apple_ipad_ver1 zugeordnet werden, sofern diese vorhanden ist.

Client-seitige Geräterkennung client-side-device-detection

In diesem Abschnitt wird beschrieben, wie Sie die Client-seitige Erkennung von AEM auf dem Gerät verwenden, um das Seiten-Rendering zu optimieren oder dem Client alternative Website-Versionen bereitzustellen.

AEM unterstützt die Client-seitige Erkennung auf der Basis von BrowserMap. BrowserMap wird in AEM als Client-Bibliothek unter /etc/clientlibs/browsermap bereitgestellt.

BrowserMap bietet Ihnen drei Strategien, die Sie verwenden können, um einem Client eine alternative Website bereitzustellen, die in der folgenden Reihenfolge verwendet werden:

Alternative Links
Gerätegruppenspezifische URL
Selektorbasierte URL

NOTE

Weitere Informationen zur Integration von Client-Bibliotheken finden Sie unter Verwenden Client-seitiger HTML-Bibliotheken.

Bereitstellen alternativer Links providing-alternate-links

Der OSGi-Service PageVariantsProvider kann alternative Links für Websites generieren, die zur selben Familie gehören. Um Sites so zu konfigurieren, dass sie von dem Dienst berücksichtigt werden, muss ein Knoten cq:siteVariant zum Knoten jcr:content aus dem Stammverzeichnis der Seite hinzugefügt werden.

Der Knoten cq:siteVariant muss die folgenden Eigenschaften aufweisen:

cq:childNodesMapTo – bestimmt, welchem Attribut des Link-Elements die untergeordneten Knoten zugeordnet werden. Es wird empfohlen, den Inhalt Ihrer Website so zu organisieren, dass die untergeordneten Elemente des Stammknotens den Stamm für eine Sprachvariante Ihrer globalen Website darstellen (z. B. /content/mysite/en, /content/mysite/de). In diesem Fall sollte der Wert von cq:childNodesMapTo dann hreflang sein.
cq:variantDomain – gibt an, welche Externalizer-Domain zum Generieren der absoluten URLs der Seitenvarianten verwendet wird. Wenn dieser Wert nicht festgelegt ist, werden die Seitenvarianten mit relativen Links erzeugt.
cq:variantFamily – gibt an, zu welcher Familie von Websites diese Seite gehört; mehrere gerätespezifische Darstellungen derselben Website sollten derselben Familie angehören;
media – speichert die Werte des Medienattributs des Link-Elements; Es wird empfohlen, den Namen der BrowserMap-registrierten DeviceGroups zu verwenden, damit die BrowserMap-Bibliothek die Clients automatisch an die richtige Variante der Website weiterleiten kann.

PageVariantsProvider und Externalizer pagevariantsprovider-and-externalizer

Wenn der Wert der Eigenschaft cq:variantDomain eines cq:siteVariant-Knotens nicht leer ist, generiert der PageVariantsProvider-Dienst absolute Links, die diesen Wert als konfigurierte Domain für den Externalizer-Dienst verwenden. Stellen Sie sicher, dass Sie den Externalizer-Service entsprechend Ihren Einstellungen konfigurieren.

NOTE

Bei der Verwendung von AEM gibt es mehrere Methoden zur Verwaltung der Konfigurationseinstellungen für solche Dienste. Weitere Informationen und empfohlene Praktiken finden Sie unter Konfigurieren von OSGi.

Definieren einer gerätegruppenspezifischen URL defining-a-device-group-specific-url

Wenn Sie keine alternativen Links verwenden möchten, können Sie für jede DeviceGroup. Adobe empfiehlt, eine eigene Client-Bibliothek zu erstellen, die die Client-Bibliothek browsermap.standard einbettet, aber die Gerätegruppen neu definiert.

BrowserMap ist so konzipiert, dass Gerätegruppendefinitionen überschrieben werden können, indem eine neue Gerätegruppe mit demselben Namen für das BrowserMap-Objekt aus Ihrer angepassten Client-Bibliothek erstellt und hinzugefügt wird.

NOTE

Weitere Details finden Sie unter Angepasste BrowserMap.

Definieren selektorbasierter URLs defining-selector-based-urls

Wenn keiner der vorherigen Mechanismen verwendet wurde, um eine alternative Site für BrowserMap anzugeben, werden Selektoren, die die Namen der DeviceGroups verwenden, zu den URLs hinzugefügt. In diesem Fall sollten Sie Ihre eigenen Servlets bereitstellen, die die Anfragen bearbeiten.

Zum Beispiel wird ein Gerät, das www.example.com/index.html durch BrowserMap als smartphone identifiziert, an www.example.com/index.smartphone.html. weitergeleitet.

Verwenden von BrowserMap auf Ihren Seiten using-browsermap-on-your-pages

Um die Standard-Client-Bibliothek von BrowserMap auf einer Seite zu verwenden, müssen Sie die Datei /libs/wcm/core/browsermap/browsermap.jsp mit einem Tag cq:include in den Abschnitt head Ihrer Seite einfügen.

<cq:include script="/libs/wcm/core/browsermap/browsermap.jsp" />

Neben dem Hinzufügen der BrowserMap-Client-Bibliothek in Ihren JSP-Dateien müssen Sie auch eine cq:deviceIdentificationMode-String-Eigenschaft, die auf client-side festgelegt ist, zum Knoten jcr:content unter dem Stammordner Ihrer Website hinzufügen.

Überschreiben des Standardverhaltens von BrowserMap overriding-browsermap-s-default-behaviour

Wenn Sie BrowserMap anpassen möchten, indem Sie die DeviceGroups überschreiben oder weitere Untersuchungen hinzufügen, sollten Sie Ihre eigene Client-seitige Bibliothek erstellen, in die Sie die Client-seitige Bibliothek browsermap.standard einbetten.

Außerdem müssen Sie die Methode BrowserMap.forwardRequest() in Ihrem JavaScript-Code manuell aufrufen.

NOTE

Weitere Informationen zur Integration von Client-Bibliotheken finden Sie unter Verwenden Client-seitiger HTML-Bibliotheken.

Nachdem Sie Ihre benutzerdefinierte BrowserMap-Client-Bibliothek erstellt haben, schlägt Adobe folgenden Ansatz vor:

Erstellen Sie eine Datei browsermap.jsp in Ihrem Programm.

code language-xml

code language-xml
<%@include file="/libs/foundation/global.jsp" %> <%@ taglib prefix="c" uri="https://java.sun.com/jsp/jstl/core" %> <%@ page import=" com.day.cq.wcm.api.variants.PageVariant, com.day.cq.wcm.api.variants.PageVariantsProvider, com.day.cq.wcm.api.devicedetection.DeviceIdentificationMode, com.day.cq.wcm.api.WCMMode" %> <% final PageVariantsProvider p = sling.getService(PageVariantsProvider.class); if(p == null) { throw new IllegalStateException("Missing PageVariantsProvider service"); } for(PageVariant v : p.getVariants(currentPage, slingRequest)) { final String curVar = v.getAttributes().get("data-current-variant"); String media = v.getAttributes().get("media"); if (media != null) { media = media.replaceAll(" ", ""); } %> <link rel="alternate" data-cq-role="site.variant" title="<%= xssAPI.encodeForHTMLAttr(v.getTitle()) %>" hreflang="<%= xssAPI.encodeForHTMLAttr(v.getAttributes().get("hreflang")) %>" media="<%= xssAPI.encodeForHTMLAttr(media) %>" href="<%= xssAPI.getValidHref(v.getURL()) %>" <% if(curVar != null) { %> data-current-variant="<%= curVar %>"<% } %> /> <% } Boolean browserMapEnabled = true; final DeviceIdentificationMode dim = sling.getService(DeviceIdentificationMode.class); String[] selectors = slingRequest.getRequestPathInfo().getSelectors(); boolean isPortletRequest = false; for (int i = 0; i < selectors.length; i++) { if ("portlet".equals(selectors[i])) { isPortletRequest = true; break; } } if (isPortletRequest) { log.debug("Request was made by a portlet container - BrowserMap will not be embedded"); } else { final WCMMode wcmMode = WCMMode.fromRequest(slingRequest); boolean shouldIncludeClientLib = false; if (WCMMode.EDIT != wcmMode && WCMMode.PREVIEW != wcmMode && WCMMode.DESIGN != wcmMode) { if (dim != null) { final String mode = dim.getDeviceIdentificationModeForPage(currentPage); shouldIncludeClientLib = DeviceIdentificationMode.CLIENT_SIDE.equals(mode); if (shouldIncludeClientLib) { browserMapEnabled = (Boolean) request.getAttribute("browsermap.enabled"); if (browserMapEnabled == null) { browserMapEnabled = true; } } } } %> <c:if test="<%= !browserMapEnabled %>"> <meta name="browsermap.enabled" content="false"> </c:if> <c:if test="<%= shouldIncludeClientLib %>"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <cq:includeClientLib categories="browsermap.custom"/> </c:if> <% } %>

<%@include file="/libs/foundation/global.jsp" %>
<%@ taglib prefix="c" uri="https://java.sun.com/jsp/jstl/core" %>
<%@ page import="
    com.day.cq.wcm.api.variants.PageVariant,
    com.day.cq.wcm.api.variants.PageVariantsProvider,
    com.day.cq.wcm.api.devicedetection.DeviceIdentificationMode,
    com.day.cq.wcm.api.WCMMode"
%>
<%
    final PageVariantsProvider p = sling.getService(PageVariantsProvider.class);
    if(p == null) {
        throw new IllegalStateException("Missing PageVariantsProvider service");
    }
    for(PageVariant v : p.getVariants(currentPage, slingRequest)) {
        final String curVar = v.getAttributes().get("data-current-variant");
        String media = v.getAttributes().get("media");
        if (media != null) {
            media = media.replaceAll(" ", "");
        }
%>
    <link
        rel="alternate"
        data-cq-role="site.variant"
        title="<%= xssAPI.encodeForHTMLAttr(v.getTitle()) %>"
        hreflang="<%= xssAPI.encodeForHTMLAttr(v.getAttributes().get("hreflang")) %>"
        media="<%= xssAPI.encodeForHTMLAttr(media) %>"
        href="<%= xssAPI.getValidHref(v.getURL()) %>"
        <% if(curVar != null) { %> data-current-variant="<%= curVar %>"<% } %>
    />
<%
    }
    Boolean browserMapEnabled = true;
    final DeviceIdentificationMode dim = sling.getService(DeviceIdentificationMode.class);
    String[] selectors  = slingRequest.getRequestPathInfo().getSelectors();
    boolean isPortletRequest = false;
    for (int i = 0; i < selectors.length; i++) {
        if ("portlet".equals(selectors[i])) {
            isPortletRequest = true;
            break;
        }
    }
    if (isPortletRequest) {
        log.debug("Request was made by a portlet container - BrowserMap will not be embedded");
    } else {
        final WCMMode wcmMode = WCMMode.fromRequest(slingRequest);
        boolean shouldIncludeClientLib = false;
        if (WCMMode.EDIT != wcmMode && WCMMode.PREVIEW != wcmMode && WCMMode.DESIGN != wcmMode) {
            if (dim != null) {
                final String mode = dim.getDeviceIdentificationModeForPage(currentPage);
                shouldIncludeClientLib = DeviceIdentificationMode.CLIENT_SIDE.equals(mode);
                if (shouldIncludeClientLib) {
                    browserMapEnabled = (Boolean) request.getAttribute("browsermap.enabled");
                    if (browserMapEnabled == null) {
                        browserMapEnabled = true;
                    }
                }
            }
        }
%>
        <c:if test="<%= !browserMapEnabled %>">
            <meta name="browsermap.enabled" content="false">
        </c:if>
        <c:if test="<%= shouldIncludeClientLib %>">
            <meta name="viewport" content="width=device-width, initial-scale=1.0">
            <cq:includeClientLib categories="browsermap.custom"/>
        </c:if>
<%
    }
%>

Fügen Sie die Datei broswermap.jsp in Ihren Kopfabschnitt ein.

code language-xml
`<cq:include script="browsermap.jsp" />`

Ausschließen von BrowserMap von bestimmten Seiten excluding-browsermap-from-certain-pages

Wenn Sie die BrowserMap-Bibliothek aus einigen Seiten ausschließen möchten, für die Sie keine Client-Erkennung benötigen, können Sie ein Anforderungsattribut hinzufügen:

<%
request.setAttribute("browsermap.enabled", false);
%>

Dadurch wird das Skript /libs/wcm/core/browsermap/browsermap.jsp dazu gebracht, der Seite ein Meta-Tag hinzuzufügen, damit BrowserMap keine Erkennung durchführt:

<meta name="browsermap.enabled" content="false">

Testen einer bestimmten Version einer Website testing-a-specific-version-of-a-web-site

Normalerweise leitet das BrowserMap-Skript Besucherinnen und Besucher immer an die am besten geeignete Version der Website weiter. Normalerweise werden Besucherinnen und Besucher bei Bedarf auf die Desktop- oder auf die Mobile-Site umgeleitet.

Sie können das Gerät bei jeder Anfrage zwingen, eine bestimmte Version einer Website zu testen, indem Sie den Parameter device zu Ihrer URL hinzufügen. Die folgende URL rendert die mobile Version der Geometrixx Outdoors-Website.

https://localhost:4502/content/geometrixx-outdoors/en.html?wcmmode=disabled&device=smartphone

NOTE

Der Parameter wcmmode wird auf disabled gesetzt, um das Verhalten einer Veröffentlichungsinstanz zu simulieren.

Der überschriebene Gerätewert wird in einem Cookie gespeichert, sodass Sie Ihre Website durchsuchen können, ohne den device-Parameter zu jeder URL hinzuzufügen.

Als Konsequenz müssen Sie dieselbe URL aufrufen, wenn device auf browser eingestellt ist, um zur Desktop-Version der Website zurückzukehren.

NOTE

BrowserMap speichert den überschriebenen Gerätewert in einem Cookie namens BMAP_device. Durch das Löschen dieses Cookies wird sichergestellt, dass CQ die entsprechende Version der Website gemäß Ihrem aktuellen Gerät (z. B. Desktop oder Mobile) bereitstellt.

Mobile Anfrageverarbeitung mobile-request-processing

AEM verarbeitet eine Anfrage, die von einem Mobilgerät ausgegeben wird, das zur Touch-Gerätegruppe gehört, wie folgt:

Ein iPad sendet eine Anfrage an die AEM-Veröffentlichungsinstanz, zum Beispiel https://localhost:4503/content/geometrixx_mobile/en/products.html.
AEM ermittelt, ob die Site der angeforderten Seite eine Mobile-Site ist (indem überprüft wird, ob die Seite /content/geometrixx_mobile der ersten Ebene die Mobile-Seitenkomponente erweitert). Wenn ja:
AEM sucht die Gerätefunktionen basierend auf dem Benutzeragenten im Anfrage-Header.
AEM ordnet die Gerätefunktionen der Gerätegruppe zu und legt touch als Gerätegruppenselektor fest.
AEM leitet die Anfrage an https://localhost:4503/content/geometrixx_mobile/en/products.touch.html. weiter.
AEM sendet die Antwort an das iPad:
- products.touch.html wird auf die übliche Weise gerendert und kann zwischengespeichert werden.
- Die Rendering-Komponenten verwenden Selektoren, um die Präsentation anzupassen.
- AEM fügt den Mobile-Selektor automatisch allen internen Links auf der Seite hinzu.

Statistiken statistics

Sie können einige Statistiken zur Anzahl der Anfragen erhalten, die von Mobilgeräten an den AEM-Server gesendet wurden. Die Anzahl der Anfragen kann wie folgt aufgeteilt werden:

pro Gerätegruppe und Gerät
pro Jahr, Monat und Tag

So zeigen Sie die Statistiken an:

Gehen Sie zur Tools-Konsole.
Öffnen Sie unter Tools > Mobile die Seite Gerätestatistik.
Klicken Sie auf den Link, um die Statistiken für ein bestimmtes Jahr, einen bestimmten Monat oder einen bestimmten Tag anzuzeigen.

Die Statistikseite sieht folgendermaßen aus:

screen_shot_2012-02-01at24353pm

NOTE

Die Seite Statistik wird erstellt, wenn ein Mobilgerät zum ersten Mal auf AEM zugreift und erkannt wird. Davor ist sie nicht verfügbar.

Wenn Sie einen Eintrag in der Statistik generieren müssen, können Sie folgendermaßen vorgehen:

Verwenden Sie ein Mobilgerät oder einen Emulator (z. B. „https://chrspederick.com/work/user-agent-switcher/“ in Firefox).
Fordern Sie eine Mobile-Seite für die Autoreninstanz an, indem Sie den Autorenmodus deaktivieren, z. B.:
https://localhost:4502/content/geometrixx_mobile/en/products.html?wcmmode=disabled

Die Statistikseite ist jetzt verfügbar.

Unterstützen von Seiten-Caching für „Link an einen Freund senden“ supporting-page-caching-for-send-link-to-a-friend-links

Mobile-Seiten können im Dispatcher zwischengespeichert werden, da Seiten, die für eine Gerätegruppe gerendert werden, in der Seiten-URL durch den Gerätegruppenselektor unterschieden werden, z. B. /content/mobilepage.touch.html. Eine Anfrage an eine Mobile-Seite ohne einen Selektor wird niemals zwischengespeichert, da in diesem Fall die Geräteerkennung arbeitet und schließlich zu der entsprechenden Gerätegruppe (oder „Nomatch“) umgeleitet wird. Eine mit einem Gerätegruppenselektor gerenderte Mobile-Seite wird vom Link-Rewriter verarbeitet, der alle Links innerhalb der Seite so umschreibt, dass sie auch den Gerätegruppenselektor enthält. Dadurch wird verhindert, dass die Geräteerkennung bei jedem Klick auf eine bereits qualifizierte Seite erneut durchgeführt wird.

Daher könnte das folgende Szenario eintreten:

Benutzerin Alice wird zu coolpage.feature.html umgeleitet und sendet diese URL an einen Freund Bob, der mit einem anderen Client, der in die touch-Gerätegruppe fällt, darauf zugreift.

Wenn coolpage.feature.html von einem Frontend-Cache geliefert wird, erhält AEM keine Chance, die Anfrage zu analysieren, um herauszufinden, dass der mobile Selektor nicht mit dem neuen Benutzeragenten übereinstimmt, und Bob erhält die falsche Darstellung.

Um dieses Problem zu lösen, können Sie auf den Seiten eine einfache Auswahlbenutzeroberfläche einfügen, über die Endbenutzer die Gerätegruppe überschreiben können, die von AEM ausgewählt wurde. Im obigen Beispiel ermöglicht ein Link (oder ein Symbol) auf der Seite Endbenutzenden, zu coolpage.touch.html zu wechseln, wenn sie glauben, dass ihr Gerät dafür gut genug ist.

recommendation-more-help

19ffd973-7af2-44d0-84b5-d547b0dffee2