Mejores Prácticas Plan de Calidad de los Proyectos FatWire en ICM

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