Tipps zum Programmieren

So oft wie möglich TagLibs oder HTL verwenden

Das Einschließen von Scriptlets in JSPs erschwert das Debugging von Fehlern im Code. Durch die Einbeziehung von Skripten in JSPs ist es außerdem schwierig, Geschäftslogik und Ansicht von der Ebene zu trennen, was eine Verletzung des Prinzips "Einfache Verantwortung"und des MVC-Designmusters darstellt.

Lesbaren Code schreiben

Code wird einmal geschrieben, aber viele Male gelesen. Wenn wir etwas Zeit vorn für die Bereinigung des Codes aufwenden, den wir schreiben, werden Dividenden auf der Straße ausgezahlt, wie wir und andere Entwickler es später lesen müssen.

Namen wählen, die den Zweck beschreiben

Idealerweise sollte ein anderer Programmierer kein Modul öffnen müssen, um zu verstehen, was es tut. Ebenso sollten sie in der Lage sein, zu erkennen, was eine Methode tut, ohne sie zu lesen. Je besser wir diese Ideen abonnieren können, desto leichter wird es sein, unseren Code zu lesen und desto schneller können wir unseren Code schreiben und ändern.

Für AEM-Codes gelten die folgenden Konventionen:

• Eine einzelne Implementierung einer Schnittstelle trägt den Namen <Interface>Impl, d.h. ReaderImpl.
• Mehrere Implementierungen einer Schnittstelle haben den Namen <Variant><Interface>, d.h. JcrReader und FileSystemReader.
• Abstrakte Basisklassen werden mit Abstract<Interface> oder Abstract<Variant><Interface> benannt.
• Pakete haben den Namen com.adobe.product.module. Jedes Maven Artefakt- oder OSGi-Bundle muss ein eigenes Paket haben.
• Java-Implementierungen werden in einem impl-Paket unter ihrer API platziert.

Beachten Sie, dass diese Konventionen nicht notwendigerweise für Kundenimplementierungen gelten müssen. Es ist jedoch wichtig, dass Konventionen definiert und eingehalten werden, sodass der Code verwaltbar bleibt.

Idealerweise sollten Namen den Zweck beschreiben. Ein üblicher Code-Test für den Fall, dass Namen nicht so eindeutig sind, wie sie sein sollten, besteht darin, dass Kommentare vorhanden sind, die erklären, wofür die Variable oder Methode verwendet wird:

Wiederholungen vermeiden

Dieses Prinzip sieht vor, dass derselbe Codesatz niemals dupliziert werden sollte. Dies gilt auch für Dinge wie Zeichenfolgenliterale. Codeduplizierung öffnet die Tür für Defekte, wenn etwas geändert werden muss und sollte gesucht und beseitigt werden.

Blanke CSS-Regeln vermeiden

CSS-Regeln sollten speziell auf das Zielelement im Kontext Ihrer Anwendung ausgerichtet sein. Eine CSS-Regel, die auf .content.center angewendet wird, wäre beispielsweise übermäßig breit gefasst und könnte letztendlich viele Inhalte auf Ihrem System beeinträchtigen, sodass andere diesen Stil in Zukunft überschreiben müssen. .myapp- centerText wäre eine spezifischere Regel, da im Kontext Ihrer Anwendung zentrierter ** Text angegeben wird.

Verwendung veralteter APIs vermeiden

Wenn eine API veraltet ist, ist es besser, den neuen empfohlenen Ansatz zu suchen anstatt die veraltete API zu verwenden. Dadurch werden in Zukunft reibungslosere Upgrades sichergestellt.

Lokalisierbaren Code schreiben

Alle Strings, die nicht von einem Autor bereitgestellt werden, sollten in einem Aufruf des i18n-Wörterbuchs von AEM über I18n.get() in JSP/Java und CQ.I18n.get() in JavaScript zusammengefasst werden. Diese Implementierung gibt die Zeichenfolge zurück, die an sie übergeben wurde, wenn keine Implementierung gefunden wurde. Auf diese Weise wird die Flexibilität bei der Implementierung der lokale Anpassung nach der Implementierung der Funktionen in der Hauptsprache Angebot.

Ressourcenpfade zur Sicherheit maskieren

Zwar sollten Pfade im JCR keine Leerzeichen enthalten, aber der Code sollte nicht fehlschlagen, wenn Leerzeichen vorhanden sind. Jackrabbit stellt eine Text-Hilfsklasse mit den Methoden escape() und escapePath() bereit. Bei JSPs stellt die Granite-Benutzeroberfläche eine granite:encodeURIPath() EL-Funktion bereit.

Zur Absicherung vor Cross-Site-Scripting-Angriffen die XSS-API und/oder HTL nutzen

AEM stellt eine XSS-API bereit, mit der Sie Parameter einfach bereinigen und die Absicherung vor Cross-Site-Scripting-Angriffen gewährleisten können. Zusätzlich hat HTL diese Schutzmechanismen direkt in die Vorlagensprache integriert. Unter Entwicklung - Richtlinien und Best Practices kann ein API-Datenblatt heruntergeladen werden.

Angemessene Protokollierung implementieren

Für Java-Code unterstützt AEM slf4j als Standard-API für die Protokollierung von Meldungen. Für eine konsistente Administration sollte die API in Verbindung mit den Konfigurationen genutzt werden, die über die OSGi-Konsole verfügbar sind. Slf4j umfasst fünf verschiedene Protokollierungsebenen. Wir empfehlen, bei der Auswahl der Ebene, auf der eine Meldung protokolliert werden soll, die folgenden Richtlinien anzuwenden:

• ERROR: Wenn etwas im Code nicht funktioniert und die Verarbeitung nicht fortgesetzt werden kann. Dies geschieht oft aufgrund einer unerwarteten Ausnahme. In der Regel ist es hilfreich, Stapelspuren in diese Szenarien einzubeziehen.
• WARN: Wenn etwas nicht richtig funktioniert hat, aber die Verarbeitung fortgesetzt werden kann. Dies ist häufig das Ergebnis einer erwarteten Ausnahme, z. B. einer PathNotFoundException.
• INFO: Informationen, die bei der Überwachung eines Systems hilfreich sein dürften. Denken Sie daran, dass dies der Standard ist und dass die meisten Kunden dies auf ihren Umgebung beibehalten werden. Verwenden Sie diese Ebene daher nicht zu häufig.
• DEBUG: Informationen der unteren Ebene zur Verarbeitung. Hilfreich, wenn ein Problem zusammen mit dem Support behoben wird.
• TRACE: Die niedrigste Ebene von Informationen, z. B. das Aufrufen/Beenden von Methoden. Dies wird in der Regel nur von Entwicklern verwendet.

Bei JavaScript sollte console.log nur während der Entwicklung genutzt werden und alle Protokollaussagen sollten vor der Veröffentlichung entfernt werden.

Nicht durchdachte Programmierung vermeiden

Vermeiden Sie es, Code zu kopieren, ohne zu wissen, was er tut. Im Zweifelsfall ist es immer am besten, jemanden zu fragen, der über mehr Erfahrung mit dem Modul oder der API verfügt, auf dem Sie nicht klar sind.