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.
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.
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:
<Interface>Impl
, d.h. ReaderImpl
.<Variant><Interface>
, d.h. JcrReader
und FileSystemReader
.Abstract<Interface>
oder Abstract<Variant><Interface>
benannt.com.adobe.product.module
. Jedes Maven Artefakt- oder OSGi-Bundle muss ein eigenes Paket haben.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:
Unklar |
Clear |
int d; /elapsed time in days |
int elapsedTimeInDays; |
/get tagged images |
public List getTaggedImages() {} |
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.
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.
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.
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.
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.
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.
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:
Bei JavaScript sollte console.log nur während der Entwicklung genutzt werden und alle Protokollaussagen sollten vor der Veröffentlichung entfernt werden.
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.