Best Practices Framework Fatwire Mejores Prácticas Plan de Calidad de los Proyectos FatWire en ICM 14 de mayo de 2008 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 1 Best Practices Framework Fatwire Histórico de Revisiones Revisión Fecha 1.0 1.1 27 abril de 2007 03 junio de 2008 1.2 15 septiembre de 2008 04 diciembre de 2008 14 mayo 2009 1.3 1.4 1.5 12 abril 2011 Causas Primera versión 1. nombre de template, cselement, siteentry han de estar prefijados con el código 2. flushcatalog de tabla mismo nombre SystemInfo 3. ics.GetVar 4. uso de scatter 5. sql en el codigo Cambiado el formato de la cabecera 1. flush de IList 1. Asset query (columnas obligatorias) 2. flush de ilist 3. systemsql y deftable dinamico 4. Reclasificacion de normas recomendaciones prohibiciones assetset:setsearchedassets y parámetro fixedlist por Edición Nombre Firma Fecha Preparado por: Revisado por: Aprobado por: Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 2 Best Practices Framework Fatwire ÍNDICE 1 2 3 4 5 6 Objetivos .......................................................................................................... 4 Codificación ...................................................................................................... 6 2.1 Normas genéricas.................................................................................... 6 2.2 Normas ContentServer ........................................................................... 11 Assets Básicos ............................................................................................. 11 Assets Flexibles ........................................................................................... 13 Programación .............................................................................................. 16 Diseño de assets ............................................................................................. 21 3.1 Cuándo usar assets básicos .................................................................... 21 3.2 Cuándo usar assets flexibles ................................................................... 21 3.3 Uso de subtipos .................................................................................... 22 Diseño de páginas y caché ................................................................................ 22 4.1 Diseño del interfaz de edición de ContentServer ........................................ 22 4.2 Diseño de páginas ................................................................................. 23 4.3 Diseño de la caché ................................................................................ 25 4.4 Expiración de Satellite Server ................................................................. 25 Nomenclatura de contenidos ............................................................................. 30 Documentos relacionados ................................................................................. 34 Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 3 Best Practices Framework Fatwire 1 Objetivos El objeto de este documento es proporcionar una serie de recomendaciones de buenas prácticas para el diseño e implementación de iniciativas con ContentServer. No existen unas buenas prácticas absolutas. Los puntos a cubrir serán los siguientes: - Programación en ContentServer. o Codificación: o Diseño de Assets. o - Normas genéricas. Normas de ContentServer: Assets básicos. Assets flexibles. Programación. Cuándo usar assets básicos. Cuándo usar assets flexibles. Uso de subtipos. Diseño de páginas y caché. Recomendaciones en el uso del Framework. o Nomenclatura de contenidos. o Nomenclaturas. Gestión de propiedades. Subtipos y asociaciones. Clases Java y Jars. Documentos relacionados: Tipos de contenidos. Uso de las hojas de estilo. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 4 Best Practices Framework Fatwire Programación en ContentServer o Codificación: Normas genéricas. Normas de ContentServer: Assets básicos. Assets flexibles. Programación. o Diseño de Assets. Cuándo usar assets básicos. Cuándo usar assets flexibles. Uso de subtipos. o Diseño de páginas y caché. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 5 Best Practices Framework Fatwire 2 Codificación 2.1 Normas genéricas Recomendación: Obtener un estilo común de programación. programación clara, sencilla de mantener y de entender. Hacer una Observar las recomendaciones de: http://java.sun.com/developer/technicalArticles/javaserverpages/code_convention/ y http://java.sun.com/docs/codeconv/ Prohibición: Norma de importación de clases. Evitar sobrecargar el “classloader”. Especificar los “imports java” a nivel de clase. No dejar importaciones del tipo “paquete.*” Recomendación: Mantenimiento del código. Evitar definir clases y métodos java dentro de los códigos JSP. Recomendación: Restringir el uso de librerías java externas para evitar: o o o Incompatibilidades con otras clases / librerías. Control de dependencias. Desfase en librerías cuyo ciclo de vida se lleva a cabo por terceros. “Hot deploy”: El mantenimiento del portal se complica al tener que parar/arrancar los servidores. Uso de librerías externas: Si son de carácter genérico y mantenidas por terceros hay que justificar su uso y plantear su ciclo de mantenimiento. Recomendación: Control de parámetros externos a la aplicación mediante archivos de propiedades. A tener en cuenta: o o o Posibles desajustes de parámetros en los pasos de software entre entornos. Tener censados los parámetros involucrados en el software. Evitar reiniciar el servidor para cambiar un parámetro. Se tiene que justificar el uso de parámetro y propiedades externos al gestor de contenidos. Hay que documentarlos en el “documento de entregas”. Se tienen que indicar qué parámetros se pueden cambiar sin reiniciar el servidor de aplicaciones y cuáles no. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 6 Best Practices Framework Fatwire Recomendación: Incluir cabeceras en todos los desarrollos (javascript, JSP y Java) Se tiene que identificar cada elemento de código a través de varios campos: Cabecera: <%-Elemento: Fecha: Autor: Descripcion: Entrada: “Nombre del codigo y su ubicación” “Fecha de creación dd/mm/yyyy” “Autor / Empresa Consultora / Centro Directivo” “Descripcion de funcionamiento del elemento” “Parámetros de entrada” Argumento-n (Obligatorio/Opcional)(Var/IList/Obj) Descripción Salida: “Parametros de salida” Argumento-n (Var/IList/Obj) Descripción Dependencias con otros elementos de codigo / plantillas: Modificaciones: “Historico de cambios:” “Version / Fecha / Autor / Motivacion” --%> NOTA: Se recomienda modificar los elementos de ContenServer que ofrecen las plantillas de creación de CSElements y Templates para incluir esas cabeceras así como las tlds más frecuentemente usadas en los desarrollos: Los elementos a modificar son: OpenMarket/Xcelerate/AssetType/CSElement/ModelJsp OpenMarket/Xcelerate/AssetType/Template/ModelJsp Recomendación: Controlar los posibles errores dentro de la navegación del usuario: o o o o - Evitar mostrar al usuario mensajes de error incontrolados. Controlar los errores mediante el chequeo de variables o propiedades: posibles valores vacíos, etc. En aquellos casos en los que se controlen los errores, evitar mostrar mensajes incomprensibles para el usuario: Redirigir a las pantallas de error estándar. Facilitar al usuario una opción alternativa: volver, intentar más tarde, etc. Usar páginas estándar y evitar sacar errores del sistema al usuario. Poner secciones “try – catch” en aquellas secciones de código que lo requieran. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 7 Best Practices Framework Fatwire No capturar excepciones con controlador “catch” vacío. Advertir al usuario del error cuando sea necesario exclusivamente. Recomendación: No poner literales a fuego (o “cableados”) en las páginas en la medida de lo posible y según las necesidades del portal (multiidioma o no). Parametrizar los mensajes. Evitar definir clases y métodos java dentro de los códigos JSP. Prohibición: Evitar que en las páginas HTML procesadas aparezcan comentarios del código Java / JSP. Poner comentarios Java o JSP al código, nunca comentarios HTML/XML. MAL: <a name="top"></a><!-- no quitarlo ya q es para q funcione el boton de subir en mac -> <!-- **************** CABECERA PRINCIPAL*************************** <ics:callelement element="Comunes/Cabecera"/> --> BIEN: <a name="top"></a><%-- no quitarlo ya q es para q funcione el boton de subir en mac -%> <%-- **************** CABECERA PRINCIPAL*************************** <ics:callelement element="Comunes/Cabecera"/> --%> Recomendación: Minimizar el código Javascript en las páginas JSP. Crear librerías Javascript basándose en criterios de: Reutilización, tamaño del código. Documentar las librerías “.js”. Indicar en los “documentos de pase” que librerías son externas (de terceros) y cuáles desarrolladas a medida. Prohibición: Evitar código potencialmente peligroso. Sentencias prohibidas: System.XXX y usos de la clase Runtime. Evitar código de “bajo rendimiento” y que violen las restricciones de seguridad: - Usar “StringBuffer”. Bucles con control de finalización finito. Crear accesos a disco. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 8 Best Practices Framework Fatwire - Crear conexiones remotas. No usar variables a fuego en el código”: - Sus valores pueden ser inválidos en distintos entornos o con el paso del tiempo. Evitar usar parámetros de uso confidencial: Usuarios y contraseñas. Direcciones IP. Recursos de disco o de red. Prohibición: Uso de “select *” en el código. Se recomienda recuperar sólo los campos que se necesiten. Esta norma se extiende a las consultas de la tabla SystemSQL y las de los assets de tipo Query. Además en el caso de un asset Query y para evitar mensajes de error en el log, se han de recuperar los campos description, updateddate y flextemplateid (éste último sólo si se trata de assets flexibles). Esto evitará que ante posibles cambios en la base de datos se produzcan errores en la recuperación de datos. Prohibición: cualquier tipo de sentencia sql (select, insert, update, delete …) insertada en el código, salvo causa muy justificada. Existe una tabla SystemSQL donde se almacenan todas las consultas. La centralización de las consultas facilita su mantenimiento. También se puede utilizar el tipo de contenido Query para esta gestión. Si dentro de la sentencia la tabla principal sobre la que se está haciendo la consulta es, por ejemplo, Banner, tenemos que especificar Banner dentro del campo deftable. Para el caso de que la consulta sea totalmente dinámica o que se haya de cachear el resultset dinámicamente según de la ejecución de la sentencia el campo deftable ha de dejarse en blanco. En el código, a la hora de ejecutar esta query, se ha de crear una variable llamada tablename con el valor adecuado. Ejemplo: <% ... ics.SetVar("tablename", attributetypename); ics.SetVar("sqlattributetype", attributetypename); ics.SetVar("sqlattributename", attraux); IList ilist = ics.CallSQL(sqlAttributeType, null, -1, true, new StringBuffer()); Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 9 Best Practices Framework Fatwire Ejemplo (uso de Query): El uso de consultas a través del contenido Query facilita la publicación de estas consultas, a la vez que no se pierde la funcionalidad existente a través de SystemSQL si se utiliza en conjunto con la función ics.ResolveVariables(). Por ejemplo, un código como el siguiente: <% ... IList ajList = ics.CallSQL( "Ruta/SystemSQL/cualquiera , -1, true, new StringBuffer() ); ... Se sustituye por un contenido de tipo "Query" parametrizado y el siguiente código: <asset:load name="lista" field="name" value="QUERY" type="Query" site='<%=ics.GetVar("site")%>'/> <asset:get name="lista" field="sqlquery"/> <ics:sql sql='<%=ics.ResolveVariables(ics.GetVar("sqlquery"))%>' listname="ajList" table="<valor_deftable>"/> <% IList ajList = ics.GetList("ajList"); ... Prohibición: Al usar los tags ics.CallSQL e ics.sql se ha de poner el parámetro bCache a true para activar la caché de resulset. (salvo razón de peso) Ejemplo: IList listQyFaq = ics.CallSQL("common/Faq/qFaqSPA",null,-1,true,errStr); Recomendación: Hacer un uso inteligente en la inserción de trazas en el código. Consultar como referencia genérica las mejores prácticas descritas en: http://jakarta.apache.org/commons/logging/guide.html#JCL_Best_Practices ContentServer escribe mensajes de log a través de la clase ICS y el método “LogMsg()” con severidad INFO. Este método está deprecado y se desaconseja su uso. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 10 Best Practices 2.2 Framework Fatwire Normas ContentServer Assets Básicos Normas El nombre con el cual se crea un asset tiene que estar en singular y debe ser identificativo del asset que representa. Cada documento de creación de un asset tiene que tener obligatoriamente un parámetro DEFDIR, el cuál determina la ruta donde se albergarán los elementos de “upload” o carga del asset (campos “url”). La descripción de un asset tiene que ser clara y entendible por el usuario. Longitud limitada, debido a que entre otras características la descripción es la información que aparece en la herramienta, en el combo para hacer las búsquedas. El acceso restringido a los assets se controlará a través de los menús de inicio y workflows. También se puede emplear la funcionalidad SAFE de ContentServer para restringir el acceso a contenidos a través de funciones de privilegio y roles. Recomendaciones Hay que comentar y documentar los elementos personalizados para una rápida localización. A continuación se detallan algunos de los elementos que determinan la estructura y funcionalidad de un asset: o AppendSelectDetails: Define la consulta de Búsqueda o AppendSelectDetailsSE: También define la consulta para un motor de búsqueda. o ContentDetails: Muestra el detalle de cada asset. o ContentForm: Formulario de introducción de contenido. o IndexAdd: Crea índices del motor de búsqueda. o IndexCreateVerity: Crea Índices de Verity (Motor de búsqueda). o IndexReplace: Reemplaza índices del motor de búsqueda. o PostUpdate: Acciones a realizar después de grabar información. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 11 Best Practices Framework Fatwire o PreUpdate: Acciones a realizar antes de grabar información. o SearchForm: Formulario de búsqueda avanzada. o SimpleSearch: Búsqueda Simple o Tile: Muestra el resultado de una búsqueda Controlar el peso de los atributos que componen un asset (Campos y elementos que se manejan en el formulario de creación así como imágenes y documentos asociados). Controlar la longitud de los campos de texto que se introducen en el formulario de creación (Máximo 2000 caracteres), si sobrepasa este máximo definir un campo tipo URL para almacenar en él la información. Se permitirá el uso de consultas que accedan a assets cuando se tenga que realizar un filtrado de assets por valores de fechas o cualquier otro atributo, que evite cargar todos los assets de un determinado tipo, siempre y cuando se justifique. Al recuperar assets con sentencias SQL, NO OLVIDAR realizar el control de dependencias adecuado en cada caso (render:unknowndeps y/o render:logdep) Usar solo assets básicos para aquellos tipos de contenidos que se sabe que no va a cambiar su definición con el tiempo, y que tiene un número de campos muy pequeño. Pensar en las ventajas que ofrecen los assets flexibles antes de diseñar uno básico. Prohibiciones Queda prohibido el uso de asset:scatter sino se van a usar todos los campos. Este tag carga todo el contenido en memoria. Hay que utilizar asset:get para recuperar un campo Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 12 Best Practices Framework Fatwire Assets Flexibles Normas Todas las búsquedas se harán por atributos. No se pueden hacer búsquedas por campos estándar (id, name, description,updateddate,…) , con la excepción del campo ‘id’ al utilizar el tag assetset. Si se van a necesitar los campos estándar hay que hacer uso de “filtros” para “copiar” lo valores de dichos campos en atributos flexibles. Las búsquedas de assets flexibles tienen que hacerse mediante el uso de: o <searchstate:create>, crea la constraint de búsqueda. o <searchstate:addsimplestandardconstraint> y similares, para indicar los criterios por los cuales se va a realizar la búsqueda. o <assetset:setsearchedassets> para realizar la búsqueda de los datos. Esta búsqueda puede ser sobre tipos de assets NO homogéneos. Por defecto, este tag establece una dependencia unknowndeps sobre los tipos de contenidos sobre los que se realiza la búsqueda. Si se hace uso del párametro fixedlist con valor a true, sólo se generarán dependencias solamente con los assets devueltos en la consulta. El número de elementos recuperados por una búsqueda se hará mediante <assetset:getassetcount name=”productSet” varname=”ascount” /> Los atributos de tipo “text” no se recuperan con <assetset:getmultiplevalues> sino con <assetset:getattributevalues>. Cuando queramos realizar una búsqueda en assets flexibles y solo queramos obtener los valores de aquellos atributos que no han sido heredados, haremos uso del modificador immediateonly=”true”, en los tag <searchstate >. Recomendaciones Se recomienda el uso de un asset flexible cuando: Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 13 Best Practices Framework Fatwire o Existan definiciones que pueden cambiar. o Existan instancias del mismo tipo de contenido, pero que hagan uso de distintos atributos. o Existan definiciones que puedan cambiar con facilidad. o Cuando se necesite crear algún tipo de catálogo. o Cuando exista necesidad de jerarquizar/organizar contenidos. o Cuando se necesite hacer uso de la herencia de información. o Cuando se necesiten filtros (transformaciones) en determinados atributos. También son apropiados para la creación automática de atributos derivados (por ejemplo, cálculo de fechas, generación automática de atributos de documentos multimedia, etc). o Cuando se quiera hacer uso de CS-DocLink o de CS-Engage Para que pueda permitirse la herencia múltiple sobre un atributo, el atributo en cuestión tiene que ser multivaluado. Minimizar el uso de atributos multivaluados, especialmente si son heredados, debido a su alto coste para el sistema. El tag <assetset:getmultiplevalues>, es mucho más eficiente que <assetset:getattributevalues>, si se están visualizando múltiples atributos. Respecto a la profundidad o anidamiento de familias flexibles, tiene que limitarse y restringirse mediante la creación de diferentes definiciones y además controlar el nivel de profundidad en el que nos encontramos mediante el uso de un asset que aporte esa información para cada instancia de asset flexible (ver familias flexible del portal Firstsite II) Respecto al diseño de familias flexibles: o Limitar el número de “flex parents” definidos para simplificar la búsqueda en el gestor de contenidos (aunque tienen que crearse las suficientes “flex definitions” y “flex parents definitions” para organizar correctamente el contenido). o Intentar no definir muchos atributos a nivel de “flex parents”. Limitar el uso de los “flex parents” para agrupar contenidos nada más. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 14 Best Practices Framework Fatwire Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 15 Best Practices Framework Fatwire Prohibiciones Queda prohibido el uso de asset:load sobre assets flexibles Para cargar en memoria un asset flexible usaremos <assetset:setasset name=”assetsetname” type=”assettype” id=”assetid” /> (solo para un contenido) Evitar escribir consultas SQL sobre assets flexibles. Hay que estudiar los beneficios en rendimiento y en cualquier caso nunca se ha de complicar la lógica para facilitar el mantenimiento del código. No es recomendable usar <assetset:getattributevalues> si se piensa visualizar más de 3 atributos. Programación Normas Se debe controlar: Código a fuego del contexto de la aplicación (/servlet/) en elementos de código. Cabe realizar varias observaciones: En muchos casos no es necesario poner el contexto En los casos que fuese necesario, hay una propiedad que define el contexto (ft.cgipath), con lo cual debería de utilizarse esta propiedad para que ante un posible cambio de contexto no haya que modificar el código Parámetros en render:satellitepage. Al pasar parámetros a este tag se debe controlar si están a null o no. En caso de ser null, no se deben pasar. Por ejemplo: <render:satellitepage pagename='mipagetemplate'> <% if (c!=null){ %><render:argument name="c" value="<%=c%>"/> <%} if (cid!=null){%><render:argument name="cid" value="<%=cid%>"/> <%}%> </render:satellitepage> Potenciar el uso de los taglibs de ContentServer frente al uso de la API java. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 16 Best Practices En Framework Fatwire los <asset:load> que utilicen el nombre del contenido como identificador, también es requisito especificar el parámetro siteName en los tipos de assets genéricos (page, collection, query, ..) para evitar errores por nombres duplicados. Se da frecuentemente al cargar un objeto Page cuyo nombre sea muy común (mapa web, home, …). Por ejemplo, en lugar de <asset:load name=”miasset” field=”name” value=”nombre”/> utilizar <asset:load name=”miasset” field=”name” value=”nombre” siteName=”site” /> Definición y Acceso de las Propiedades: Para recuperar las propiedades de ficheros auxiliares hay que utilizar una variante del método "ics:getproperty" que indica el fichero origen de propiedades. Trazas en el log de Content Server: Durante el desarrollo, vigilar continuamente el log de ContentServer para eliminar TODOS los errores que aparezcan en el mismo. Los atributos definidos en el PageCriteria de una plantilla, deben declararse en minúsculas para evitar problemas de ambigüedad de sus parámetros. Utilizar el método ics.GetVar(“nombreVariable”) para recoger los diferentes parámetros que lleguen a la página. Se prohibe el uso de request.getParameter porque puede provocar comportamientos inesperados cuando se active la caché (debido entre otras cosas a la regeneración de las páginas con contenido modificado tras una publicación ) Cuando se hace flushcatalog de una tabla hay que utilizar el mismo nombre que aparece en la tabla SystemInfo, ya que es case sensitive. Recomendaciones Anticipar el uso <insite:edit> en los assets donde se quiera editar el contenido de un campo y <render:stream> para recoger el contenido de un campo que contenga algún “embedded link” (enlace embebido). No se permite parsear los campos o la implementación interna para generar los enlaces. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 17 Best Practices Framework Fatwire Sobre las familias flexibles: o Limitar las ordenaciones a un atributo, ya que la ordenación se hace en memoria no en BBDD. o Crear distintas familias cuando se quiera separar contenidos por motivos de seguridad o para ganar eficiencia. Uso de <render:callelement> vs. <ics:callelement>: o Se recomienda usar <render:callelement> para cualquier elemento que visualice información como resultado (html, xml, etc). Se puede usar el parámetro “scope” para gobernar los ámbitos de visibilidad de variables. o Se recomienda usar <ics:callelement> para aquellos elementos que devuelven como resultado valores en variables. Nomenclatura de argumentos de entrada para elementos de lógica invocados mediante <ics:callelement>. o Para evitar efectos laterales con las variables de entrada a los elementos invocados, es conveniente usar una nomenclatura del estilo “prefijo:nombrevariable". o Esto se debe a que los elementos de código invocado y llamante comparten el mismo ámbito de declaración de variables. o Internamente el elemento de código debería seguir la misma nomenclatura para el nombrado de variables. Espacios en blanco y líneas vacías en el código HTML. o Para evitar que el código HTML generado por ContentServer en modo JSP esté repleto de saltos de línea y de espacios en blando, se puede utilizar el truco de poner los saltos de línea entre áreas java dentro del código JSP. o Por ejemplo: En saltos de línea: <% . . . %> En las declaraciones de las JSPs: <%@...%><% Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 18 Best Practices Framework Fatwire @...%><% En las llamadas a otras etiquetas JSPs: %><ics:callelement...><% %><ics:whatever/><% %><ics:whatever/><% %></ics:callelement...><% Se recomienda editar desde el interfaz web CS-Direct, aquellos elementos de código y plantillas que se han desarrollado o modificado desde el CS-Explorer. De esta manera la herramienta considera que esos elementos han sido modificados. Uso de IList. o Nunca hacer flush de los objetos IList. Sólo sería necesario para el caso de que el parámetro bcache en una consulta estuviera a false. Pero esto está prohibido por un punto anterior. o Si en un elemento de código se reutiliza una instancia de IList, se puede hacer un ics.RegisterList(“nombrelista”, null) para vaciar la lista y que no ocupe espacio en memoria. Programar adecuadamente los formularios HTML, a través de la etiqueta JSP proporcionada por Content Server: <satellite:form> que esconde al programador todas las complejidades de los formularios HTML. No es una buena práctica declarar directamente formularios HTML. En esos casos se ha de observar: o Usar el método POST. o No usar parámetros en el campo ACTION del formulario. Usar campos HIDDEN con los parámetros. o No cablear los servlets ContentServer o Satellite en el campo ACTION. Prohibiciones Cualquier uso de <render:unkowndeps> debe estar claramente justificado en la documentación que acompaña al site. Hay que limitarlo al mínimo posible ya que afecta a la regeneración de la caché durante la publicación. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 19 Best Practices Framework Fatwire En código no se puede usar ni “ContentServer” ni "Satellite". Se ha de usar el API de FatWire para evitar tener que indicar estos servlets en el fichero de configuración. Los taglibs a usar para generar las urls son: o satellite:link (para páginas si no se tiene acceso al parámetro cid) o render:getpageurl (para páginas) o render:satelliteblob (para blobs) o render:getbloburl (para blobs) En la versión 6.3 de Content Server se introduce el tag <render:calltemplate> que unifica la invocación a plantillas y CSElements a través de un único tag. Cualquier uso de <ics:disablecache> en producción debe estar justificado. Esta etiqueta JSP penaliza el rendimiento de los pagelets afectados: Páginas padres e hijas dejan de estar cacheados y se serializan los accesos a estos elementos a nivel de threads. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 20 Best Practices Framework Fatwire 3 Diseño de assets 3.1 Cuándo usar assets básicos Cuando los datos tienen las siguientes características: 3.2 - Son fijos y predecibles: No habrá necesidad de añadir atributos al tipo de contenido. - Son homogéneos: Todos los contenidos del mismo tipo tienen atributos similares. - Tienen un número moderado de atributos. Tan solo está limitado por la base de datos la cantidad de columnas/atributos que se pueden definir en la tabla de un asset básico. - Se quiere usar el mecanismo de publicación estático de Exportación a Disco. Están muy limitadas las aplicaciones de los assets flexibles en los cuales tienen sentido utilizar la publicación de Exportación a Disco. - Los visitantes navegan por el sitio web navegando de enlace en enlace. Cuándo usar assets flexibles - Cuando existen muchos atributos. Por ejemplo, los productos pueden tener potencialmente cientos de atributos. Puesto que los valores de los atributos de las familias flexibles son almacenados como filas en lugar de columnas, los assets flexibles pueden albergar físicamente muchos más atributos que los assets básicos. - Se pueden representar como una jerarquía en la cual los contenidos heredan valores de atributos de sus contenidos padre. - No se puede predecir qué atributos pueden ser necesarios en un futuro y además los datos podrían necesitar atributos adicionales periódicamente. - Las instancias de los assets pueden ser bastante distintas. Esto es, no todos los assets del mismo tipo de contenido tienen los mismos atributos. Por ejemplo, una toalla de baño podría tener atributos que una tostadora no tendría, sin embargo tanto la toalla como la tostadora son instancias del asset “Producto”. - Los visitantes navegan por el portal a través de opciones de búsqueda de más genéricas a más concretas a través de enlaces o árboles de navegación. Estas búsquedas están basadas en los atributos del modelo de datos. - Se quiere usar el modulo Engage. - Cuando se quieran utilizar mecanismos de herencia de atributos, aplicar filtros para generar atributos (derivados) de manera automática o se quieran aplicar motores de transformación sobre los atributos. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 21 Best Practices 3.3 Framework Fatwire Uso de subtipos Los subtipos son útiles en muchas ocasiones: - Muy apropiados para personalizar las páginas del “SitePlan” y por tanto los elementos almacenados en los assets Page. - Permiten que la herramienta muestro solo los campos apropiados al editor en función del subtipo (por ejemplo en las relaciones de los assets de tipo page). - Se pueden emplear para especificar asociaciones por subtipo entre contenidos. - Son útiles para asociar plantillas a contenidos en función del subtipo. 4 Diseño de páginas y caché 4.1 Diseño del interfaz de edición de ContentServer Al interfaz de edición de contenidos hay que aplicarle unos criterios de usabilidad que garanticen un interfaz cómodo para el usuario redactor. Se deben vigilar las siguientes recomendaciones: Generación de plantillas de previsualización para la mayoría de los contenidos. Estas plantillas muestran desde el interfaz de edición, como se vería la información en el portal una vez publicado. Generación automática de campos no relevantes para el editor, o de difícil obtención por otros medios (por ejemplo, atributos de peso, longitud y altura en imágenes o de tamaño en documentos. Control automático del peso de la información entrada por el usuario. Generación automática de imágenes de baja resolución o de iconos. Eliminar aquellos campos “combo” cuyo contenido se pueda generar automáticamente de manera algorítmica (por ejemplo campos “mime-type”). Crear editores de atributos para campos cuyo introducción textual pueda generar errores (como los campos fecha). Aplicar el editor de atributos “Field copier” para copiar campos estándar como el nombre del contenido. Asegurar que las definiciones de los contenidos o las plantillas no son accesibles o están protegidas por workflows y roles frente al usuario redactor. Potenciar el uso de assets flexibles vs. Assets básicos para el modelado del portal. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 22 Best Practices Framework Fatwire Diseñar un buen “Site Plan” que pueda guiar a los redactores en la búsqueda de información colgada en el portal, bajo una sección concreta. Inclusión de fechas de vigencia en aquellos contenidos que requieran la funcionalidad de que solo sena visibles en el portal durante un rango de fechas. Para las versiones 6.X de Content Server se recomienda diseñar los contenidos multiidioma a través de assets flexibles. 4.2 Diseño de páginas El tag render:satellitepage (y el tag satellite:page y sus equivalentes en xml) identifican un pagelet cacheado por el campo pagename y por los valores de otros posibles parámetros. Si los valores de estos parámetros cambiaran de una invocación a otra, se cachearía otro pagelet diferente incluso si el contenido fuese el mismo. Es importante pasar valores a los parámetros de los pagelets a través de estos tags. Los valores pasados a través del pool de objetos ICS, las listas ICS, atributos en el contexto de una página y variables de sesión, podrían no estar disponibles para todos los pagelets invocados puesto que los pagelets anidados podrían no se invocan al mismo tiempo que los padres. Por tanto, los pagelets que dependen en variables de sesión o datos de contexto no deberían cachearse: Intentar cachearlos podría originar un comportamiento no determinista. Todos los parámetros pasados a un pagelet anidado a través de render:satellitepage (y el tag satellite:page y sus equivalentes en xml) se tienen que especificar como pagecriteria en la tabla SiteCatalog. Esta información la utiliza ContentServer para determinar que parámetros son relevantes a la hora de cachear pagelets. No está permitido usar otros parámetros que no estén listados en el pagecriteria (en tal caso ContentServer sacará un error en el log). Usar plantillas (Templates) para mostrar o renderizar toda la información (Pages y pagelets). Nota: Hay dos tipos distintos de plantillas: “typeless” y “typed” (sin tipo asociado y con tipo asociado). Las plantillas typeless despachan su proceso a plantillas typed que realizan la visualización en función del tipo de contenido. - Utilizar CSElements para lógica que no muestra información y que devuelven valores. - Se desaconseja utilizar CS-Explorer para crear registros directamente en las tablas SiteCatalog y SiteEntry: o Evitando potencialmente la creación de registros huérfanos entre esas tablas. o Se crearán primero contenidos SiteEntry y CSElement a través de CS-Direct (GUI web) para luego editarlos con el CS-Explorer. Así estos elementos se podrán publicar y promocionar entre entornos de la manera usual. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 23 Best Practices Se desaconseja utilizar CatalogMover para mover los elementos de código. - Framework Fatwire Debido al fuerte uso que se hace de las Templates para la visualización, los convenios de nombrado se convierten en pieza clave del desarrollo. Una buena política permitirá que las plantillas “typless” puedan despachar su funcionamiento de manera algorítmica. Un ejemplo sencillo: Crear una plantilla /Layout (configurada como “typeless” y usada para todos los assets) que sería cacheable y generaría todas las CSS, DIVs y estructura de tablas del esquema de la página web. Para cada pagelet de su cuerpo, llamaría a <site>/<assettype>/Body, donde <assettype> sería una variable implícita. Alternativamente /Layout podría cargar el asset y obtener su definición. Así se podría despachar a diferentes plantilla dentro de un asset usando <site>/<assettype>/<definition>. Se recomienda que el diseño del site se haga siguiendo una planificación de plantillas en secciones y subsecciones. De esta manera se aumentará la reutilización de código. Por ejemplo, es común diseñar plantillas de tipo Page que recuperan información de sus contenedores y la pintan de distinta manera en función de la sección que se trate, etc. Se recomienda que las plantillas del portal sigan un esquema unificado a la hora de enumerar los parámetros que admiten las plantillas. Esto hará que el portal sea más fácilmente indexable por motores de indexación externos a Content Server. No se debe permitir el uso de parámetros que a su vez codifiquen parámetros a través de separadores (“,” , “;”, “@”, etc). Sobre todo si estos parámetros forman parte del “pagecriteria” de plantillas con la caché activada. En algunos casos se requiere que las URLs que genera la herramienta tengan un formato definido. Usar la funcionalidad del URLAssembler para generar direcciones más amigables. Uso de mapas en aquellos sites que se prevean puedan ser replicables (versión 6.3 en adelante). Para asegurar que los portales sean replicables, los elementos de código no deben tener referencias directas a tipos de contenidos. En su lugar los elementos deben usar el tag <render:lookup> con una clave para obtener el valor asociado. El interfaz web de ContentServer ofrece un espacio en la definición de las plantillas para almacenar estos pares de clave-valor. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 24 Best Practices 4.3 Framework Fatwire Diseño de la caché Satellite Server, automáticamente instalado con Content Server, provee al sistema de una segunda capa adicional de caché. Para mejorar nuestro sistema de caché podemos añadir a nuestro sistema cuantos satélites necesitemos. Satellite Server cachea páginas, pagelets y blob a disco o memoria. Se puede usar el servlet Inventory para visualizar las principales características de configuración de Satellite Server así como todos los elementos que tiene almacenados en su memoria. Los objetos pequeños se cachean en memoria y los grandes en disco, dependiendo del valor que tenga la variable file_size (consultar “Content Server Property Files Reference”). 4.4 Expiración de Satellite Server La expiración en Satellite Server está especificada en la columna sscacheinfo de la tabla SiteCatalog. El valor de esta columna determina cuando una entrada en caché debe expirar. La sintaxis que sigue esta columna está especificada más adelante. El orden de precedencia del tiempo en la expiración de la caché es el siguiente: 1. Atributo cachecontrol, establecido en el tag satellite.page, es el primero que establece el tiempo que un elemento permanecerá vivo en la caché de Satellite Server. La utilización este atributo está en desuso, ya que como hemos indicado es suficiente con establecer este mismo valor en la columna sscacheinfo de la tabla SiteCatalog. Con el uso de esta columna logramos un código mucho más limpio que usando el parámetro cachecontrol y una forma mucho más sencilla y rápida de localizar los elementos que están cacheados y cuales no (consultando la tabla SiteCatalog). 2. Propiedad satellite.page.cachecontrol.default también en desuso. del fichero “futuretense.ini”, 3. Columna sscacheinfo de la tabla SiteCatalog. Es conveniente establecer un valor de caché alto para que los elementos que deseamos permanezcan vivos en caché. Cuando hacemos alusión a un valor alto sería por ejemplo un año. La idea de establecer un valor de estas características es para confiar en el sistema de refresco de caché del proceso de la publicación. Este sistema permite publicar cualquier contenido en cualquier momento y que se actualicen los elementos afectados por los contenidos publicados. 4. Si la propiedad cs.alwaysusedisk tiene establecido el valor true, entones el valor que tiene la propiedad cs.pgcacheTimeout es usado. La sintaxis de este parámetro es la misma que la de las entradas de la SiteCatalog sscacheinfo y cscacheinfo que detallamos más abajo. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 25 Best Practices Framework Fatwire Recomendaciones: 1. No establecer nunca el valor de caché en las columnas sscacheinfo y cscacheinfo de tal forma que el elemento en cuestión caduque antes en la caché de Content Server que en la caché de Satellite Server. Siempre debe tener mayor o igual vida en cscacheinfo. Debemos evitar a toda costa que un elemento caduque antes en la caché de Content Server que en la caché de Satellite ya que para que las notificaciones de refresco y actualización entre los dos niveles se lleven a cabo, el elemento que debe ser refrescado en la publicación debe estar vivo en Content Server (esté o no lo esté en Satellite Server). Este concepto es crucial para evitar desfases en los elementos, entre los dos niveles de caché y el correcto funcionamiento de la actualización de contenidos en la publicación. 2. No usar el atributo cachecontrol de los tags satellite.page, siempre confiar en las columnas cscacheinfo y sscacheinfo de la tabla SiteCatalog, para establecer el tiempo de vida de un elemento. 3. Establecer un tiempo grande de permanencia de caché en las columnas cscaheinfo y sscacheinfo para que los elementos se actualicen automáticamente mediante el proceso de publicación (a través las dependencias almacenadas en las tablas SystemPageCache y SystemItemCache). En este punto debemos nombrar el concepto de “unknowndeps” o dependencias no conocidas o no explícitas. Existen dependencias creadas entre assets que no hay forma de predecir que assets son, ya que provienen de sentencias SQL o cambios muy frecuentes. El tag “render.unknowndeps” crea una dependencia en tabla llamada “unknowndep”, cuando una dependencia es establecida a unknowndep significa que será regenerada en la caché después de una sesión de publicación de “Mirror to Server”, tanto si lo necesita o no. Esto implica un uso cuidadoso de este tag, ya que el abuso del mismo puede provocar sobrecarga en la regeneración de páginas así como producir que el proceso de publicación tarde un tiempo considerable (dependiendo siempre del número de contenidos que se publiquen). Se debe usar este tag cuando realmente no podemos determinar con que assets vamos a generar las dependencias. Por ejemplo, consultas en las que cada resultset devuelvo en cada consulta puede ser diferente, en el uso de los tags SELECTTO, EXECSQL o ICS.SQL, debemos usar el tag RENDER.UNKNOWNDEPS. Merece una mención especial los tags de la familia ASSETSET, cuyo uso generan automáticamente dependencias “unknown”. Nota: Consultar “Developers Guide” pagina 505. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 26 Best Practices Framework Fatwire 5. Si deseamos un tiempo de vida por defecto en todos los elementos que se almacenan en Satellite Server debemos establecer la propiedad, en el fichero “futuretense.ini”, “cs.alwaysusedisk” a true y el valor que queremos por defecto establecerlo en la propiedad “cs.pgcahetimeout”, del mismo fichero. De esta forma debemos poner en la columna sscacheinfo el valor true, para que coja el valor por defecto. Para las entradas que deseamos un valor particular bastaría con establecerlo en sscacheinfo. Por ejemplo, si deseamos que todos los elementos de mi portal permanezcan en caché de Satellite hasta el día 21 de Junio de 2006 a las 12 de la noche, los valores que debemos establecer son los siguientes. Valores en las columnas de la tabla SiteCatalog: cscacheinfo=true sscacheinfo=true (Con este valor o vacío el sistema se dirigirá a la propiedad cs.pgcachetimeout, que establece el tiempo por defecto. También valdría con el valor “true,*”) Nota: Vamos a resaltar que la vida en la caché de Content Server tanto en Satellite Server depende de la propiedad cs.pgcacheTimeout del futuretense.ini. Valores en propiedades del fichero futuretense.ini: cs.alwaysusedisk=true cs.pgcahetimeout= true,@2016-06-21 00:30:00 Caso concreto de un elemento que queremos que se actualice cada 15 minutos: Si queremos que un elemento en concreto caduque cada 5 minutos debemos establecer este tiempo en las entradas de la SiteCatalog como indicamos a continuación: cscacheinfo=true,* sscacheinfo=true, ,~15 Caso concreto de un elemento que queremos que se actualice cada 24 horas: cscacheinfo=true,* sscacheinfo=true, ,~1440 Caso concreto de un elemento que queremos que se actualice todos los domingos: cscacheinfo=true,* sscacheinfo= true,#00:00:00 0/*/* Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 27 Best Practices Framework Fatwire 6. Actualmente en las versiones 6.x de Content Server es posible mantener en caché las páginas contenedoras. Es decir, según la siguiente figura: Ahora es posible cachear selectivamente los contenedores de las páginas. De tal forma que cuando Satellite Server pregunta por una página a Content Server, la columna sscacheinfo es enviada de vuelta a junto con la página y por lo tanto el Satellite sabrá cuando debe ser cacheada y cuando no (y cuando refrescarla). Otras recomendaciones en cuanto al uso de pagelets (por motivos de eficiencia, aunque variará en función de cada plataforma) son: No anidar pagelets a más de dos o tres niveles de profundidad. No desarrollar plantillas con más de 8 pagelets incrustados. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 28 Best Practices Framework Fatwire Recomendaciones en el uso del Framework. o Nomenclatura de contenidos: Nomenclaturas. Gestión de propiedades. Subtipos y asociaciones. Clases Java y Jars. o Documentos relacionados: Tipos de contenidos. Uso de las hojas de estilo. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 29 Best Practices Framework Fatwire 5 Nomenclatura de contenidos Portales: Para cada portal se definen los siguientes prefijos que se deberán utilizar en los nombres y rutas de los diferentes elementos, según se especifica más abajo. Nombre del proyecto [nombre] – Por ejemplo: PortalSalud Sigla del proyecto [sigla] – Por ejemplo: PTSA Ficheros estáticos: El directorio StaticFiles debe ir dentro del WEB-INF de la aplicación y en él van las hojas de estilo, las imágenes, ficheros de JavaScript, ficheros Flash, etc. StaticFiles/[nombre] – Por ejemplo: StaticFiles/PortalSalud Nombre de los tipos de contenidos (asset types): Básicos [sigla]_XXX – Por ejemplo: PTSA_Literal Flexibles [sigla]_XXX_FPD/FP/FD/FA – Por ejemplo: PTSA_Agrupador_FPD, PTSA_Agrupador_FP, PTSA_Agrupador_FD y PTSA_Agrupador_FA Attr. editors [sigla]_XXX – Por ejemplo: PTSA_PickFromTree Atributos flex [sigla]_XXX – Por ejemplo: PTSA_Titulo_es Template [sigla]_XXX – Por ejemplo: PTSA_Home CSElement [sigla]_XXX – Por ejemplo: PTSA_Cabecera SiteEntry [sigla]_XXX – Por ejemplo: PTSA_cabecera Asociaciones y subtipos: Asociación [sigla]_XXX – Por ejemplo: PTSA_Literal Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 30 Best Practices Framework Fatwire Subtipo [sigla]_XXX – Por ejemplo: PTSA_Home (Page) Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 31 Best Practices Framework Fatwire Estructura del código y las páginas: Todo el código tiene que estar censado en el ContenServer como assets de diseño, Templates, CSElements y SiteEntry. ElementCatalog SiteCatalog Consultas SQL y “Querys” Todas las consultas que no estén dadas de alta como asset Query se tienen que almacenar dentro de la carpeta SystemSQL donde se guardarán como ficheros .sql Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 32 Best Practices Framework Fatwire Enlaces: Todos los enlaces tienen que ser relativos a los servlets de Content Server , no debe aparecer ningún contexto web (por ejemplo /servlet/) en el código. Asset Propiedades La manera de gestionar propiedades dentro de los portales de ICM es a través de un tipo de contenido específico, así, se tendrá que crear un asset [sigla]_Propiedad donde se almacenarán propiedades que puedan ser necesarias para el desarrollo. Ejemplo de asset: <ASSET NAME=”HFUE_Propiedad" DESCRIPTION=" HFUE_Propiedad " PROCESSOR="4.0" DEFDIR="/"> <PROPERTIES> <PROPERTY NAME="valor" DESCRIPTION="Valor"> <STORAGE TYPE="VARCHAR" LENGTH="255" /> <INPUTFORM TYPE="TEXT" WIDTH="60" MAXLENGTH="255" REQUIRED="NO" /> <SEARCHFORM DESCRIPTION="Valor contiene" TYPE="TEXT" WIDTH="48" MAXLENGTH="255"/> </PROPERTY> </PROPERTIES> </ASSET> Existe una tag-lib para extraer las propiedades: <icm:property name="nombrePropiedad" type=" HFUE_Propiedad " output="variableSalida"/> Nota: Esta norma de aplicación en ICM lleva implícita la prohibición de utilizar archivos de propiedades a través del tag de ContentServer ics:getproperty. Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 33 Best Practices Framework Fatwire Subtipos y asociaciones Todos los tipos genéricos, por ejemplo Page, Collection o Query, deben tener un subtipo específico para el portal en cuestión. Pueden haber varios subtipos de páginas, lo que no se permite es un asset page sin subtipo (lo mismo para Collection, Query, ..). Todas las asociaciones que involucren a estos tipos genéricos deberán definirse para uno o varios subtipos específicos del portal, esto es no pueden ser aplicables a cualquier subtipo. En otro caso se dificulta el trabajo del usuario al ofrecerle asociaciones sin sentido en el portal con el que se esté trabajando. Las asociaciones que se aplican a assets específicos del portal sí pueden ser aplicables a cualquier subtipo. Clases Java y JARs Todas las clases Java, ya sean dentro de un JAR o no, deben estar documentadas y se debe justificar la necesidad de añadir código Java externo al propio Content Server. Es requisito que todas las clases estén incluidas en paquetes Java y la nomenclatura para dichos paquetes deberá ser la siguiente: org.madrid.fatwire.[nombre_site].* – Por ejemplo: org.madrid.fatwire.cm.util 6 Documentos relacionados En relación con las recomendaciones para programar con ContentServer usando el Framework, es obligatorio seguir las recomendaciones establecidas en las siguientes referencias entregadas junto con el Kit de desarrollo: - Representación gráfica de los tipos de contenidos de Madrid.org: Tipos de contenido de Madrid_org.pdf - Reglas de diseño de los portales: libro-estilo-estand_Optimizada-v2.ppt ESTANDAR-CSS-01.00-Hojas de estilo.doc Área de Integración y Arquitectura de Aplicaciones Dirección de Análisis y Mantenimiento de Aplicaciones y Desarrollos Institucionales Subdirección General de Desarrollo, Tecnología e Infraestructuras Página: 34