AEM 6.4 ha llegado al final de la compatibilidad ampliada y esta documentación ya no se actualiza. Para obtener más información, consulte nuestra períodos de asistencia técnica. Buscar las versiones compatibles here.
La inclusión de scripts en JSP dificulta la depuración de problemas en el código. Además, al incluir scripts en JSP, es difícil separar la lógica empresarial de la capa de vista, lo que constituye una violación del principio de responsabilidad única y del patrón de diseño de MVC.
El código se escribe una vez, pero se lee muchas veces. Pasar algún tiempo por delante para limpiar el código que escribimos dará dividendos en el camino ya que nosotros y otros desarrolladores necesitamos leerlo más tarde.
Idealmente, otro programador no debería tener que abrir un módulo para entender lo que hace. Asimismo, deben poder decir lo que hace un método sin leerlo. Cuanto mejor podamos suscribirnos a estas ideas, más fácil será leer nuestro código y más rápido podremos escribir y cambiar nuestro código.
En la base de código de AEM, se utilizan las siguientes convenciones:
<Interface>Impl
, es decir, ReaderImpl
.<Variant><Interface>
, es decir, JcrReader
y FileSystemReader
.Abstract<Interface>
o Abstract<Variant><Interface>
.com.adobe.product.module
. Cada artefacto Maven o paquete OSGi debe tener su propio paquete.Tenga en cuenta que estas convenciones no necesariamente tienen que aplicarse a implementaciones de clientes, pero es importante que las convenciones se definan y se adhieran a ellas para que el código pueda mantenerse.
Idealmente, los nombres deberían revelar su intención. Una prueba de código común para los casos en los que los nombres no están tan claros como deberían ser es la presencia de comentarios que explican para qué sirve la variable o el método:
Unclear |
Borrar |
int d; //tiempo transcurrido en días |
int elapsedTimeInDays; |
//obtener imágenes etiquetadas |
public List getTaggedImages() {} |
DRY indica que el mismo conjunto de código nunca debe duplicarse. Esto también se aplica a cosas como literales de cadena. La duplicación de código abre la puerta a defectos cada vez que algo tiene que cambiar y debe buscarse y eliminarse.
Las reglas CSS deben ser específicas del elemento de destino en el contexto de la aplicación. Por ejemplo, una regla CSS aplicada a .content.center sería demasiado amplio y podría terminar impactando en gran cantidad de contenido en su sistema, lo que requeriría que otros anularan este estilo en el futuro. .myapp-centertext sería una regla más específica ya que especifica centrado text en el contexto de la aplicación.
Cuando una API está en desuso, siempre es mejor encontrar el nuevo enfoque recomendado en lugar de depender de la API en desuso. Esto garantizará que las actualizaciones sean más fluidas en el futuro.
Cualquier cadena que no proporcione un autor debe envolverse en una llamada al diccionario i18n de AEM mediante I18n.get() en JSP/Java y CQ.I18n.get() en JavaScript. Esta implementación devolverá la cadena que se le pasó si no se encuentra ninguna implementación, por lo que ofrece la flexibilidad de implementar la localización después de implementar las funciones en el idioma principal.
Aunque las rutas en el JCR no deben contener espacios, su presencia no debe provocar que el código se rompa. Jackrabbit proporciona una clase de utilidad de texto con escape() y escapePath() métodos. Para JSP, la interfaz de usuario de Granite expone un granite:encodeURIPath() EL función.
AEM proporciona una API XSS para limpiar fácilmente los parámetros y garantizar la seguridad frente a ataques de scripts entre sitios. Además, HTL tiene estas protecciones integradas directamente en el idioma de creación de plantillas. Puede descargar una hoja de referencia de API en Desarrollo: Directrices y prácticas recomendadas.
Para el código Java, AEM admite slf4j como la API estándar para el registro de mensajes y debe usarse junto con las configuraciones disponibles a través de la consola OSGi para mantener la coherencia en la administración. Slf4j expone cinco niveles de registro diferentes. Se recomienda utilizar las siguientes directrices al elegir el nivel en el que se debe registrar un mensaje:
En el caso de JavaScript, console.log solo debe utilizarse durante el desarrollo y todas las instrucciones de registro deben eliminarse antes del lanzamiento.
Evite copiar código sin comprender qué hace. Cuando haya dudas, siempre es mejor preguntar a alguien que tenga más experiencia con el módulo o API en los que no esté claro.