LIFERAY. PROPIEDADES DE PORTAL.PROPERTIES MODIFICADAS QUE AFECTAN A FREEMARKER Y VELOCITY

Hay propiedades en el fichero portal.properties que afectan al procesamiento de plantillas realizadas en Freemarker o Velocity y aquí, aparece uno de los problemas comúnmente asociados al software libre: una nueva versión de la herramienta, puede implicar cambios que afectan a código desarrollado para versiones anteriores.
Es precisamente lo que ha ocurrido con las clases y variables restringidas en Freemarker y Velocity a partir de la versión 6.2 de Liferay. En versiones anteriores nos encontrábamos con:
// Entre otras propiedades…

Sin embargo, si nos bajamos el código fuente de Liferay
Selección de Bundle Liferay
Atención: Datos actualizados a 09/01/2017.
En la actualidad, la zona de descarga de Liferay ha cambiado bastante y se ha orientado totalmente hacia la última versión de Liferay en este momento: Liferay 7. Para cualquier descarga de versiones anteriores o de recursos relacionados a esas versiones: Descargas de Liferay.
…, abrimos el fichero /portal-impl/src/portal.properties con un buen editor y buscamos la palabra Velocity o Freemarker, nos daremos cuenta que ya no existen. Lo que ahora tenemos a nuestra disposición es (se indican las propiedades con los valores que vienen por defecto):
Atención: Datos actualizados a 21/12/2015.

Por tanto, si queremos acceder a esas variables y clases desde nuestras plantillas Freemarker o Velocity, el clásico fichero portal-ext.properties que sobrescribe a portal.properties contendrá algo como:

Parece ser que la razón del cambio es hacer más genéricas estas clases y variables que pueden ser usadas en diferentes contextos.
En cualquier caso, acceder a esas variables y clases en plantillas, implica generalmente que vamos a usar lógica en ellas, lo cual no es recomendable, como tampoco es recomendable el uso de serviceLocator en plantillas, recomendándose mejor usar el método getClass().forName(‘…’). Sobre esto tengo pensado realizar un artículo, así que lo veremos con más profundidad más adelante.
Nada más, un cordial saludo y hasta otra.

HTML 5. REQUIRED SELECT.

HTML5 Logotipo

HTML 5 ha traído bastantes funcionalidades a los desarrolladores de aplicaciones web que antes era necesario “fabricar”; bastantes de ellas dentro de los llamados Formularios HTML 5 y en concreto aquellas que tienen que ver con validaciones de los campos de formularios, como la frecuente tarea de comprobar si se han rellenado o no, los campos que establezcamos como obligatorios.

Una tarea, simple en su cometido, pero que requería un uso intensivo de JavaScript y CSS. Con HTML 5 solamente tenemos que añadir el atributo required al campo del formulario que consideremos obligatorio completar.
A partir de ahí, será el propio navegador el encargado de controlar si ese campo requerido tiene información adecuada o no, interactuando con el visitante de acuerdo a la implementación que de HTML 5 tenga el navegador que se esté usando. Es el punto donde entra en juego la compatibilidad del navegador con el estándar HTML 5. Hay un muy buen artículo sobre compatibilidades aquí: http://www.wufoo.com.mx/html5/
Puesto que con las nuevas versiones de navegadores esto puede cambiar, la información del artículo al que apunta el enlace, solamente debe servir como guía. En cualquier caso, si queremos cambiar el comportamiento que ofrece el navegador para required, tendremos que utilizar nuevamente CSS y JavaScript. También podemos usar el atributo aria-required (se puede utilizar de manera conjunta a required) que hace lo mismo que éste pero es compatible con algunos navegadores que no lo son con este atributo.
EDITADO 16/12/2016
Actualmente los atributos aria no se consideran necesarios ya que la práctica totalidad de navegadores son compatibles con la mayoría de características de HTML 5 y realmente no aportan nada. En el siguiente hiperenlace se trata este punto de forma exhaustiva:
http://html5doctor.com/on-html-belts-and-aria-braces/

Un usuario anónimo me comentó que la misión de aria-required no es la compatibilidad si no para indicar que un campo es requerido desde un lector de pantalla. Sin entrar en debates baldíos de lo que realmente hace aria-required, es verdad que quizás su uso en este artículo, debería haber sido más detallado para evitar confusiones. Gracias quien seas. La idea de incluirlo aquí, era que, en las fechas en que se publicó el artículo, habían clientes web que no reconocían correctamente el atributo required y aria-required podía ser usado como factor de ampliación de compatibilidad, independientemente de lo que pueda ser su uso real. De todas formas: https://www.w3.org/TR/html-aria/
El uso con cualquier elemento de tipo input, textarea o select es muy simple, ya que simplemente basta con añadirlo al elemento obligatorio. De todas formas, si hay problemas de compatibilidades con navegadores, estas son las posibilidades:

Con todo, su utilización en un elemento select, actualmente implica tener en cuenta algunos detalles más que su mera inclusión. Estos factores son:

  • Debe tener uno o más opciones (elementos option).
  • La primera opción o elemento option debe tener su atributo value vacío o simplemente no tener contenido de texto.
Ejemplos:

A la hora de crear las vistas para nuestras aplicaciones o nuestras herramientas como Liferay, Joomla, Prestashop, etc., no cabe duda de que es un arma excelente que nos ahorrará mucho trabajo, eso, sin tener en cuenta que estaremos ahorrando código CSS y JavaScript, lo que hará que aumente el rendimiento de la aplicación.
Lo dejamos aquí de momento, ya que este artículo tenía como misión mostrar el uso correcto de required con select. La creación de formularios HTML 5 podéis estudiarla con todo detalle, bien en la abundante documentación existente en la web, bien, realizando algún curso como los que podemos ofrecerte. Si quieres más información, puedes hacerlo a josema@orbispservices.com o más cómodamente desde el formulario de contacto.
Un cordial saludo y mis mejores deseos para todos para este nuevo año.