Das Einschließen von Scriptlets in JSPs erschwert das Debugging von Fehlern im Code. Darüber hinaus ist es schwierig, durch die Einbeziehung von Skripten in JSPs die Geschäftslogik von der Ansichtsebene zu trennen, was einen Verstoß gegen das Prinzip der Einzelverantwortung und das MVC-Designmuster darstellt.
Code wird einmal geschrieben, aber viele Male gelesen. Wenn wir etwas Zeit im Voraus für die Bereinigung des Codes aufwenden, den wir schreiben, werden wir Dividenden auf der Straße auszahlen, da 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. Genauso sollten sie in der Lage sein, zu sagen, was eine Methode tut, ohne sie zu lesen. Je besser wir diese Ideen abonnieren können, desto einfacher wird es sein, unseren Code zu lesen und desto schneller werden wir in der Lage sein, unseren Code zu schreiben und zu ä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>
.com.adobe.product.module
. Jedes Maven-Artefakt oder OSGi-Bundle muss über ein eigenes Paket verfügen.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 gängiger Codetest für den Fall, dass Namen nicht so klar 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. Code-Duplizierung öffnet die Tür für Fehler, wann immer sich etwas ändern muss und gesucht und beseitigt werden sollte.
CSS-Regeln sollten speziell auf das Zielelement im Kontext Ihrer Anwendung ausgerichtet sein. Beispiel: eine CSS-Regel, die auf .content .center würde übermäßig breit angelegt sein und potenziell viele Inhalte in Ihrem System beeinflussen, sodass andere diesen Stil in Zukunft überschreiben müssen. .myapp-centertext wäre eine spezifischere Regel, da sie die Zentrierung angibt. text im Kontext Ihrer Anwendung.
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 gewährleistet.
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 wird. Dies bietet daher die Flexibilität, die Lokalisierung nach der Implementierung der Funktionen in der Primärsprache zu implementieren.
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. Für JSPs stellt die Granite-Benutzeroberfläche eine granite:encodeURIPath() EL -Funktion.
AEM stellt eine XSS-API bereit, mit der Sie Parameter einfach bereinigen und die Absicherung vor Cross-Site-Scripting-Angriffen gewährleisten können. Darüber hinaus sind diese Schutzmaßnahmen in HTL direkt in die Vorlagensprache integriert. Ein API-Infoblatt kann hier heruntergeladen werden: Entwicklung - Richtlinien und Best Practices.
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, über die Sie nicht genau Bescheid wissen.