Historial de página
Subdirección de las Tecnologías de la Información y Comunicaciones
Área de Gobernanza y Calidad
Cumplimiento normativo
| Advertencia |
|---|
Las normas expuestas son de obligado cumplimiento. La STIC podrá estudiar los casos excepcionales los cuales serán gestionados a través de los responsables del proyecto correspondiente y autorizados por el Área de Gobernanza de la STIC. Asimismo cualquier aspecto no recogido en estas normas deberá regirse en primera instancia por las guías técnicas correspondientes al esquema nacional de seguridad y esquema nacional de interoperabilidad según correspondencia y en su defecto a los marcos normativos y de desarrollo software establecidos por la Junta de Andalucía, debiendo ser puesto de manifiesto ante la STIC. La STIC se reserva el derecho a la modificación de la norma sin previo aviso, tras lo cual, notificará del cambio a los actores implicados para su adopción inmediata según la planificación de cada proyecto. En el caso de que algún actor considere conveniente y/o necesario el incumplimiento de alguna de las normas y/o recomendaciones, deberá aportar previamente la correspondiente justificación fehaciente documentada de la solución alternativa propuesta, así como toda aquella documentación que le sea requerida por la STIC para proceder a su validación técnica. Contacto Arquitectura: l-arquitectura.stic@juntadeandalucia.es |
| Info | ||
|---|---|---|
| ||
Los nuevos desarrollos enmarcados dentro de la STIC hacen uso de algunas soluciones tecnológicas más actuales. El documento actual, pretende servirle de ayuda para aquellos desarrollos más antiguos, puede ser que su solución provea de una pila tecnológica más actual que la que aquí está descrita. En tal caso se propondrán los asuntos al área de arquitectura para determinar el enfoque. |
Histórico de cambios
Los cambios en la normativa vendrán acompañados de un registro de las modificaciones. De este modo se podrá realizar un seguimiento y consultar su evolución. Ordenándose de mas recientes a menos recientes, prestando especial cuidado a las cabezeras de la tablas dónde se indican las fechas de entrada en vigor y versión.
| Expandir | ||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
1. Normativa de Clientes Web
Para una continua actualización y uso de los aplicativos en tecnologías y navegadores modernos, se proponen unas técnicas para eliminar o minimizar la incompatibilidad de los aplicativos entre diferentes navegadores, tecnologías y estilos.
Se recomienda la técnica de "Graceful degradation" para la construcción de los aplicativos, esto quiere decir que se proveerá con la máxima experiencia de usuario en los navegadores más modernos, y esta ira degradándose de manera controlada a un nivel menor en navegadores antiguos, siempre ofreciendo la misma funcionalidad básica.
Hay que hacer foco en tres áreas principales a la hora de la compatibilidad, JavaScript, CSS, y HTML
- JavaScript:
Uso de la especificación ECMAScript 5 (En este enlace podéis comprobar los navegadores compatibles: http://kangax.github.io/compat-table/es5/)
Para evitar incompatibilidades y facilitar el desarrollo se recomienda el uso de las siguientes librerías:- jQuery: Ofrece muchas funcionalidades, sobre todo relacionadas con el tratamiento del DOM, y la realización de peticiones ajax.
- modernizr: Librería que permite la detección y la carga condicional de javascripts y css, lo que permite fácilmente ofrecer recursos específicos para navegadores concretos.
- CSS: Para evitar problemas de estilos entre navegadores se debe de hacer uso de css que normalicen los estilos entre los navegadores, por ejemplo normalize.css
- HTML: Se usara HTML4 siempre y cuando la tecnologia de sus clientes no le permitan hacer uso de html5.
Otras detalles a la hora de desarrollar:
- Seguir el estándar w3c
- Evitar el uso de "hacks", sobre todo hacks de CSS
- No extender el DOM
- Hacer test automáticos de la interfaz
2. Comunicación entre cliente servidor
Para la comunicación cliente servidor, siempre y cuando no haya ningún inconveniente de aplicación de la tecnológica por obsolescencia en los navegadores, será de obligado cumplimiento hacer uso de fetch para articularla.
Dicho modelo se basa en la siguiente especificación viva https://fetch.spec.whatwg.org/#http-network-fetch.
Tenga en cuenta aspectos concretos que pueden resultarle nuevos por el modo en que los navegadores modernos manejan la comunicación, cómo:
- Capitalización en las cabeceras
- Preste atención al modo en que fetch ha de tratar las cabeceras
- Todas las propiedades de las cabeceras a incluir han de ser byte-case-insensitive, aunque se recomienda el uso de: PascalCase (capitalizando todas las palabras) + kebab-case (separando las palabras con guiones) → p.e. "Content-Type"
- Preste atención al modo en que fetch ha de tratar las cabeceras
- Preflight requests
- Fetch hace uso en las implementaciones mas recientes de una llamada previa conocida como "preflight request" que permiten a su cliente web determinar que verbos están disponibles para un recurso rest, y que cabeceras serán obligatorias en posteriores peticiones a dicho recurso. Si su solución contiene tanto una implementación del cliente web y el servidor del recurso, siga las consideraciones indicadas en la información relativa a la implementación de soluciones de servicios rest.
Vista general
Herramientas de contenido
- Impreso por Atlassian Confluence 8.7.2