Download - TesisFinal 30-12-12
1
Contenido CAPITULO I .................................................................................................................................. 10
PLANTEAMIENTOS GENERALES ................................................................................................... 10
1.1. DESCRIPCION DEL PROBLEMA ..................................................................................... 11
1.2. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 11
1.3. OBJETIVOS ................................................................................................................... 11
1.3.1. OBJETIVO PRINCIPAL ........................................................................................... 11
1.3.2. OBJETIVOS ESPECÍFICOS ...................................................................................... 12
1.3.3. JUSTIFICACION ..................................................................................................... 12
1.3.4. MÉTODOLOGIA DE INVESTIGACIÓN .................................................................... 13
1.3.5. LIMITACIONES ..................................................................................................... 14
1.3.6. BENEFICIOS DEL PROYECTO ................................................................................ 14
CAPITULO II ................................................................................................................................. 15
REVISION BIBLIOGRAFICA .............................................................. ¡Error! Marcador no definido.
2.1. ANTECEDENTES ........................................................................................................... 16
2.1.1. CAIRNGORM ........................................................................................................ 16
2.1.2. MATE ................................................................................................................... 18
2.1.3. SWIZ..................................................................................................................... 19
2.1.4. BACKBONE ........................................................................................................... 20
2.1.5. SPROUTCORE MVC .............................................................................................. 21
2.1.6. SAMMY ................................................................................................................ 22
2.1.7. MVC EXTJS ........................................................................................................... 23
2.2. MARCO CONCEPTUAL ................................................................................................. 24
2.2.1. INTERNET ............................................................................................................. 24
2.2.2. LA WORL WIDE WEB (WWW).............................................................................. 25
2.2.3. TECNOLOGIAS DEL LADO DEL SERVIDOR ............................................................ 53
2.2.4. TECNOLOGIAS DEL LADO DEL CLIENTE ................................................................ 58
2.2.5. FRAMEWORK ....................................................................................................... 76
2.2.6. PATRON DE DISEÑO ............................................................................................ 76
2.2.7. SCRUM ............................................................................................................... 101
CAPITULO III .............................................................................................................................. 105
ESTUDIO DE FRAMEWORKS PARA LA IMPLEMENTACION DE APLICACIONES WEB DEL LADO DEL
CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML ........................................................................ 105
2
3.1. DOJO TOOLKIT ........................................................................................................... 106
3.1.1. ORIGEN Y DESARROLLO ..................................................................................... 106
3.1.2. CARACTERÍSTICAS .............................................................................................. 107
3.1.3. ARQUITECTURA ................................................................................................. 109
3.2. EXTJS .......................................................................................................................... 110
3.2.1. CORE .................................................................................................................. 111
3.2.2. UI COMPONENTS ............................................................................................... 111
3.2.3. WEB REMOTING ................................................................................................ 114
3.2.4. DATA SERVICES .................................................................................................. 114
3.2.5. DRAG AND DROP ............................................................................................... 114
3.2.6. GENERAL UTILITIES ............................................................................................ 114
3.3. YUI (INTERFAZ DE USUARIO YAHOO) ........................................................................ 115
3.3.1. NÚCLEO ............................................................................................................. 115
3.3.2. UTILIDADES ........................................................................................................ 116
3.3.3. CONTROLES / WIDGETS ..................................................................................... 117
3.3.4. CSS HERRAMIENTAS .......................................................................................... 118
3.3.5. HERRAMIENTAS DE DESARROLLO ..................................................................... 118
3.3.6. HERRAMIENTAS DE CONTRUCCIÓN .................................................................. 119
CAPITULO IV .............................................................................................................................. 120
IMPLEMENTACION DE FRAMEWORK MODELO VISTA PRESENTADOR PARA APLICACIONES WEB
DEL LADO DEL CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML ................................................ 120
4.1. DESCRIPCION DEL PROBLEMA ................................................................................... 121
4.2. RESUMEN DEL PROYECTO ......................................................................................... 121
4.3. BENEFICIOS ................................................................................................................ 122
4.4. DESCRIPCIÓN DE LA METODOLOGÍA DE TRABAJO .................................................... 122
4.4.1. INTRODUCCIÓN ................................................................................................. 122
4.4.2. DESCRIPCIÓN GENERAL DE LA METODOLOGÍA ................................................. 123
4.4.3. PERSONAS Y ROLES DEL PROYECTO. ................................................................. 124
4.4.4. ARTEFACTOS ...................................................................................................... 124
4.4.5. RESUMEN DE SPRINTS ....................................................................................... 129
CONCLUSIONES ......................................................................................................................... 139
RECOMENDACIONES ................................................................................................................. 141
BIBLIOGRAFÍA ..…………………………………………………………………………………………………………………… 142
3
PRESENTACIÓN
SEÑOR DECANO DE LA FACULTAD DE CIENCIAS QUÍMICAS, FÍSICAS Y
MATEMÁTICAS DE LA UNIVERSIDAD NACIONAL SAN ANTONIO ABAD
DEL CUSCO.
SEÑORES MIEMBROS DEL JURADO:
De acuerdo al Reglamento de Grados y Títulos vigentes para optar el
Título Profesional de Ingeniero Informático y de Sistemas ponemos a vuestra
disposición la Tesis colectiva, intitulada “FRAMEWORK PARA LA
IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA PRESENTADOR EN
CLIENTES WEB (HTML-JAVASCRIPT)” que abarca el estudio de frameworks
para la implementación de clientes web basados en JavaScript, CSS y HTML.
Así como el desarrollo de un framework alternativo que mejore el desarrollo,
escalabilidad y mantenibilidad de dichos clientes.
Esperando que los señores dictaminantes y miembros del jurado,
dispensen las deficiencias encontradas y valoren el contenido desarrollado que
trata de dar un aporte tecnológico a la sociedad en general.
Los Tesistas.
4
AGRADECIMIENTOS
Agradecer de manera especial a nuestro Asesor, Lic. José Mauro Pillco
Quispe por el tiempo y la dedicación prestados para el desarrollo de esta
Tesis.
A todas las personas que han colaborado en el desarrollo de esta Tesis.
5
DEDICATORIAS
A mi madre
Por brindarme una carrera, creer en mí y con su vida convencerme que la
fuerza de voluntad es suficiente para lograr lo que uno desee.
A Marleny.
Por confiar y creer siempre en mí.
A la memoria de mi padre
A mis amigos y amigas
Quienes participaron, aún sin saberlo, en lograr este objetivo.
Jorge Francisco Castro Alvarez
6
A mis padres
Por su apoyo incondicional a pesar que no siempre supe corresponderles
tanto cariño y paciencia, que tuvieron en todos estos años. Por brindarme
una carrera, creer en mí y con sus vidas convencerme que la fuerza de
voluntad es suficiente para lograr lo que uno desee. Y sobre todo por su
amor.
A mis hermanos
Por confiar y creer siempre en mí, gracias por ser los mejores hermanos los
quiero mucho.
A mis amigos y amigas
Que están ahí lejos o cerca de uno, pero que siempre estarán en mi
corazón.
Luis Rafael Callapiña Cosio
Sólo un exceso es recomendable en el mundo: el exceso de gratitud.
Jean de la Bruyère
7
RESUMEN
En la actualidad las aplicaciones web del lado del cliente necesitan un
comportamiento similar a la de las aplicaciones de escritorio tradicionales,
que permitan combinar el alcance de la Internet con una interfaz de usuario
enriquecida, con el fin de mejorar la productividad, este tipo de aplicaciones
son conocidas con el nombre de Rich Internet Application (RIA).
Hoy en día esas experiencias de usuario enriquecidas son mayormente
implementadas en tecnologías como Flash, Silverlight, JavaFX, las mismas
que vienen siendo remplazadas progresivamente por HTML5 (HTML,
JavaScript y CSS3).
El avance de las RIAs y el uso de tecnologías como Ajax, REST, Web
Services, JSON-RPC, XML-RPC, AMF, entre otros han hecho posible crear
aplicaciones web del lado del cliente con mayor independencia de la
aplicación web del lado Servidor haciendo de esta forma la actualización
modificación y migración de tecnología en el cliente mucho más flexible e
independiente de la implementación del Servidor. Generando con esto el
desarrollo de diferentes Frameworks implementados en JavaScript para la
comunicación entre el cliente y el Servidor así como para el manejo, control
y actualización del DOM (Modelo de Objetos de Documento).
Hoy en día se cuenta con un número considerable de frameworks que
permiten la implementación de aplicaciones web del lado del cliente, siendo
una cantidad considerable de estos orientados a documentos y otros pocos
a aplicaciones web que consumen datos.
Entre los framework más completos, maduros, que gozan de una
popularidad considerable y permiten la implementación de aplicaciones web
del lado del cliente que consumen datos tenemos: EXTJS, YUI (interfaz de
usuario Yahoo) y DojoToolkit.
Esta tesis se enfoca en el desarrollo de un Framework que permita
implementar el patrón modelo vista presentador (MVP), haciendo uso de
inyección de dependencia y de archivos XML para la definición de las
interfaces gráficas. Ofrece información preliminar acerca de la Web, una
8
visión general de tecnologías del lado del cliente, e identifica las diferentes
soluciones existentes para la implementación patrones de diseño como
modelo vista controlador (MVC) en aplicación web del lado del cliente
basadas en HTML, JavaScript y CSS.
9
ABSTRACT
Currently Web applications require client side behavior similar to that of
traditional desktop applications, that combine the scope of the Internet with a
rich user interface in order to enhance productivity, these applications are
known by the name of Rich Internet Application (RIA).
Today those rich user experiences are mostly implemented in technologies
such as Flash, Silverlight, JavaFX, the same that are being progressively
replaced by HTML5 (HTML, JavaScript and CSS3).
The advance of RIAs and the use of technologies such as Ajax, REST, Web
Services, JSON-RPC, XML-RPC, AMF, etc.. They can create web clients
miss more independently of the server-side application thus making
modification and updating of technology migration on the client much more
flexible and independent of the server implementation. Generating this
development with different JavaScript Frameworks implemented for
communication between client and server as well as for management, control
and update the DOM (Document Object Model).
Today there is a considerable number of client-side frameworks that allow
the implementation of web applications on the client side, with a considerable
amount of these document-oriented applications and a few other web
oriented data processing.
Among the most comprehensive framework, mature, enjoying considerable
popularity and allow the implementation of web applications on the client side
oriented data processing are: ExtJS, YUI (Yahoo User Interface) and Dojo
Toolkit.
This thesis focuses on the development of a framework that allows to
implement the Model View Presenter pattern (MVP), using dependency
injection and XML files for defining GUIs. Provides preliminary information on
the Web, an overview of client-side technologies, and identifies the various
existing solutions for implementing design patterns such as Model View
Controller (MVC) Web Application client side based on HTML, JavaScript
and CSS.
10
CAPITULO I
PLANTEAMIENTOS
GENERALES
11
1.1. DESCRIPCION DEL PROBLEMA
Actualmente existe un número considerable de framework para la
implementación de patrones de programación en el desarrollo de
aplicaciones web. Sin embargo la mayoría de estos fueron
implementados en tecnologías que se ejecutan del lado del Servidor
generando con esto una dependencia innecesaria entre las aplicaciones
del lado del cliente y la del Servidor.
El desarrollo de las tecnologías como XML, JSON, HTML, JavaScript y
CSS3 ha permitido la aparición de diferentes Framework que facilitan el
manejo del DOM (Modelo de Objetos de Documento), la comunicación
entre el cliente y el Servidor así como también la implementación de
patrones de diseño como modelo vista controlador, modelo vista
presentador, etc.
A pesar de existir múltiples Framework para la implementación de
patrones de programación basados en HTML, JavaScript y CSS3, estos
carecen de claridad y eficiencia a la hora de utilizarlos y en especial en
la definición de las interfaces de usuario ya que las definen mediante
código JavaScript, generando problemas sustancialmente importantes
que afectan el tráfico, la mantenibilidad, la escalabilidad del sistema y
tiempo de aprendizaje de los desarrolladores.
1.2. PLANTEAMIENTO DEL PROBLEMA
¿Cómo resolver el problema de legibilidad, mantenibilidad, escalabilidad
y reutilización de código en las aplicaciones web del lado del cliente
basadas en HTML, JavaScript y CSS?
¿Resuelven los framework existentes los problemas de legibilidad,
mantenibilidad, escalabilidad y reutilización de código?
1.3. OBJETIVOS
1.3.1. OBJETIVO PRINCIPAL
Implementar un Framework para la implementación del patrón Modelo
12
Vista Presentador en clientes web basados en tecnologías HTML y
JavaScript.
1.3.2. OBJETIVOS ESPECÍFICOS
Definir y implementar las clases y mecanismos necesarios para
registrar el contrato que debe de existir entre los diferentes
componentes del patrón modelo vista presentador (Vista-
Presentador, Presentador-Modelo).
Implementar una clase que ha de implementar los mecanismos
necesarios para instanciar la interfaz de usuario en un
documento HTML, notificar de sus cambios al Presentador así
como actualizarse a sí misma, en función a las notificaciones
de la clase presentador.
Implementar una clase ancestro para las clases que
representen los presentadores de las aplicaciones la misma
que ha de implementar los mecanismos necesarios para
notificar y actualizar la vista así como modificarse así mismo en
función a las notificaciones que le presenten tanto el modelo
como la vista.
Implementar una clase ancestro para las clases que
representen el modelo de la aplicación, misma que ha de
implementar los mecanismos necesarios para notificar de sus
cambios al presentador y modificarse así mismo en función a
las notificaciones provenientes de las clases que representen el
presentador.
1.3.3. JUSTIFICACION
En la actualidad no contamos con muchos framework basados en
HTML, JavaScript y CSS, orientados a la implementación de patrones
de diseño en aplicaciones web del lado del cliente, aplicaciones que
han sido siempre difíciles de escribir, difícil de organizar y difícil de
mantener. Teniendo una tendencia de crecimiento rápido y sin control
a medida que agrega más funcionalidad y desarrolladores a un
proyecto.
13
Los Frameworks existentes como EXTJS, YUI (interfaz de usuario
Yahoo) y Dojo Toolkit permiten crear aplicaciones web del lado del
cliente con características similares a las de una aplicación de
escritorio a través del acceso al DOM y facilitando la comunicación e
intercambio de datos con el Servidor, pero utilicemos la librería que
utilicemos lo común es tener un montón de código JavaScript que
después minimizamos en un archivo (o varios) para servir en nuestro
sitio web. Esto a la larga se convierte en un infierno de selectores y
callbacks que tenemos que mantener sincronizados con el código
HTML para que sigan funcionando como se espera.
A pesar de que estos frameworks nos permiten implementar el patrón
de diseño modelo vista control aún siguen generando problemas en el
desarrollo, escalabilidad y mantenimiento de las aplicaciones
especialmente en la definición de las interfaces de usuario ya estas
son definidas en el leguaje JavaScript el cual no fue creado para la
definición de interfaces de usuario sino más bien para dar
funcionalidad a las mismas.
Otras de las limitaciones que presentan estos framework son las
inherentes a la implementación de los mismos, como sucede en
EXTJS el mismo que nos obliga a crear un controlador par cada
control de usuario utilizado.
Otra de sus limitaciones que tienen estos frameworks es la inherente
diferencia existente entre el patrón Modelo vista controlador y el
patrón modelo vista presentador ya que el primero obliga a
implementar un controlador por cada vista para poder ejecutar las
acciones solicitadas a través de las interacciones con el usuario.
Mientras que en el segundo la vista es la encargada de responder al
usuario.
1.3.4. MÉTODOLOGIA DE INVESTIGACIÓN
La metodología del trabajo de investigación es “Descriptiva y
Aplicativa”. Descriptiva porque describirá las características del
proyecto. Aplicativa porque permitirá resolver el problema, alcanzar
los objetivos y evaluar los resultados. La metodología tecnológica que
14
se usara será el marco de trabajo denominado SCRUM que se apoya
sobre la metodología de Programación Extrema o extreme
Programming (XP). Se eligieron estos modelos de trabajo.
1.3.5. LIMITACIONES
Este proyecto, tiene por objetivo crear un Framework para la
implementación del patrón modelo vista presentador en aplicaciones
clientes basados en tecnología HTML, JavaScript y CSS. En este
entender el proyecto no se encargara del desarrollo de librerías para
el manejo del Modelo de Objetos del Documento (DOM), así como
tampoco de la implementación de controles de usuario para la
renderizacion de las vistas motivo por el cual se usaran librerías
implementadas por terceros.
1.3.6. BENEFICIOS DEL PROYECTO
Al implementar el Framework Modelo Vista Presentador podrá
resolverse la mayoría de los problemas existentes en la
implementación de clientes HTML-JavaScript.
En este trabajo se identifican los beneficios de las RIAs y sus ventajas
sobre las aplicaciones web tradicionales.
En este trabajo se identifican las ventajas y desventajas de los
diferentes framework existentes.
15
CAPITULO II
MARCO TEÓRICO
16
2.1. ANTECEDENTES
El primer intento de mejorar la usabilidad de las aplicaciones web,
acercándolas más a sus contrapartes de escritorio, fue realizado por Sun
Microsystems con la introducción de los Applets Java. En un principio la
única tecnología que nos permitía desarrollar clientes web, a pesar de
sus ventajas, en dicha época los ordenadores carecían del poder de
computo necesario para poder ejecutar ligeramente este tipo de
aplicaciones, así como la falta de velocidades aceptables para la
conexión conllevaron a una mala aceptación de esta tecnología,
impidiendo que se logren desarrollar frameworks dedicados a la
implementación de patrones de diseño.
Otra tecnología que intento llevar la experiencia de las interfaces de
escritorio a la web es Adobe Flash. La misma que gozo de gran
aceptación en su momento, permitiendo el desarrollo de frameworks
especializados en la implementación de diferentes patrones de diseño,
entre los que podemos mencionar:
2.1.1. CAIRNGORM
Es el más antiguo y el más conocido de los framework hechos para
Flex Builder. En realidad, es una micro-arquitectura, es decir, una
colección de patrones de diseño que han demostrado que funcionan
bien con otros, Se basa en el patrón MVC y ha diseñado
específicamente para facilitar la sincronización de estados y de datos
entre el cliente y el Servidor, mientras se mantiene la programación de
la capa de vista separada de la aplicación de datos.
La construcción de un proyecto en Cairngorm implica dividir la
aplicación en varios paquetes y que se extiende a las clases
Cairngorm, entre las secciones principales y clases de este tipo de
proyectos tenemos:
ModelLocator._ Es un singleton1 que actúa como un
repositorio de datos-representa el estado del programa. La
naturaleza de la clase singleton garantiza que todos los
1 SINGLETON: está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único
objeto, véase: http://es.wikipedia.org/wiki/Singleton.
17
componentes del programa tienen acceso a los mismos datos.
ServiceLocator._ es otro singleton que actúa con una
ubicación centralizada para el almacenamiento de servicios
tales como HTTP Services. Una vez más, porque esta clase es
un producto único, todos los componentes del programa
tendrán acceso a los mismos servicios.
Lógica empresarial._ se encapsula en clases de comandos
que implementan el patrón de comando. Estas clases
representan la lógica que responde a eventos de usuario.
Los eventos._ Estos manejados por el front Controller
(Controlador frontal) clase, que ejecuta los comandos
apropiado para ese evento. Cada evento de usuario que el
programa debe responder tiene que estar registrada en esta
clase junto con su clase de comando correspondiente.
Clases de delegado._ se utilizan como indicadores para el
acceso y responder a servicios remotos.
Fig. 1. Flujo de Cairngorm
Fuente: http://internetdeveloping.blogspot.com/2009/04/empezando-con-cairngorm-
desarrollando.html
18
2.1.2. MATE
Fue creado para poder implementar el patrón Modelo Vista
Presentador y sincronizar los datos del cliente con los del Servidor en
aplicaciones Adobe Flex, basado en eventos y manejadores de
eventos los mismos que hacen uso de etiquetas básicas MXML para
poder enlazar las vistas con el presentador.
Mate también implementa la idea de inyección de dependencia, a
veces se denominada el principio de Hollywood, o "no nos llame,
nosotros lo llamaremos". Los objetos se construyen de tal manera que
los datos que estos requieren se le es proporcionado o se les inyecta
en la clase. En otras palabras, las clases no llaman para obtener los
datos ("no nos llame"), sino que se pasan los datos que necesitan ("te
llamaremos") a través de inyección de dependencia para así poder
sincronizar los cambios del modelo en el presentador.
Fig.2.Flujo de Mate
Fuente: http://mate.asfusion.com/archives/category/examples
19
2.1.3. SWIZ
Swiz es un framework de inversión de dependencia (IoC) framework
que proporciona metodologías para simplificar la gestión de eventos y
llamadas asincrónicas a métodos remotos. El foco principal del
framework Swiz es proporcionar un verdadero paradigma MVC en una
manera simple y efectiva. A diferencia de Cairngorm y PureMVC,
específicamente huye de la imposición de patrones de Java y no
impone ninguna estructura de carpetas predefinida.
Para crear un proyecto Swiz tenemos que indicar al framework acerca
de los componentes de la aplicación. En su esencia, Swiz es una
fábrica centralizada. Los componentes se cargan en la fábrica a
través de una clase BeanLoader. Cuando se inicia la aplicación, la
fábrica se encarga de la creación de instancias de sus componentes.
Swiz también proporciona gestión de la dependencia a través de
metatag (información adicional de la cual hace uso el framework para
poder definir la dependencia entre objetos) personalizado llamado
Autowire. Esta etiqueta es un método de definición de las
dependencias entre clases Swiz.
Fig.3.Flujo de SWIZ
Fuente: http://swizframework.jira.com/wiki/display/SWIZ/Home
20
Posteriormente la evolución y mejoras de tecnologías como HTML,
JavaScript y CSS. Permitieron crear clientes aplicaciones ricas en
internet, lo que conllevo al desarrollo de múltiples tipos de frameworks
para el manejo del DOM, sincronización de datos con el Servidor e
implementación de diferentes patrones de diseño entre los que podemos
mencionar:
2.1.4. BACKBONE
Backbone fue creado para poder implementar en clientes web
JavaScript el Patrón Modelo Vista Controlador permitiéndonos
configurar/separar nuestra aplicación dependiendo de lo que
necesitamos realizar. Así Backbone nos presenta las tres capas de la
siguiente forma:
Capa Modelo._ Backbone nos entrega dos clases (aceptemos
llamar clase a los objetos JavaScript que intentan tener un
comportamiento similar a una clase POO) que realizan
acciones de almacén de datos y comunicación con el Servidor.
Backbone.Model y Backbone.Collection, en donde cada una
tiene sus funciones y métodos específicos.
Capa Vista._ Aquí Backbone provee una sola clase llamada
Backbone.View, que cuenta con métodos y funciones que
permiten administrar los eventos realizados por el usuario al
interactuar con los elementos de la página.
Capa Controlador._ Backbone cambia el nombre de ésta capa
por otro concepto, pero que básicamente realizan la misma
función: Backbone.Router, su función es manejar los enlaces,
URL y funcionar como una central de acciones.
21
Fig.4.Flujo de Backbone MVC
Fuente: http://www.webvigo.com/blog/backbone-js-estructura-mvc-en-cliente/
2.1.5. SPROUTCORE MVC
SproutCore es un framework de código abierto, permite implementar
el Patrón de Diseño "Modelo, Vista, Controlador", en clientes web
(HTML- JavaScript). Este Framework extiende la arquitectura MVC
tradicional mediante la adición de más de tres capas: Interfaz de
Servidor, Display y Responders.
Models._ Esta capa se encarga de contener los datos de
aplicación y gran parte de la lógica de negocio, tales como
contactos, fotos o correos electrónicos.
Views._ La función de esta capa es de manejar la pantalla y
responder a eventos de usuario, pero en general tienen poco o
ningún conocimiento específico de dominio
Controllers._ Esta capa está encargada de cerrar la brecha
entre las dos capas anteriores, es decir esta se encarga de
sincronizar los cambios en la vista con los cambios en el
modelo.
Server Interface._ Esta capa se encarga de sincronizar datos
entre el Servidor web y la capa del modelo, utilizando
opcionalmente en el cliente almacenamiento local para admitir
22
el modo fuera de línea.
Display._ Es la capa que en realidad renderiza la interfaz de
usuario. Incluye el navegador web y cualquier biblioteca de
bajo nivel de DOM (como jQuery o Prototype).
Responders._ Es la capa que controla el estado general de las
aplicaciones. Aquí es donde se suele poner el código de nivel
superior que configura los modelos, vistas y controladores
basados en el estado de carga u otros factores.
Fig.5.Flujo de SPROUTCORE MVC
Fuente: http://blog.sproutcore.com/tag/statecharts/
2.1.6. SAMMY
Sammy es un framework pequeño y poco conocido, idóneo para
pequeños proyectos, tiene una estructura basada en plugins y
también nos permite implementar el patrón de diseño "Modelo, Vista,
Controlador”, basada en respuesta a URL mediante función JS las
mismas que responde con contenidos HTML que posteriormente
actualizara las secciones correspondientes de la página.
DataModel._ Capa encargada del manejar las entidades y la
comunicación con el Servidor.
ViewModel._ Capa encargada de monitorear los cambios y el
comportamiento y la estructura de los elementos HTML.
Controlador._ Encargada vincular la capa DataModel con la
23
capa ViewModel (conjunto de direcciones URL específica).
2.1.7. MVC EXTJS
ExtJS es un conjunto de frameworks JavaScript que permite
desarrollar potentes aplicaciones del lado del cliente y está orientado
a objetos. Entre los distintos frameworks que contiene esta MVC
EXTJS que nos permite implementar parcialmente el patrón de
diseño Modelo Vista Controlador ya que el concepto de vistas que
maneja está basada en controles de usuario individuales mas no en
una vista completa que estaría representada por un conjunto de
controles visuales. Este framework nos obliga a extender tres clases
que son:
Modelo._ Esta clase nos permite definir y abstraer las
propiedades de una entidad, y se usan para llenar una
colección de datos para luego poder desplegar la información
en un widget como un Grid, View, Combo box, o algún otro
control que permita la visualización de colecciones de datos.
Controlador._ Esta clase nos permite agregar la interacción y
funcionalidad a nuestra aplicación mediante diferentes
funciones que han de enlazarse con los diferentes eventos de
la vista.
Vistas._ Esta clase es la encargada de extender el
componentes o widget, por ejemplo un Grid, un formulario y
todo aquello que se renderiza en la pantalla.
Store._ Este vendría a representar la capa de datos el cual se
encarga de almacenar los modelos para luego ser usados en
un Grid.
24
Fig.6.Flujo de EXTJS MVC
Fuente: http://www.slideshare.net/loianeg/extjs-4-mvc-architecture-mind-map-13669488
2.2. MARCO CONCEPTUAL
2.2.1. INTERNET2
Es un conjunto descentralizado de redes de comunicación
interconectadas, que utilizan la familia de protocolos TCP (Control de
Transmisión) /IP (Protocolo de Internet), garantizando que las redes
físicas heterogéneas que la componen funcionen como una red lógica
única, de alcance mundial. Sus orígenes se remontan a 1969, cuando
se estableció la primera conexión de computadoras, conocida como
ARPANET, entre tres universidades en California y una en Utah,
EE.UU.
Uno de los servicios que más éxito ha tenido en Internet ha sido la
World Wide Web (WWW, o "la Web"), Al contrario de lo que se piensa
comúnmente, Internet no es sinónimo de World Wide Web (WWW, o
"la Web"). Esta es parte de Internet, siendo uno de los muchos
servicios ofertados en la red Internet. La Web es un sistema de
información mucho más reciente, desarrollado inicialmente por Tim
2OCHOA TAPIA GRETTY MAIBELY,TEJADA AUCCACUSI JORGE CARLOS, Estudio De Las Tecnologías Ria Y Data Push De
Servicios Multimedia En Tiempo Real, Universidad Nacional de San Antonio Abad Del Cusco,2010:Pag23
25
Berners Lee en 1989.
La WWW es un conjunto de protocolos que permite, de forma sencilla,
la consulta remota de archivos de hipertexto. Ésta fue un desarrollo
posterior (1990) y utiliza Internet como medio de transmisión.
2.2.2. LA WORL WIDE WEB (WWW)3
La World Wide Web (WWW) emergió en los inicios de la década de
los 90s y se ha convertido rápidamente en el recurso más poderoso
para compartir información. Ha revolucionado los negocios, haciendo
posibles cosas que eran antes inconcebibles, como compras
electrónicas, banca electrónica, televisión en línea, apuestas en línea,
búsquedas en línea, video llamadas, correo electrónico, etc.
Fig. 7. La World Wide Web (WWW): una combinación de DNS, HTTP, HTML y un
navegador web
Fuente: Martin P. Clark. Data Networks, IP and the Internet: Protocols, Design and
Operation. John Wiley& Sons, Ltd., 2003
Cuatro tecnologías surgieron a inicios de los 90s para dar origen a la
World Wide Web. Estas son:
3 MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :
473
26
2.2.2.1. SISTEMA DE NOMBRES DE DOMINIO (DNS)4
La primera piedra angular para la World Wide Web (WWW) fue
establecida a inicios de los 80s, mediante el desarrollo y
especificación del Sistema de nombres de dominios (DNS).
Antes del sistema de nombres de dominios, ya era común en el
sistema operativo UNIX la creación de enlaces de nombres. Estos
enlaces eran registrados bajo un archivo de configuración donde se
relacionaba el nombre de un computador con su ubicación en la red.
Debido a que UNIX era el sistema operativo dominante entre la
comunidad ARPANET, la cual originó la Internet, fue natural extender
la idea de los enlaces de nombres para permitir que cualquier
Servidor UNIX en la ARPANET pueda ser localizado por todos los
demás Servidores.
Inicialmente todas los direcciones de cada host en la ARPANET eran
administradas de manera centralizada, pero a medida que el tamaño
de la red crecía y el número de equipos conectados a la red se
empezaba a multiplicar, este modelo se convirtió poco práctico,
surgiendo así el sistema de nombres de dominio (DNS), el cual era un
servicio de directorio descentralizado.
El sistema de nombres de domino (DNS) es usado básicamente para
mapear un nombre (hostname) de Servidor en la red con una
dirección IP, para localizar dicho Servidor y establecer comunicación
con este. Así es posible resolver la dirección web www.servidor.com a
una dirección IP (por ejm.: 37.168.153.232) del Servidor relacionado.
Utilizando la dirección IP, el Servidor puede ser contactado usando
cualquiera de los protocolos IP.
4 MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :
474
27
Fig. 8. Estructura de los espacios de nombres de dominios
Fuente: Martin P. Clark. Data Networks, IP and the Internet: Protocols, Design and
Operation. John Wiley & Sons, Ltd., 2003
Existen 3 componentes básicos del sistema de nombres de dominio:
El espacio de nombres de dominio.- Define un esquema de
nombres jerárquico para todos los hosts y subredes en un dominio
determinado.
Los Servidores de nombres.- Son programas de Servidor que
almacenan información sobre la estructura de dominios. Un Servidor
de nombres es la autoridad para una parte dada de un espacio de
nombres, el cual puede ser subdividido en zonas. El Servidor de
nombres almacena copias para las zonas para las cuales es la
autoridad.
Los programas de resolución.- Son programas que se ejecutan en
las computadoras del usuario. Extraen, usan y almacenan en cache
información procedente de los Servidores de nombres en respuesta a
pedidos DNS del cliente (denominados consultas). Un programa de
resolución funciona típicamente en un sistema operativo cliente. Un
navegador web usualmente integra esta funcionalidad de resolución.
28
Fig. 9. El Sistema de Nombre de Dominios (DNS) provee de un servicio de búsqueda
Fuente: Martin P. Clark. Data Networks, IP and the Internet: Protocols, Design and
Operation. John Wiley& Sons, Ltd., 2003
2.2.2.2. PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO (HTTP)5
Es un protocolo que permite que documentos sean creados a partir de
múltiples archivos de texto e imágenes, donde cada uno de estos
archivos puede ser almacenado en un computador distinto. Un
hiperenlace es una clase de “puntero” usado para marcar la posición
en un documento donde un texto, imagen u otro deben de apuntar a
la ubicación donde el archivo se encuentra almacenado.
Frecuentemente el hiperenlace aparece en texto como una dirección
de nombre de dominio, precedido por http://www. HTTP es el
protocolo que recupera el archivo señalado por el hiperenlace. La
versión actual del protocolo es la versión 1.2 (HTTP/1.2). El protocolo
de transferencia de hipertexto permite:
Transferencia de datos basada en punteros (por tanto la
recuperación de datos, capacidades de búsqueda o anotación
de documentos científicos con referencias bibliográficas a otros
documentos o reportes).
Hiperenlazar datos mediante enlaces a archivos. El protocolo
HTTP es usado entre un cliente HTTP (también llamado el
5MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :
465
29
agente de usuario - UA) y el Servidor de origen HTTP. El
hiperenlace existe para conectar un puntero residente en el
cliente con el archivo de datos real alojado en el Servidor de
origen. El archivo hiperenlazado es recuperado utilizando una
secuencia de pedidos y respuestas http.
Fig. 10. HTTP: Cadenas de solicitud y respuesta
Fuente: Martin P. Clark. Data Networks, IP and the Internet: Protocols, Design and
Operation. John Wiley& Sons, Ltd., 2003
2.2.2.2.1. AGENTE DE USUARIO, SERVIDOR DE ORIGEN E
INTERMEDIARIOS HTTP6
Las solicitudes HTTP (HTTP requests) son generadas por el cliente
(agente de usuario) y la cadena de petición es pasada al Servidor
de origen. La respuesta HTTP (HTTP response) es devuelta por
medio de la cadena de respuesta. Tanto las solicitudes como las
respuestas son transportadas normalmente a través del puerto
TCP 80.
Los intermediarios HTTP pueden ser proxys o caches. Dichos
dispositivos no están siempre presentes, pero son usados a veces
para incrementar la seguridad de acceso a determinado Servidor
HTTP (si se usa un proxy) o para mejorar la velocidad de respuesta
de una petición HTTP (si se usa un cache).
Un proxy HTTP se encuentra generalmente cerca del Servidor de
origen (por ej. Un firewall que asegura un Servidor web). El proxy
discrimina las solicitudes HTTP dirigidas hacia el Servidor de
origen. Las solicitudes no permitidas son resueltas con un error por
parte del Servidor proxy.
6 MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :
466
30
Un Servidor de cache se encuentra generalmente cerca, y en
beneficio del agente de usuario. El Servidor de cache almacena
todas las respuestas recibidas en la cadena de respuesta,
permitiendo que las solicitudes subsecuentes de los mismos
recursos sean resueltas por este sin tener que repetir la petición al
Servidor de origen.
URIs, URLs y URNs7
El URI de solicitud (Universal Resource Identifier / Identificador de
Recurso Universal) es una combinación de un URL (Universal
Resource Locutor / Localizador de Recurso Universal: que localiza
un recurso de red) y un URN (Universal Resource Name / Nombre
de Recurso Universal: que localiza un archivo en particular). Un
URI HTTP tiene el siguiente formato estándar:
http://host [:puerto] / ruta_abs [?consulta]
Donde host es el nombre de dominio del Servidor HTTP, puerto es
el número de puerto TCP a ser usado para la transferencia del
protocolo HTTP, ruta_abs es la ruta absoluta hacia el archivo de
destino y consulta es la información relacionada con la solicitud. Si
el puerto no se específica, el puerto por defecto (80) es usado. Un
ejemplo de URI podría ser:
http://WWW.Servidor.com:80/ventas/index.html
2.2.2.2.2. SOLICITUDES Y RESPUESTAS HTTP8
SOLICITUD HTTP
Las solicitudes HTTP (generados por el cliente HTTP o agente de
usuario) incluyen la siguiente información:
Un método de solicitud (por ejm. Un comando como GET,
POST, PUT, DELETE, etc.);
Un identificador de recurso universal (URI) (Universal
Resource Identifier) (también llamado identificador de
documento universal) un URI es equivalente a la
7MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :
472 8HANS BERGSTEN. JAVA SERVER PAGES™, 2nd Edition, O'Reilly, 2002 : 20
31
combinación del localizador universal de recurso (URL)
(Universal Resource Locator) y del nombre universal de
recurso (URN) (Universal Resource Name). Este es el
localizador de archivo o “puntero” el cual indica donde el
protocolo HTTP puede localizar el archivo solicitado.
La versión del protocolo HTTP.
Información acerca del cliente que realiza la solicitud; y
Información adicional que forma parte de la solicitud (si se
requiere).
Los primeros tres elementos listados arriba forman juntos la línea
de solicitud HTTP. Una línea de solicitud HTTP podría ser:
GET http://www.servidor.com/ventas/ordenes.html HTTP/1.1
De entre los tres parámetros el más importante es el método.
HTTP/1.1 incorpora ocho métodos, aunque sólo obliga a
implementar GET y HEAD, siendo todos los demás opcionales. En
cualquier caso, los Servidores que implementen alguno de los
métodos adicionales, deben atenerse a la especificación de los
mismos. Existe también la posibilidad de implementar métodos
extendidos, a los que la especificación no pone ningún límite.
METODOS HTTP
Tabla Nº1
Método Significado
GET Devuelve el recurso identificado en la URL pedida.
HEAD Funciona como el GET, pero sin que el Servidor
devuelva el cuerpo del mensaje. Es decir, sólo se
devuelve la información de encabezado.
POST Indica al Servidor que se prepare para recibir
información del cliente. Suele usarse para enviar
información desde formularios.
PUT Envía el recurso identificado en la URL desde el
32
cliente hacia el Servidor.
OPTIONS Pide información sobre las características de
comunicación proporcionadas por el Servidor. Le
permite al cliente negociar los parámetros de
comunicación.
TRACE Inicia un ciclo de mensajes de petición. Se usa para
depuración y permite al cliente ver lo que el Servidor
recibe en el otro lado.
DELETE Solicita al Servidor que borre el recurso identificado
con el URL.
CONNECT Este método se reserva para uso con proxys.
Permitirá que un proxy pueda dinámicamente
convertirse en un túnel. Por ejemplo para
comunicaciones con SSL.
Fuente: MARTIN P. CLARK. DATA NETWORKS
El método GET es el método por defecto para seguir enlaces y
enviar datos a través de Internet. Después de pulsar sobre un
enlace, el navegador enviará el método GET. Si pulsamos sobre el
botón de envío (Submit) de un formulario y dentro de la etiqueta
<FORM> su propiedad METHOD es igual a GET.
En HTTP/1.0 sólo se especificaban tres métodos, GET, POST y
HEAD. Estos son, con mucha diferencia, los tres más extendidos y
utilizados
Después del método completo de petición, se suele enviar los
encabezados de solicitud HTTP.
ENCABEZADOS DE SOLICITUD HTTP
Tablas Nº 2
Nombre Descripción
Accept Tipo de contenido aceptado por el navegador (por
ejemplo, texto/html).
Accept-Charset Juego de caracteres que el navegador espera
33
Accept-Encoding Codificación de datos que el navegador acepta
Accept-Language Idioma que el navegador espera (de forma
predeterminada, inglés)
Authorization Identificación del navegador en el Servidor
Content-Encoding Tipo de codificación para el cuerpo de la solicitud
Content-Language Tipo de idioma en el cuerpo de la solicitud
Content-Length Extensión del cuerpo de la solicitud
Content-Type Tipo de contenido del cuerpo de la solicitud (por
ejemplo, texto/html). Consulte Tipos de MIME
Date Fecha en que comienza la transferencia de datos
Forwarded Utilizado por equipos intermediarios entre el navegador y
el Servidor
From Permite especificar la dirección de correo electrónico del
cliente
Link Vínculo entre dos direcciones URL
Orig-URL Dirección URL donde se originó la solicitud
Referer Dirección URL desde la cual se realizó la solicitud
User-Agent Cadena con información sobre el cliente, por ejemplo, el
nombre y la versión del navegador y el sistema operativo
Fuente: MARTIN P. CLARK. DATA NETWORKS
El encabezado de petición Accept es el más usado, indica al
Servidor que tipo de respuesta puede tratar el navegador.
El encabezado de petición Accept tiene la siguiente sintaxis
general:
Accept: tipo-informacion; calidad
El tipo de datos o información se describe mediante los tipos MIME
(Multipart Internet Mail Extension) estos son una forma abierta y
extensible de representar el contenido de los datos. Como su
nombre indica fueron en un primer momento utilizados para
34
extender las características del correo electrónico, hoy su uso se
ha generalizado, también puede llamárseles IMT (Internet Media
Types).
Los MIME se componen de un tipo y un subtipo, como ejemplo, un
archivo que es un documento de texto y que ha sido escrito en
HTML, tendrá como tipo MIME:
text/html
El registro de los tipos MIME los controla la IANA (Internet Asigned
Numbers Authority) y en su sitio Web se puede obtener la lista
completa y actualizada de los tipos registrados. Es importante el
registro de tipos MIME, esto asegura que dos tipos de contenido
distintos no acaban con el mismo nombre. El prefijo especial “x-
“queda reservado para tipos experimentales (desplegados sin que
haya terminado el proceso de registro) o tipos de uso interno de
organizaciones, por ejemplo:
image/x-fwf
El protocolo HTTP usa tipos MIME en sus encabezados, por
ejemplo para:
Informar al cliente el tipo de datos que está recibiendo del Servidor.
Esto se hace con el encabezado Content-Type. Por ejemplo, un
navegador típico puede manejar los datos de tres maneras distintas
según el tipo MIME indicado en Content-Type :
Visualizar el documento, por ejemplo con tipos text/html .
Llamar a una aplicación externa, por ejemplo con tipos
application/pdf.
O preguntarle al usuario que hacer ante un tipo que no se entiende,
por ejemplo
image/x-fwf .
Permitir la negociación de contenido. El cliente, en su petición
incluye los tipos MIME que acepta. Por ejemplo, un navegador
puede soportar documentos de tipo application/zip , lo indicará con
el encabezado HTTP:
Allow: application/zip
35
Encapsular una o más entidades dentro del cuerpo de mensaje,
mediante los tipos MIME multipart. Quizá el ejemplo más conocido
sea el tipo:
multipart/form-data
El tipo multipart/form-data ha sido definido para encapsular los
datos de un formulario en su envío hacia el Servidor mediante el
método POST.
En la siguiente tabla aparecen los tipos MIME más comunes:
Tabla Nº3
Tipo MIME Descripción
Application Indica al Servidor que aplicación ejecutar basándose en
la extensión del fichero.
Audio Especifica el tipo de audio que puede tratar el
navegador. Suele ser basic, x-aiff y x-wav.
Image Especifica el tipo de imagen que puede tratar el
navegador. Suele ser gif y jpeg.
Text Especifica el tipo de texto que puede ser manejado por el
navegador. Comúnmente los tipos de texto son: html,
plain, richtext y x-setext.
Video Especifica el tipo de video que puede ser tratado por el
navegador. Suele ser: mpeg y QuickTime.
Fuente: MARTIN P. CLARK. DATA NETWORKS
Mediante el factor de calidad que aparece junto al tipo de contenido
que se espera recibir, podremos acortar los tiempos de descarga,
ya que si no indicamos una calidad de 100% no se enviarán los
datos completos de la URL, sino una versión más reducida. Para
indicar que podemos aceptar audio con una calidad del 50% el
encabezado Accept deberá contener lo siguiente:
Accept: audio/*; q=0.5
El asterisco del ejemplo indica que podemos recibir cualquier
fichero de audio, pero podremos indicar una extensión para limitar
36
el tipo de ficheros de audio. Si no queremos limitar el tipo de datos
que se quiere recibir escribiremos: */*. El formato para indicar la
calidad del recurso es: q=factor. Cuando factor es igual a 1
estamos indicando el 100% de la calidad.
El método GET y el encabezado Accept son los encabezados de
petición HTTP más comunes. Y dentro de los tipos MIME, los más
comunes son los de texto (text), audio (audio) e imágenes (image).
Los textos estándar dentro de Internet son html y plain, y para las
imágenes son válidos los formatos jpeg y gif.
RESPUESTA HTTP
El Servidor HTTP (Servidor de origen) responde a una petición http
con una respuesta http que incluye:
Una Línea de Estado de respuesta (a cual está comprendida
por la versión del protocolo HTTP y un código de éxito o de
error).
Los campos del encabezado de respuesta, que son un
conjunto de líneas opcionales que permiten aportar
información adicional sobre la respuesta y/o el Servidor.
Cada una de estas líneas está compuesta por un nombre
que califica el tipo de encabezado, seguido por dos puntos
(:) y por el valor del encabezado.
Un archivo de datos formateado en uno de los formatos
MIME estándares conteniendo información proporcionada
por el Servidor en el cuerpo de la respuesta a la petición.
Otra información de respuesta.
ENCABEZADOS DE RESPUESTA
Tablas Nº4
Nombre Descripción
Content-
Encoding Tipo de codificación para el cuerpo de la respuesta
37
Content-
Language Tipo de idioma en el cuerpo de la respuesta
Content-Length Extensión del cuerpo de la respuesta
Content-Type Tipo de contenido del cuerpo de la respuesta (por
ejemplo, texto/html).
Date Fecha en que comienza la transferencia de datos
Expires Fecha límite de uso de los datos
Forwarded Utilizado por equipos intermediarios entre el navegador y
el Servidor
Location Redireccionamiento a una nueva dirección URL
asociada con el documento
Server Características del Servidor que envió la respuesta
Fuente: MARTIN P. CLARK. DATA NETWORKS
LOS CÓDIGOS DE RESPUESTA
Son los códigos que se ven cuando el navegador no puede mostrar
la página solicitada. El código de respuesta está formado por tres
dígitos: el primero indica el estado y los dos siguientes explican la
naturaleza exacta del error.
Tabla Nº5
Código Resultado Descripción
200 OK La petición se ha servido sin problemas
202 Accepted
La petición ha sido aceptada pero todavía
se está procesando.
301 Moved
El documento se ha trasladado a una
nueva localización.
302 Found
El documento está en el Servidor pero en
una localización diferente.
400 BadRequest La sintaxis de la petición es incorrecta.
38
401 Unauthorized
(AUTH_TYPE)
El Servidor tiene restricciones sobre este
documento.
403 Forbidden.
La petición se ha prohibido, debido a
derechos de accesos o por otras razones.
404 NotFound La petición no se ha podido encontrar.
500 Internal Error
El Servidor ha fallado inesperadamente al
intentar servir la petición
502 Serviceisoverloaded
El Servidor no puede procesar más
peticiones ahora.
Fuente: MARTIN P. CLARK. DATA NETWORKS
2.2.2.2.3. HIPERTEXT MARKUP LANGUAGE (HTML-LENGUAJE DE
MARCAS DE HIPERTEXTO)
Es un lenguaje usado para formatear “documentos” para su
visualización el cual incluye comandos para recuperar texto,
imágenes y otros recursos en la World Wide Web.
HTML es una aplicación de SGML (Standard Generalized Markup
Language) el cual es un sistema para la organización y etiquetado
de documentos, este sirve para especificar las reglas de etiquetado
de documentos y no impone ningún conjunto de etiquetas en
especial.
El propósito principal del HTML era las referencias cruzadas entre
investigaciones científicas con hiperenlaces que daban acceso
directo a los documentos referidos.
En noviembre de 1995 se aprobó el estándar HTML 2.0 para la
creación de páginas web. Se creó con objetivos divulgativos,
orientado a la actividad académica, en el que el contenido de las
páginas era más importante que el diseño.
Pero esta versión del HTML carecía de muchas herramientas que
permitieran controlar el diseño de las páginas y añadir contenido
multimedia, por lo que Netscape (cuyos navegadores eran los más
utilizados por aquellos años) comenzó a incluir nuevas etiquetas
que no existían en el estándar.
39
El comité encargado de establecer los estándares dentro de
Internet, comenzó a trabajar en el borrador de una nueva versión
de HTML, el borrador de HTML 3.0.
Pero este borrador resultó demasiado extenso, al intentar incluir
numerosos nuevos atributos para etiquetas ya existentes, y la
creación de otras muchas etiquetas nuevas. Por ello, no fue bien
aceptado por el mercado y varias compañías se unieron para
formar un nuevo comité encargado de establecer los estándares
del HTML. Este comité pasó a llamarse W3C.
En enero de 1997 se aprobó el estándar HTML 3.2. Este nuevo
estándar incluía las mejoras proporcionadas por los navegadores
Internet Explorer y Netscape Navigator, que ya habían realizado
extensiones sobre el estándar HTML 2.0.
En diciembre de 1997 se aprobó el estándar HTML 4.0, creado
para estandarizar los marcos (frames), las hojas de estilo y los
scripts.
En septiembre de 2001 se aprobó el estándar HTML 4.01.
Una etiqueta HTML consiste en un signo menor "<", un nombre de
una directiva (orden o comando para el navegador), seguido de los
parámetros o atributos y un signo mayor ">". Para cualquier
etiqueta que indica un el inicio de un elemento hay otra de cierre
que indica que esa directiva ya no debe actuar sobre el texto que
sigue (en algunas ocasiones no es necesario poner, o no existe, la
etiqueta de cierre correspondiente).
<directiva parámetro="xxxx"> ...</directiva>
HTML no es sensible a mayúsculas y minúsculas. Para HTML es
equivalente <HTML> y <html>, con algunas excepciones. Aunque
es recomendable es escribir los nombres de las etiquetas en
minúsculas ya que las nuevas generaciones del HTML están
basadas en SGML que requiere de documentos bien formados:
Nombres de etiquetas y atributos en minúsculas.
Etiquetas de cierre para elementos no vacíos.
40
Los valores de los atributos deben estar incluidos entre
comillas dobles.
Por otro lado, otro subconjunto de SGML es el lenguaje XML, pero,
es al igual que su padre un metalenguaje, del cual se pueden
derivar muchos otros, XML es utilizado generalmente para diseñar
y construir documentos, administrar y transferir información. Y es
de esta posibilidad de donde nació un híbrido que se esperara
fuera un nuevo estándar de internet.
De la unión de estos dos lenguajes, HTML y XML es de donde
nació un nuevo estándar, del cual el W3C lanzó la recomendación
en el año 2000, en un intento por regresar al HTML así motivo e
idea principal que era la representación semántica de la
información. El W3C buscó revertir lo que las empresas habían
estado haciendo al tratar de convertir al HTML visual.
Sin embargo el resultado nunca dejó de cuajar ni ser el estándar
esperado, y para el año 2002 el grupo de trabajo en el W3C
dedicado al desarrollo y búsqueda de mejoras en el XHTML dejó
de funcionar teniendo en puerta la recomendación de XHTML 2.0.
El desarrollo continuó, sin embargo este se volvió irrelevante.
También en 2007 se reintento abrir el grupo encargado de XHTML
2.0 sin embargo volvió cerrar a tan solo 2 años después de su
creación.
ESTRUCTURA DE UN DOCUMENTO HTML
Todas las páginas web tienen la siguiente estructura:
<html>
<head>
<title>Primerapágina</title>
</head>
<body>
</body>
</html>
En la primera línea encontramos la etiqueta <html>. Esta le indica
al cliente que comienza un documento HTML.
41
Luego viene <head>, la cabecera, donde se pone información
sobre el documento, que no se ve en la pantalla del navegador.
Aquí puede ir el título <title> del documento, es lo que veremos
como título de la ventana en los navegadores que lo permitan y
como se conocerá nuestra página en algunos buscadores y en la
lista de favoritos de los usuarios (es importante pensar bien el título
del documento).
Tras la cabecera viene <body>, el cuerpo, que es donde se coloca
la información que queremos mostrar en la pantalla principal del
navegador.
2.2.2.3. LOS NAVEGADORES WEB
Cuando un documento HTML es visto usando un software de
navegación web (como Internet Explorer, Mozilla Firefox o Safari)
asume el formato de estilo gráfico que se le intentó dar para su
visualización posterior por parte del usuario (en vez del formato de
etiquetas del documento de texto/html original).
La funcionalidad básica de un navegador web es permitir la
visualización de documentos de texto, posiblemente con recursos
multimedia incrustados. Los documentos pueden estar ubicados en la
computadora en donde está el usuario, pero también pueden estar en
cualquier otro dispositivo que esté conectado a la computadora del
usuario o a través de Internet, y que tenga los recursos necesarios
para la transmisión de los documentos (un software Servidor web).
Tales documentos, comúnmente denominados páginas web, poseen
hipervínculos que enlazan una porción de texto o una imagen a otro
documento, normalmente relacionado con el texto o la imagen.
42
Fig. 11. El Navegador Web Internet Explorer 8
El seguimiento de enlaces de una página a otra, ubicada en cualquier
computadora conectada a la Internet, se llama navegación; que es de
donde se origina el nombre de navegador.
2.2.2.2.4. HISTORIA
EL PRIMER NAVEGADOR9
Desarrollado en el CERN a finales de 1990 y principios de 1991 por
Tim Berners-Lee, era bastante sofisticado y gráfico, pero sólo
funcionaba en estaciones NeXT.
MOSAIC10
Creado por el Centro Nacional de Aplicaciones de
Supercomputación (Universidad de Illinois, EE.UU.) fue el primer
navegador que popularizó el uso de la web. Cuando se publicó la
primera versión, en 1993, el acceso a Internet todavía estaba
limitado a Universidades y organismos gubernamentales. Cuando
en 1994, el acceso a Internet se abrió a particulares, el jefe del
proyecto y otros miembros del equipo se salieron de la Universidad
para crear Netscape. A partir de ese momento, aunque se
publicaron nuevas versiones en 1995 y 1997, Mosaic dejó de ser
importante. En 1997 el desarrollo de Mosaic se dio por terminado.
9 NAVEGADORES WEB ,Disponible en: [http://es.wikipedia.org/wiki/Navegador_web]
10HISTORIA DE LA WEB: NAVEGADORES, disponible en:
[http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadores.html]
43
NETSCAPE
Apareció en 1994 y hasta 1997 fue el navegador más popular, por
varios motivos:
Aunque en algún momento intentó ser un programa
comercial, siempre existieron versiones gratuitas con toda la
funcionalidad
Se publicaban versiones nuevas continuamente que eran
capaces de representar elementos cada vez más complejos
Antes de 1994 las empresas de comunicación no podían
ofrecer acceso a Internet, pero en su lugar ofrecían acceso a
comunidades cerradas a los clientes (la más grande era
entonces AOL, America On Line). A partir de 1994, las leyes
permitieron el acceso de particulares, pero las empresas
seguían sin cambiar el chip: por ejemplo hasta 1996
Microsoft no incluyó en Windows un navegador web, aunque
sí ofrecía acceso a una red privada llamada Microsoft
Network. Netscape aprovechó para situarse como la puerta
de entrada al nuevo mundo de la web.
A partir de 1996, en que Windows incluyó un navegador (Internet
Explorer) en Windows 95 OSR2, la cuota de mercado de Netscape
empezó a caer inexorablemente. En 1998, Netscape se rindió y
antes de abandonar el mercado fundó la fundación sin ánimo de
lucro Mozilla, para crear un navegador de software libre. En 1999
Netscape fue comprada por AOL (reconvertida ya en proveedor de
Internet), que a su vez se fusionó con Time Warner en 2000.
Aunque se siguieron publicando versiones de Netscape hasta
2008, desde el año 2000 Netscape es irrelevante.
Desde 2008, el desarrollo de Netscape se dio por terminado.
INTERNET EXPLORER
Microsoft presentó Internet Explorer en agosto de 1995, basándose
en una versión de Mosaic. Internet Explorer 1 no estaba incluido en
Windows 95, pero ante el éxito de Netscape y la creciente
popularidad de la web, Microsoft pisó el acelerador:
44
Se publicaron versiones prácticamente cada año: IE 2
(noviembre de 1995), IE 3 (agosto de 1996), IE 4
(septiembre de 1997), IE 5 (marzo de 1999), IE 5.5 (julio de
2000) e IE 6 (agosto de 2001).
IE se incluyó en Windows a partir de Windows 95 OSR1
(febrero de 1996), lo que dio lugar a demandas por abuso de
posición dominante en Estados Unidos y Europa.
Cada versión incluía nuevas características avanzadas,
superando a Netscape en muchos aspectos.
A partir del año 2000, Internet Explorer dominó absolutamente el
mercado y Microsoft pisó el freno:
Las versiones se espaciaron: Internet Explorer 6 SP1
(septiembre de 2002), Internet Explorer 6 SP2 (agosto de
2004).
Las nuevas versiones no incluían prácticamente nuevas
características.
En 2003, Microsoft llegó a anunciar que sólo habría nuevas
versiones de Internet Explorer cuando hubiera nuevas
versiones de Windows.
A partir de 2005, ante la aparición de Firefox, Microsoft volvió a
pisar el acelerador, aunque su uso global ha ido bajando desde
entonces:
Se fueron publicando nuevas versiones a un ritmo cada vez
más rápido: IE 7 (octubre de 2006), IE 8 (marzo de 2009) e
IE 9 (marzo de 2011).
Las nuevas versiones volvieron a incluir características
avanzadas y, sobre todo, respeto a las recomendaciones del
W3C.
Tanto IE 7 como IE 8 estuvieron disponibles para Windows
XP, probablemente debido al fracaso de Windows Vista
como sustituto de Windows XP. Durante el primer año de IE
7, para instalarlo era necesario validar Windows, pero desde
entonces esa limitación no se ha vuelto a utilizar.
45
A partir de 2011, confirmado el éxito de Windows 7 como sustituto
de Windows XP, Microsoft volvió a vincular el navegador con el
sistema operativo e Internet Explorer 9 ya no se publicó para
Windows XP. Para Windows XP, Microsoft promueve el uso de IE 8
e incluso creó en marzo de 2011 la web
http://WWW.ie6countdown.com/ para promover la desaparición de
IE6.
El 26 de octubre del 2012 Microsoft ha publicado Internet Explorer
10, incluyéndolo en Windows Server 2012 y Windows 8.
Actualmente (noviembre 2012) el 13 de noviembre salió una
versión preliminar para Windows 7 SP1 pero no se sabe cuándo se
publicará la versión final.
OPERA
Es un navegador que comenzó en 1994 como proyecto de
investigación de Telenor, una compañía telefónica Noruega, pero
que desde 1995 desarrolla la compañía Opera Software. La
primera versión, Opera 2.1, se publicó en diciembre de 1996 y
desde entonces ha ido publicando versiones tanto para PCs como
para dispositivos móviles.
Su principal característica ha sido siempre el cumplimiento de las
recomendaciones del W3C (no en vano Håkon Wium Lie, uno de
los padres de las hojas de estilo, pertenece a esta compañía).
Hasta el año 2000 se trataba de un navegador de pago (con
versión de prueba temporal), pero desde entonces es gratuito.
Nunca ha tenido una gran cuota de mercado, salvo en dispositivos
móviles, donde siempre ha sido bastante utilizado (aunque la
competencia de Safari y Android están reduciendo esa
importancia).
MOZILLA
Mozilla era el apodo del navegador Netscape dentro de la misma
empresa Netscape. En enero de 1998 Netscape anunció que
46
liberaba el código fuente de su navegador y el proyecto de
continuar el desarrollo de ese código recibió el nombre de Mozilla.
Tras unos comienzos titubeantes en los que hubo que desechar
gran parte del código, a partir de 1999 se empezaron a publicar
numerosas versiones (el lema era "release early, release often", es
decir "publica pronto, publica a menudo") de la suite Mozilla, que
incluía tanto el navegador como el cliente de correo electrónico, un
programa de chat o un editor. Desde el primer momento, el objetivo
era implementar fielmente las recomendaciones del W3C. En junio
de 2002 se publicó por fin Mozilla 1.0.
Durante esos años, la financiación del proyecto provenía de AOL,
que utilizaba Mozilla como base para las versiones de Netscape
que siguieron publicándose durante unos años. Pero en mayo de
2003 AOL alcanzó un acuerdo con Microsoft para poner fin a las
demandas por abuso de posición dominante. Microsoft pagó a AOL
750 millones de dólares y, a cambio, AOL pasó a utilizar Internet
Explorer en vez de Netscape. AOL anunció entonces que dejaría
de financiar el desarrollo de Mozilla.
Para poder continuar el desarrollo de Mozilla, se creó en 2004 la
Mozilla Foundation, fundación sin ánimo de lucro, que recibe la
mayor parte de sus ingresos de Google.
De 2002 a 2004 todavía se siguieron publicando numerosas
versiones de Mozilla, pero se decidió separar (seguramente por
influencia de Google, entre otros factores) los componentes de
Mozilla y publicarlos como programas separados (el navegador
Firefox, el cliente de correo electrónico Firebird, etc.). Mozilla 1.7, la
última versión de Mozilla, se publicó en junio de 2004 y Firefox 1.0,
la primera versión de Firefox, se publicó en noviembre de 2004.
Posteriormente un grupo de programadores crearon SeaMonkey,
un programa que incluye navegador, cliente de correo, cliente de
chat, etc., como hacía Mozilla. SeaMonkey está basada en Firefox
y Thunderbird y el proyecto, aunque no forma parte de la
Fundación Mozilla, se aloja en sus Servidores.
Desde 2005, el desarrollo de Mozilla se dio por terminado.
47
FIREFOX
Firefox es el navegador creado por la Fundación Mozilla y es
continuación del navegador Mozilla, que a su vez es continuación
del navegador Netscape. Firefox 1.0 se publicó en noviembre de
2004 y su objetivo es permitir que la web sea pública, abierta y
accesible.
Además de cumplir las recomendaciones del W3C (no solamente
respecto al HTML y a CSS, sino también SVG o MathML), Firefox
pone el énfasis en la usabilidad (pestañas, interface, etc.),
facilitando además la personalización y ampliación a través de
extensiones.
Es el navegador que ha conseguido acabar con la dominación
absoluta de Internet Explorer y permitir que resurja la innovación en
la web. A partir de 2005, Firefox se convirtió en el navegador
alternativo a Internet Explorer y su uso creció hasta casi el 25% a
principios de 2009. Sin embargo la aparición de Google Chrome
por esas fechas detuvo su crecimiento y actualmente (noviembre
de 2011) se ha reducido a un 21%.
Entre 2005 y 2011 Firefox publicó nuevas versiones más o menos
una vez al año. A partir de Firefox 5 (junio de 2011), Firefox tomó
un modelo de desarrollo similar a Chrome y se publican nuevas
versiones cada 6 semanas, para hacer llegar rápidamente a los
usuarios las nuevas funcionalidades.
Este modelo de desarrollo rápido crea conflictos en los entornos
empresariales, en los que se utiliza una misma versión de los
programas durante mucho tiempo. La solución ofrecida ha sido
crear una versión ESR (Extended Support Release), que se
publicará cada siete versiones de Firefox (7x6 = 42 semanas). La
primera versión ESR fue Firefox 10 y las siguientes serán Firefox
17, Firefox 24, etc. El tiempo dirá si este plazo, inferior a un año, es
adecuado para los entornos empresariales.
Este modelo de desarrollo rápido también crea conflictos para los
creadores de extensiones, ya que los cambios internos de cada
versión pueden hacer que cualquier extensión deje de funcionar.
48
Este problema se agravaba en las primeras versiones porque
Firefox suponía que las extensiones eran incompatibles si no se
habían actualizado, pero a partir de Firefox 10, Firefox supone que
las extensiones son compatibles salvo que se indique lo contrario
en la web de extensiones.
El desarrollo de Firefox está financiado principalmente por Google,
a través de donaciones a la Fundación Mozilla. A cambio, la página
de inicio inicial de Firefox es la página web de Google. Cuando
Google comenzó a publicar en 2008 su propio navegador (Chrome)
surgieron dudas sobre la continuidad de esas donaciones, pero en
agosto de 2008 el acuerdo se renovó hasta noviembre de 2011 y
en diciembre de 2011 se renovó hasta noviembre de 2014.
SAFARI
Hasta 2003 el sistema operativo Mac de Apple no disponía de su
propio navegador web, sino que incluía Netscape o Internet
Explorer, pero en junio de 2003 Apple publicó Safari 1.0 para Mac
OS X. Safari utiliza el motor de renderizado WebKit, desarrollado
por Apple a partir del motor de renderizado KHTML del proyecto de
software libre KDE.
Desde 2003 Apple publica nuevas versiones de Safari cada año
(en los últimos años en el mes de junio). Aunque existen versiones
de Safari para Windows, su uso es irrelevante.
CHROME
Chrome es un navegador creado en 2008 por Google a partir de
WebKit, el motor de renderizado del navegador Safari. Tiene un
ritmo de desarrollo muy rápido, aunque no se publica a intervalos
regulares, como Firefox. La versión 1.0 se publicó en diciembre de
2008, actualmente (Noviembre de 2012) 6 de noviembre de 2012
ya va por la versión 23. Ha destacado siempre por su interfaz
minimalista y por la velocidad de ejecución del código JavaScript, lo
que obligó a Firefox y a Internet Explorer a mejorar estos aspectos.
49
Chrome ha vuelto a poner sobre la mesa el eterno debate entre la
superioridad de las aplicaciones locales y remotas. Gracias a
Chrome algunos ven técnicamente posible que el navegador se
convierta en la única aplicación del ordenador, con todos los datos
en Internet y las aplicaciones ejecutándose en HTML5 y JavaScript.
Otros recuerdan que más o menos esa fue ya la promesa de Java
hace 15 años, que no se cumplió. En cualquier caso, los próximos
años prometen ser apasionantes.
2.2.2.2.5. LA GUERRA DE LOS NAVEGADORES11
En 1994, la primera versión del navegador Netscape salió al
mercado, escrita por los inventores del navegador Mosaic. En
1996, se introdujo Netscape 2 con nuevas características: frames y
JavaScript.
Con Netscape 3 JavaScript 1.1 se volvió un estándar,
estandarizado por la ECMA (European Computer Manufacturers
Association) como ECMAScript.
En 1997 se estableció DHTML (Dynamic HTML) con la salida de
Netscape 4. Este incluía más etiquetas HTML y partes del estándar
de la W3C (World Wide Web Consortium) CSS 1 (Cascading Style
Sheets). En combinación con CSS 2 y JavaScript 1.2 se podía
modificar la posición, estilo y visibilidad de una página.
En 1997 apareció el concepto de layer (capa) introducido por el
navegador Microsoft Internet Explorer 4 que incluía muchas
características no estándar para competir con su rival Netscape
Navigator.
Los años posteriores las tecnologías citadas anteriormente se
convirtieron más avanzadas. Microsoft Internet Explorer fue incluido
directamente como parte del sistema operativo “Microsoft
Windows”, convirtiéndose de esta manera en el navegador más
utilizado.
11
FLORIAN MORITZ, Rich Internet Applications (RIA):A Convergence of User Interface Paradigms of Web and Desktop
Exemplified, 2008
50
Cada navegador, Netscape e Internet Explorer, utilizaban
tecnologías diferentes, las cuales no estaban estandarizadas e
implementaban incorrectamente los estándares establecidos. Esta
falta de estandarización hacía la programación para los
desarrolladores web difícil. El año 2000 con la salida de Opera 4
nace el primer navegador que cumple los estándares de la W3C.
En el año 2001 se libera Internet Explorer 6, pero su soporte CSS
era inferior comparado al Motor Gecko. El motor Gecko es un
motor de disposición para el manejo de HTML y CSS, el cual fue
publicado el 2002. Basado en este motor apareció un proyecto
Open Source denominado Mozilla. Más tarde el grupo Mozilla
produjo el navegador Mozilla Firefox con mucho éxito.
Otro navegador importante es Safari, desarrollado por Apple Inc.;
también el reciente Google Chrome lanzado el 2008 desarrollado
por Google. Cabe destacar que ambos navegadores utilizan el
motor de renderizado Webkit.
Microsoft detuvo el desarrollo de su navegador por años, hasta el
2006, año en el que libera Internet Explorer 7, esta versión
implementa mejoras en funcionalidad, estabilidad y compatibilidad
entre aplicaciones que usan CSS. El 2009 lanza Internet Explorer
8.
El 2009 también fue lanzada La versión 3.5 de Mozilla Firefox
(antes numerada como la versión 3.1). Es compatible con la
etiqueta <video> cómo define la especificación HTML 5; en el cual
incluye compatibilidad nativa con los códecs libres OggTheora y
OggVorbis. Esta versión incluye características que no pudieron ser
desarrolladas a tiempo para Firefox 3.
2.2.2.2.6. FUNCIONAMIENTO
La gran mayoría de los navegadores cuentan con un campo de
dirección donde el usuario escribe las direcciones web, que
vendrían a ser las Líneas de Petición en formato HTTP, al
presionar la tecla “Enter” activan el hiperenlace (que activa el
agente de usuario o navegador). La primera acción tomada por el
51
navegador es la resolución DNS del nombre de dominio a su
dirección IP equivalente. Una vez que la dirección ha sido resuelta
el navegador establece una conexión TCP a esta dirección y el
protocolo HTTP es usado para localizar y recuperar el archivo
HTML solicitado. Una vez recibido el navegador web muestra cada
uno de los elementos del documento HTML. A medida que el
usuario interactúa con los hiperenlaces del documento, un nuevo
proceso comienza nuevamente que involucra al DNS, TCP/IP y
HTTP12
La mayoría de los navegadores soportan otros protocolos
como FTP, Gopher y HTTPS (una versión cifrada de HTTP basada
en Secure Socket Layer o Capa de Conexión Segura (SSL)).
A pesar de que la función principal del navegador es descargar
documentos HTML y mostrarlos en pantalla, en la actualidad, no
solamente descargan este tipo de documentos sino que muestran
con el documento sus imágenes, sonidos e incluso
vídeos streaming en diferentes formatos y protocolos. Además,
permiten almacenar la información en el disco o
crear marcadores (bookmarks) de las páginas más visitadas.
Los primeros navegadores web sólo soportaban una versión muy
simple de HTML. El rápido desarrollo de los navegadores web
propietarios condujo al desarrollo de dialectos no estándares de
HTML y a problemas de interoperabilidad en la web. Los más
modernos (como Amaya, Mozilla, Netscape, Opera y versiones
recientes de Internet Explorer) soportan los estándares HTML
y XHTML (comenzando con HTML 4.01, los cuales deberían
visualizarse de la misma manera en todos ellos)13
Actualmente el navegador más utilizado en el mundo es Google
Chrome, seguido en esta clasificación por Internet Explorer y
Mozilla Firefox según los datos de Statcounter.
12
MARTIN P. CLARK. DATA NETWORKs, IP and the Internet: Protocols, Design and Operation. John Wiley& Sons, Ltd., 2003 :
479 13
NAVEGADORES WEB, Disponible en: [http://es.wikipedia.org/wiki/Navegador_web]
52
Fig. 12. Cuota de Navegadores Web.
Fuente: http://es.wikipedia.org/wiki/Mozilla_Firefox
2.2.2.4. APLICACIONES WEB
Se denomina aplicaciones web a aquellas aplicaciones que los
usuarios pueden utilizar accediendo a un Servidor web a través de
Internet o de una intranet mediante un navegador. En otras palabras,
son aplicaciones que se codifican en distintos lenguajes (Java, C#,
PHP, ColdFusion, etc.) y más tarde son compiladas o interpretadas
por el Servidor de aplicaciones que genera una salida HTML la cual
es mostrada por el navegador.
53
Fig. 13. Ejemplo de una aplicación web multicapa
Fuente: Martin P. Clark. Data Networks, IP and the Internet: Protocols, Design and
Operation. John Wiley& Sons, Ltd., 2003
2.2.3. TECNOLOGIAS DEL LADO DEL SERVIDOR
Las empresas no se habían dado cuenta aún sobre el qué hacer con
este nuevo “canal”. De hecho, al comienzo de la World Wide Web, las
páginas web corporativas frecuentemente mostraban solo información
de contacto y alguna documentación. Sin embargo, no paso mucho
tiempo para que los usuarios web desearan una experiencia mucho
más dinámica, en la cual el contenido de las páginas cambia de
acuerdo al tiempo, a las preferencias del usuario y miles de otros
atributos. El paso inmediatamente posterior en la evolución de las
aplicaciones web fue la inclusión de un método para elaborar páginas
dinámicas que permitieran que lo mostrado tuviese carácter dinámico
(es decir, generado a partir de los datos de la solicitud).
54
2.2.2.5. COMMON GATEWAY INTERFACE(CGI)14
Brindaba los mecanismos necesarios para generar contenido
dinámico ejecutando procesos (ejecutables) en los Servidores web
que generaban contenido HTML, el cual era devuelto al usuario;
funcionaba de la siguiente manera:
El navegador del usuario envía una solicitud como si fuera para
una página HTML.
El Servidor web reconoce que el recurso solicitado corresponde
a un programa externo.
El Servidor web ejecuta el programa externo, pasándole a este
la solicitud HTTP recibida del navegador del usuario.
El programa externo realiza el procesamiento y envía los
resultados (HTML) al Servidor.
El Servidor web envía la salida del programa externo hacia el
navegador como una respuesta HTTP.
CGI gozó de una popularidad enorme en los inicios de la Web
como medio de generación de contenido dinámico. Sin
embargo a medida que la Web crecía en popularidad, el tráfico
hacia los sitios web también crecía. Debido a muchas
deficiencias CGI no era suficiente para soportar esa carga.
Afortunadamente con el paso de los años surgieron muchas
alternativas de solución a CGI, que resolvían sus limitaciones.
En la actualidad aunque existen muchas variaciones posibles,
una aplicación web está normalmente estructurada como una
aplicación de tres-capas. En su forma más común, el
navegador web ofrece la primera capa; un motor capaz de usar
alguna tecnología web dinámica (ejemplo: PHP, Java Servlets
o ASP, ASP.NET, ColdFusion, Perl, Python o Ruby) constituye
la capa de intermedia. Por último, una base de datos constituye
la tercera y última capa.
14
JAYSON FALKNER, KEVIN JONEs, Servlets and Java Server Pages™: The J2EE™ Technology Web Tier. Addison Wesley,
2003
55
El navegador web manda peticiones a la capa de intermedia
que ofrece servicios valiéndose de consultas y actualizaciones
a la base de datos y a su vez proporciona una interfaz de
usuario.
2.2.2.6. SERVLET CONTAINERS, SERVLETS Y JSP 1.
2.2.2.2.7. SERVLETS CONTAINERS15
Es un Servidor web especializado que soporta la ejecución de
Servlets, combina la funcionalidad básica de un Servidor web con
un ambiente de ejecución Java y se encarga de gestionar el ciclo
de vida de cada Servlet que tiene registrado. Provee de un
ambiente de ejecución para todos los Servlets en el Servidor.
2.2.2.2.8. JAVA SERVLETS16 .
En el mundo Java, los Servlets fueron diseñados para resolver los
problemas de CGI y crear ambientes robustos del lado del Servidor
para los desarrolladores Web, basados en la plataforma Java. De
manera similar a CGI, los Servlets permiten que una solicitud sea
procesada por un programa y que este produzca una respuesta
dinámica. Adicionalmente definen un ciclo de vida eficiente que
maneja de manera óptima las solicitudes. Los Servlets sirven de
base para otras tecnologías Java como JSP (Java Server Pages).
Los Servlets no son aplicaciones, y tienen que ser cargados en
memoria por un ServletContainer. El ServletContainer funciona
como un Servidor web, recibiendo las solicitudes HTTP de los
navegadores web y enviándolas luego a los Servlets para generar
una respuesta, que generalmente es un documento HTML.
2.2.2.2.9. JSP.
Para ayudar a facilitar la creación de contenido dinámico, Sun
introdujo JSP (Java Server Pages). Una página JSP en realidad
cuando es procesada por un ServletContainer es convertida en un
15
DEFINICIÓN DE SERVLETCONTAINERS, Disponible en: [http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers] 16
JAYSON FALKNER, KEVIN JONES, Servlets and Java Server Pages™: The J2EE™ Technology Web Tier. Addison Wesley,
2003
56
Servlet que luego es ejecutado por este. Pero a diferencia de los
Servlets una página JSP puede contener código HTML a manera
de una página web tradicional y también elementos especiales JSP
que permiten insertar contenido dinámico en la página.
2.2.2.7. ASP NET17
Es un componente central de Microsoft .NET Framework18 y
proporciona la infraestructura para aplicaciones Web .NET
dinámicas desarrolladas fácilmente. ASP.NET no sólo sucede a
Microsoft Active Server Pages (ASP), es una plataforma de
desarrollo Web unificada que proporciona los servicios necesarios
a los desarrolladores para generar aplicaciones Web
empresariales. ASP.NET proporciona grandes mejoras con
respecto a ASP tradicional e incluye muchas características
nuevas.
ASP.NET está construido sobre el Common Language Runtime19,
permitiendo a los programadores escribir código ASP.NET usando
cualquier lenguaje admitido por el .NET Framework. ASP.NET
proporciona la habilidad de crear y utilizar controles UI
reutilizables que pueden encapsular una funcionalidad común y,
por tanto, reducir la cantidad de código que el desarrollador tiene
que escribir, la habilidad de los desarrolladores para estructurar
de forma clara las páginas en un estilo ordenado, y la habilidad de
las herramientas de desarrollo de proporcionar un potente soporte
de diseño WYSIWYG20 para las páginas.
17
DEFINICIÓN DE ASP.NET ,Disponible en: [http://support.microsoft.com/?scid=kb;es;305140] 18
NET FRAMEWORK :es el modelo de programación de código administrado de Microsoft para la creación de aplicaciones en
clientes de Windows, Servidores y dispositivos móviles o incrustados. Los desarrolladores pueden usar .NET para crear muchos
tipos de aplicaciones: aplicaciones web, de Servidor, de cliente inteligente, de consola, de bases de
datos.[http://msdn.microsoft.com/es-pe/netframework/default.aspx] 19
COMMON LANGUAGE RUNTIME :es un entorno en tiempo de ejecución que ejecuta el código y proporciona servicios que
facilitan el proceso de desarrollo [http://msdn.microsoft.com/es-pe/library/8bs2ecf4.aspx] 20
WYSIWYG. (What You See Is What You Get). Término utilizado para describir un sistema en el cual el contenido mostrado
durante la edición es muy similar al resultado final. [http://en.wikipedia.org/wiki/WYSIWYG]
57
2.2.2.8. PHP21
Es un lenguaje interpretado de propósito general ampliamente usado
y que está diseñado especialmente para desarrollo web y puede ser
incrustado dentro de código HTML. Generalmente se ejecuta en un
Servidor web, tomando el código en PHP como su entrada y creando
páginas web como salida.
El gran parecido que posee PHP con los lenguajes más comunes de
programación estructurada, como C y Perl, permiten a la mayoría de
los programadores crear aplicaciones web con una curva de
aprendizaje muy corta.
Cuando el cliente hace una petición al Servidor para que le envíe una
página web, el Servidor ejecuta el intérprete de PHP. Este procesa el
script solicitado que generará el contenido de manera dinámica (por
ejemplo obteniendo información de una base de datos). El resultado
es enviado por el intérprete al Servidor, quien a su vez se lo envía al
cliente.
2.2.2.9. COLDFUSION
Adobe Coldfusion es un Servidor de aplicaciones y un lenguaje de
programación usado para desarrollar aplicaciones de Internet,
generalmente sitios web generados dinámicamente. En este aspecto,
es un producto similar a ASP.NET, JSP o PHP.
Las partes dinámicas de una página ColdFusion son generadas
insertando elementos de marcado similares a HTML o XML en una
página web, estos elementos son conocidos como ColdFusion Markup
Language (CFML), el cual es el lenguaje con el que se desarrollan
aplicaciones web en ColdFusion.
CFML incluye una gran cantidad de etiquetas que se asemejan a
elementos encontrados en otros lenguajes de programación, así como
etiquetas para realizar tareas de acceso a base de datos, archivos,
correo, generación de PDF, etc.
21DEFINICIÓN DE PHP , disponible en: [http://es.wikipedia.org/wiki/PHP]
58
Coldfusion es una aplicación web Java, que se puede desplegar sobre
un contenedor de Servlets o un Servidor de Aplicaciones Java JEE,
también posee un Servidor JEE incorporado denominado JRun.
2.2.4. TECNOLOGIAS DEL LADO DEL CLIENTE22
Todo comenzó con una simple versión de HTML propuesta para crear
la estructura básica de páginas web, organizar su contenido y
compartir información. El lenguaje y la web misma nacieron
principalmente con la intención de comunicar información por medio
de texto.
El limitado objetivo de HTML motivó a varias compañías a desarrollar
nuevos lenguajes y programas para agregar características a la web
nunca antes implementadas. Estos desarrollos iniciales crecieron
hasta convertirse en populares y poderosos accesorios. Simples
juegos y bromas animadas pronto se transformaron en sofisticadas
aplicaciones, ofreciendo nuevas experiencias que cambiaron el
concepto de la web para siempre.
De las opciones propuestas, Java y Flash fueron las más exitosas;
ambas fueron masivamente adoptadas y ampliamente consideradas
como el futuro de Internet. Sin embargo, tan pronto como el número
de usuarios se incrementó e Internet pasó de ser una forma de
conectar amantes de los ordenadores a un campo estratégico para los
negocios y la interacción social, limitaciones presentes en estas dos
tecnologías probaron ser una sentencia de muerte.
El mayor inconveniente de Java y Flash puede describirse como una
falta de integración. Ambos fueron concebidos desde el principio
como complementos (plugins), algo que se inserta dentro de una
estructura pero que comparte con la misma solo espacio en la
pantalla. No existía comunicación e integración alguna entre
aplicaciones y documentos.
La falta de integración resultó ser crítica y preparó el camino para la
evolución de un lenguaje que comparte espacio en el documento con
HTML y no está afectado por las limitaciones de los plugins. 22
EL GRAN LIBRO DE HTML5. CSS3 Y JAVASCRIPT :Juan Diego Gauchat.
59
JavaScript, un lenguaje interpretado incluido en navegadores,
claramente era la manera de mejorar la experiencia de los usuarios y
proveer funcionalidad para la web. Sin embargo, después de algunos
años de intentos fallidos para promoverlo y algunos malos usos, el
mercado nunca lo adoptó plenamente y pronto su popularidad declinó.
Los detractores tenían buenas razones para oponerse a su adopción.
En ese momento, JavaScript no era capaz de remplazar la
funcionalidad de Flash o Java. A pesar de ser evidente que ambos
limitaban el alcance de las aplicaciones y aislaban el contenido web,
populares funciones como la reproducción de video se estaban
convirtiendo en una parte esencial de la web y solo eran
efectivamente ofrecidas a través de estas tecnologías.
A pesar del suceso inicial, el uso de Java comenzó a declinar. La
naturaleza compleja del lenguaje, su evolución lenta y la falta de
integración disminuyeron su importancia hasta el punto en el que hoy
día no es más usado en aplicaciones web de importancia. Sin Java, el
mercado volcó su atención a Flash. Pero el hecho de que Flash
comparte las mismas características básicas que su competidor en la
web lo hace también susceptible de correr el mismo destino.
Mientras esta competencia silenciosa se llevaba a cabo, el software
para acceder a la web continuaba evolucionando. Junto con nuevas
funciones y técnicas rápidas de acceso a la red, los navegadores
también mejoraron gradualmente sus intérpretes JavaScript. Más
potencia trajo más oportunidades y este lenguaje estaba listo para
aprovecharlas.
En cierto punto durante este proceso, se hizo evidente para algunos
desarrolladores que ni Java o Flash podrían proveer las herramientas
que ellos necesitaban para crear las aplicaciones demandadas por un
número creciente de usuarios. Estos desarrolladores, impulsados por
las mejoras otorgadas por los navegadores, comenzaron a aplicar
JavaScript en sus aplicaciones de un modo nunca visto. La innovación
y los increíbles resultados obtenidos llamaron la atención de más
programadores. Pronto lo que fue llamado la "Web 2.0" nació y la
percepción de JavaScript en la comunidad de programadores cambió
60
radicalmente.
JavaScript era claramente el lenguaje que permitía a los
desarrolladores innovar y hacer cosas que nadie había podido hacer
antes en la web. En los últimos años, programadores y diseñadores
web alrededor del mundo surgieron con los más increíbles trucos para
superar las limitaciones de esta tecnología y sus iniciales deficiencias
en portabilidad. Gracias a estas nuevas implementaciones,
JavaScript, HTML y CSS se convirtieron pronto en la más perfecta
combinación que pronto seria llamada HTM5, quien terminaría por
desplazar progresivamente a las soluciones basadas en plugins
existentes hasta ese momento como Applet Java, Adobe Flex y
Microsoft Silverlight.
2.2.4.1. APPLET JAVA23
En Java, un Applet24 es un programa que puede incrustarse en un
documento HTML, es decir en una página web. Cuando un navegador
carga una página web que contiene un Applet, este se descarga en el
navegador web y comienza a ejecutarse. Esto permite crear
programas que cualquier usuario puede ejecutar con tan solo cargar
la página web en su navegador.
El navegador que carga y ejecuta el Applet se conoce en términos
genéricos como el "contenedor" de los Applets. El kit de desarrollo de
software para Java Standard Edition 7 (1.7.1 --Versión más actual,
puesta en marcha el 18 de octubre de 2011) incluye un contenedor de
Applets, llamado appletviewer, para probar los Applets antes de
incrustarlos en una página web.
Los Applet java pueden hacer uso de diferentes tecnologías creadas
para el renderizado de interfaz gráfica como AWT, Swing y JavaFX.
Así como también las diferentes implementaciones de formatos de
socialización de datos para comunicación con el Servidor, como
Json, Json-RPC, Xml-Rpc, etc.
23
DEFINICIÓN DE APPLET JAVA, disponible en [http://es.wikipedia.org/wiki/Applet_Java] 24
DEFINICIÓN DE APPLET, disponible en [ http://es.wikipedia.org/wiki/Applet]
61
2.2.4.1.1. AWT25
La Abstract Window Toolkit (AWT, en español Kit de Herramientas
de Ventana Abstracta) es un kit de herramientas de gráficos,
interfaz de usuario, y sistema de ventanas independiente de la
plataforma original de Java. AWT es ahora parte de las Java
Foundation Classes (JFC) - la API estándar para suministrar una
interfaz gráfica de usuario (GUI) para un programa Java.
Cuando Sun Microsystems liberó Java en 1995, AWT suministró
solo un nivel de abstracción muy fino sobre la interfaz de usuario
nativa subyacente. Por ejemplo, crear una caja de verificación AWT
causaría que AWT directamente llame a la subrutina nativa
subyacente que cree una caja de verificación. Sin embargo, una
caja de verificación en Microsoft Windows no es exactamente lo
mismo que una caja de verificación en Mac OS o en los distintos
tipos de UNIX.
Algunos desarrolladores de aplicaciones prefieren este modelo
porque suministra un alto grado de fidelidad al kit de herramientas
nativo subyacente y mejor integración con las aplicaciones nativas.
En otras palabras, un programa GUI escrito usando AWT parece
como una aplicación nativa Microsoft Windows cuando se ejecuta
en Windows, pero el mismo programa parece una aplicación nativa
Apple Macintosh cuando se ejecuta en un Mac, etc. Sin embargo,
algunos desarrolladores de aplicaciones desprecian este modelo
porque prefieren que sus aplicaciones se vean exactamente igual
en todas las plataformas.
2.2.4.1.2. SWING26
Las Internet Foundation Classes (IFC) eran una biblioteca gráfica
para el lenguaje de programación Java desarrollada originalmente
por Netscape y que se publicó en 1996.
25
DEFINICIÓN DE AWT, Disponible en:[http://es.wikipedia.org/wiki/Abstract_Window_Toolkit] 26
DEFINICIÓN DE SWING, Disponible en:[ http://es.wikipedia.org/wiki/Swing_(biblioteca_gráfica])
62
Desde sus inicios el entorno Java ya contaba con una biblioteca de
componentes gráficos conocida como AWT. Esta biblioteca estaba
concebida como una API estandarizada que permitía utilizar los
componentes nativos de cada sistema operativo. Entonces una
aplicación Java corriendo en Microsoft Windows usaría el botón
estándar de Windows y una aplicación corriendo en UNIX usaría el
botón estándar de Motif. En la práctica esta tecnología no funcionó:
Al depender fuertemente de los componentes nativos del sistema
operativo el programador AWT estaba confinado al máximo
denominador común entre ellos. Es decir que sólo se disponen en
AWT de las funcionalidades comunes en todos los sistemas
operativos.
El comportamiento de los controles varía mucho de sistema a
sistema y se vuelve muy difícil construir aplicaciones portables. Fue
por esto que el eslogan de Java "Escríbalo una vez, ejecútelo en
todos lados" fue parodiado como "Escríbalo una vez, pruébelo en
todos lados".
En cambio, los componentes de IFC eran mostrados y controlados
directamente por código Java independiente de la plataforma. De
dichos componentes se dice con frecuencia que son componentes
ligeros, dado que no requieren reservar recursos nativos del
sistema de ventanas del sistema operativo. Además al estar
enteramente desarrollado en Java aumenta su portabilidad
asegurando un comportamiento idéntico en diferentes plataformas.
En 1997, Sun Microsystems y Netscape Communications
Corporation anunciaron su intención de combinar IFC con otras
tecnologías de las Java Foundation Classes. Además de los
componentes ligeros suministrados originalmente por la IFC, Swing
introdujo un mecanismo que permitía que el aspecto de cada
componente de una aplicación pudiese cambiar sin introducir
cambios sustanciales en el código de la aplicación. La introducción
de soporte ensamblable para el aspecto permitió a Swing emular la
apariencia de los componentes nativos manteniendo las ventajas
de la independencia de la plataforma. También contiene un
63
conjunto de herramientas que nos permiten crear una interfaz
atractiva para los usuarios.
2.2.4.1.3. JAVAFX
En 2005, Sun Microsystems adquirió la compañía SeeBeyond, en
la que un ingeniero de software de nombre de Chris Oliver creó un
lenguaje rico en gráficos de secuencias de comandos conocido
como F3 (Form Follows Function). F3 lenguaje que más tarde fue
presentado por Sun Microsystems como JavaFX en la conferencia
JavaOne 2007.
Posteriormente Oracle Corporation anunció la adquisición de Sun
Microsystems, con lo que Oracle se convirtió en el nuevo
administrador de JavaFX, la misma que volvió a crear esta
tecnología desde cero, basada en el lenguaje java eliminando de
esta manera el lenguaje de script JavaFX.
Con estos cambios JavaFX se convertiría en la próxima generación
de herramientas para el desarrollador y construcción de
aplicaciones multiplataforma con interfaces gráfica enriquecidas de
usuario (GUI),
Proporciona a través de gráficos acelerados por hardware y diseño
de interfaces de programación que permiten a los desarrolladores
combinar gráficos, animaciones, y los controles de interfaz de
usuario.
JavaFX 2.0 API puede ser utilizado por los diferentes lenguajes
que ejecutan en la máquina virtual Java (Visage, Jython, Groovy,
JRuby, y Scala).
2.2.4.2. AJAX27
AJAX es acrónimo de Asynchronous JavaScript and XML. El elemento
clave es su naturaleza asíncrona. En pocas palabras, AJAX es una
técnica para realizar llamadas asíncronas en segundo plano mediante
JavaScript y solicitar datos adicionales cuando sean necesarios,
27
BOGDAN BRINZAREA-IAMANDI, Cristian Darie, Audra Hendrix, AJAX and PHP Building Modern Web Applications, 2nd
Edition, Packt Publishing, 2009.
64
actualizando porciones de la página web sin provocar refrescos de
página.
AJAX permite la comunicación entre el cliente y el Servidor mientras
el usuario está utilizando la página web. Es necesario enfatizar que
AJAX es una técnica del lado del cliente, trabaja con cualquier
tecnología del lado del Servidor.
Junto con JavaScript, se necesita cierta familiaridad con otras
tecnologías como HTML, DOM y CSS. Estas tecnologías son
implementadas por todos los navegadores web de hoy en día, no se
requiere que el cliente instale componentes extras para visualizar un
sitio web AJAX.
JavaScript, el ingrediente esencial de AJAX, permite
implementar la funcionalidad del lado del cliente. En las
funciones JavaScript utilizamos el DOM (Document Object
Model) que nos permite manipular partes de la página HTML.
El objeto XMLHttpRequest, que permite realizar llamadas
asíncronas al Servidor en segundo plano mediante JavaScript.
A excepción de aplicaciones simples, se requiere de una
tecnología del lado del Servidor que recepcionen las solicitudes
del lado del cliente JavaScript.
El código del cliente JavaScript y el código del lado del Servidor
requieren de una manera de pasar datos y recibirlos respectivamente.
El objeto XMLHttpRequest permite enviar valores utilizando
solicitudes HTTP mediante métodos GET y POST. Por lo cual es muy
fácil interpretar estos datos con cualquier script del lado del Servidor.
El script del lado del Servidor envía una respuesta HTTP, está
respuesta estará en un formato que pueda ser interpretado por el
cliente JavaScript, el formato puede ser texto simple, pero en la
práctica, se requerirá de un formato de datos que pueda ser usado
para pasar datos estructurados. Los 2 formatos de datos más
populares utilizados en aplicaciones AJAX son XML y JSON
(JavaScript Object Notation).
65
INTERACCION AJAX DE EJEMPLO
Evento
XMLHttpRequest
function callback(){
//actualizar interfaz
}
Script de lado del
servidor
Aplicación Web AJAX
Cliente Servidor
1
2
3
45
Figura 14: Interacción en una aplicación AJAX.
Fuente: Nathaniel T. Schutta, Ryan Asleson, Pro AJAX and Java Frameworks, Apress,
2006.
1. Un evento JavaScript del lado del cliente dispara un evento
AJAX. Este puede ser disparado por cualquier otro elemento,
desde un evento hasta una acción específica del usuario. Con
un código como el siguiente:
<input type = “text” id=”email” name=”email” onblur=”validateEmail();”>
2. Una instancia del objeto XmlHttpRequest es creada. Usando el
método open, la llamada se configura. El URL con el método
HTTP correspondiente, típicamente GET o POST. La solicitud
es generada llamando al método send. De la siguiente manera:
var xmlHttp;
function validarEmail()
{
var email = document.getElementById("email");
var URL = "validar?email=" + escape(email.value);
if (window.ActiveXObject)
{
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
}
else if (window.XMLHttpRequest)
{
xmlHttp = new XMLHttpRequest();
}
xmlHttp.open("GET", URL);
xmlHttp.onreadystatechange = callback;
66
xmlHttp.send(null);
}
3. Se realiza una solicitud HTTP al Servidor. A cualquier script del
lado del Servidor.
4. El Servidor realiza cualquier tarea, generalmente de acceso a
datos. La respuesta es devuelta al navegador. El Content-Type
se establece a “text/xml” (El objeto XMLHttpRequest solo
puede procesar resultados del tipo “text/html”).
5. Cuando el Servidor devuelve la respuesta, el objeto
XMLHttpRequest invoca a una función de callback, que recibe
los datos devueltos y actualiza la interfaz del cliente.
Funtioncallback{
//actualizar interfaz
}
Como podemos ver, esto difiere del paradigma tradicional de
solicitud/respuesta. Típicamente estas llamadas se centralizan en una
librería que será utilizada por la aplicación web, o se utilizara una de
las tantas disponibles en la actualidad. En general estos frameworks
se encargan de las funcionalidades básicas e interacciones con el
navegador, otras agregan componentes JavaScript para la interfaz de
usuario.
2.2.4.3. ADOBEFLEX28
En su versión más reciente (Flex 4), es una plataforma de desarrollo y
despliegue de aplicaciones que se ejecutan sobre el Adobe Flash
Player para la Web y sobre Adobe AIR para el escritorio. A pesar de
que el Adobe Flash Player tiene ya varios años de existencia, la
mayoría de elementos desarrollados para este eran animaciones y
elementos visuales creados en su mayoría por diseñadores.
La plataforma de Adobe Flex permite a los desarrolladores ser
productivos construyendo aplicaciones para el Adobe Flash Player,
utilizando habilidades aprendidas en cualquier otro lenguaje de
programación. Desde su segunda versión (Adobe Flex 2) brinda un
28
FLASH BUILDER 4 AND FLEX 4 BIBLE ,David Gassne. Wiley Publishing, 2010.
67
ámbito de trabajo similar a herramientas existentes como Visual
Studio, Delphi, y JBuilder. El desarrollador escribe código (El lenguaje
utilizado es ActionScript 3) lo compila localmente y luego sube la
aplicación compilada al Servidor web para que puede ser utilizada por
el usuario.
2.2.2.4 Adobe Flash Player es un software de tiempo de ejecución
basado en navegadores y multiplataforma que ofrece una
visualización sin compromiso de aplicaciones expresivas, contenido y
vídeos en diferentes pantallas y exploradores. Flash Player 10.1 está
optimizado para un alto rendimiento en pantallas de dispositivos
móviles y está diseñado para aprovechar las funciones nativas del
dispositivo, permitiendo experiencias de usuario más profundas y
envolventes.
El resultado de compilar una aplicación Flex es un archivo SWF, que
al ser desplegado en un Servidor web, luego es descargado como
respuesta a una solicitud de un navegador web. El navegador
inicializa el Adobe Flash Player que ejecuta la aplicación del archivo
SWF.
Una de las principales ventajas del Adobe Flash Player es su gran
nivel de penetración en la Web. Cada nueva versión de este ha
alcanzado una tasa rápida de crecimiento de instalación con respecto
a versiones previas.
A junio del 2010, la tasa de penetración de las versiones 7, 8 y 9
fueron del 99%, y la versión 10 del Flash Player ya tiene una tasa de
penetración del 97.5% en navegadores a nivel mundial.
2.2.4.4.1. LENGUAJES
Las aplicaciones creadas con Adobe Flex tienen el mismo formato
que las animaciones producidas con las herramientas habituales
para crear contenido para el Adobe Flash Player (como Adobe
Flash CS5), pero el proceso para crear estas aplicaciones es muy
distinto.
Los lenguajes utilizados en la plataforma son:
68
ActionScript 3. La versión más reciente del lenguaje que
evolucionó a lo largo del ciclo de vida del Adobe Flash
Player hasta convertirse en un lenguaje de programación
completo, orientado a objetos.
MXML. Un lenguaje basado en XML que se utiliza para
definir una aplicación Flex y sus componentes. Muchos de
los elementos en MXML tienen sus clases equivalentes en
ActionScript 3 y forman parte de la librería de clases Flex.
FXG. Un lenguaje basado en XML que permite representar
objetos gráficos como marcado XML. Este lenguaje es
soportado por herramientas de Adobe como Illustrator,
Photoshop y Fireworks para permitir exportar objetos
gráficos hacia Adobe Flex.
Cuando una aplicación es compilada, el código MXML es
interpretado y se genera su correspondiente código en ActionScript
3, lo cual hace que sea más fácil definir partes de la aplicación en
MXML, que escribirlas completamente en ActionScript 3.
Se puede utilizar MXML y ActionScript de manera intercambiable
en muchas situaciones. MXML se usa comúnmente para definir la
disposición de los elementos visuales de la aplicación.
Por ejemplo para mostrar un elemento Label en pantalla:
<s:Label id=”miLabel” text=”Texto del Label” fontSize=”18”
fontWeight=”bold”/>
2.2.4.4.2. FLEX 4 SDK
O Flex 4 Standard Development Kit, es una librería de clases
implementada en ActionScript 3 que comprende la mayoría de
componentes visuales, animación, servicios de datos y otros que
forman parte del framework:
Controles de manejo de formularios.
Controles de menús.
Componentes de audio y video.
Contenedores de disposición de elementos visuales.
Componentes de datos.
69
Formateadores y validadores.
Manejo de cursor.
Manejo de estado.
Efectos.
Animación.
Manejo de historial.
Componentes de arrastrar y soltar.
Administración de estilos.
También incluye compiladores necesarios para construir
aplicaciones Flex. La descarga de los componentes mencionados
previamente y los compiladores es gratuita, los siguientes
componentes requieren de una licencia, la cual forma parte del IDE
llamado Adobe Flash Builder.
Componentes de visualización de datos y otros controles
visuales avanzados.
Herramientas de optimización de aplicaciones.
2.2.4.4.3. ADOBE FLASH BUILDER
Conocido previamente como Flex Builder, es un plugin basado en
Eclipse para el desarrollo de aplicaciones Flex. Eclipse es un IDE
(Integrated Development Environment) ampliamente utilizado, en
especial por desarrolladores Java. Aunque se pueden desarrollar
aplicaciones Flex sin necesidad de este IDE, Flash Builder facilita
enormemente tanto el diseño, depuración y despliegue de estas.
70
Herramientas de Desarrollo
Flex 4 SDK
(Gratuito)
Flash Builder 4
(Comercial)
Lenguajes
MXML y FXG
(Basados en XML)ActionScript 3
Entornos de ejecución
Flash Player
(Web)
AIR
(Escritorio)
ADOBE FLEX 4
Figura 15: Componentes de Adobe Flex 4
Fuente: David Gassner, Flash Builder 4 and Flex 4 Bible, Wiley Publishing, 2010.
2.2.4.4. MICROSOFT SILVERLIGHT29
Es una tecnología desarrollada por Microsoft para el desarrollo de
RIAs. Es una plataforma que está compuesta por un subconjunto de
la funcionalidad incluida en Windows Presentation Foundation (WPF)
y el .NET Framework. Al igual que el Adobe Flash Player, es un plugin
de navegador que permite la ejecución de contenido enriquecido en la
web.
Una aplicación RIA Silverlight, se ejecuta en el cliente, sobre el plugin
de Silverlight, el cual es ejecutado por el navegador, este ejecuta en el
cliente una versión específica del Common Language Runtime (CLR).
Un gran beneficio, ya que contiene una versión recortada de la Base
Class Library (BCL) de .NET, en total el plugin de Silverlight tiene un
tamaño de 5 MB.
29
SHANNON HORN, Microsoft Silverlight 3: A Beginner’s Guide, McGraw Hill, 2010.
71
2.2.4.4.4. FUNDAMENTOS
WINDOWS PRESENTATION FOUNDATION (WPF)
Es una versión rediseñada y mejorada de las tecnologías
.NET utilizadas para crear aplicaciones Windows, trabajar
con gráficos, crear animaciones e incrustar medios. Las
tecnologías Windows Forms (para ventanas y formularios
Windows) y GDI+ (para manipulación de gráficos) seguirán
siendo soportadas por Microsoft y pueden ser aún utilizadas,
pero carecen de muchas de las bondades disponibles en
WPF.
EXTENSIBLE APPLICATION MARKUP LANGUAGE
(XAML)
Es un lenguaje basado en XML creado para su utilización en
WPF. Su propósito principal es la definición de interfaces
gráficas y elementos visuales. Un archivo XAML es utilizado
para definir componentes visuales y su ubicación en la
aplicación. Un intérprete lee el archivo XAML y genera el
código administrado correspondiente para ser que estos
puedan ser instanciados.
SILVERLIGHT RUNTIME
Es el plugin propiamente dicho que se ejecuta en los
navegadores. Aparte de ser un subconjunto de WPF
también extiende y utiliza muchas de las funcionalidades de
ASP.NET AJAX. Al ser diseñada para el desarrollo de
aplicaciones RIA el plugin de Silverlight es multiplataforma y
funciona en distintos navegadores web.
En la actualidad, (Mayo 2012) el producto se encuentra en
su versión 5.1 Desde sus inicios las distintas versiones
fueron evolucionando de la siguiente manera:
La versión 1.0 fue lanzada en el 2007, e incluía las
siguientes funcionalidades:
- Gráficos y animación.
72
- Audio y video en formatos MP3 y Windows Media Video
(WMV).
- Imágenes en formato JPG y PNG.
- Utilización del Document Object Model (DOM) usando
JavaScript.
Silverlight 2 fue lanzado en septiembre del 2008, agregaba
las siguientes funcionalidades:
- Soporte de código administrado, en C#, Visual Basic,
IronPython e IronRuby.
- Controles de interfaz de usuario
- Acceso a datos mejorado.
Silverlight 3, lanzado en marzo del 2009, añadía las
siguientes funcionalidades:
- Soporte para validación de datos en los controles
visuales.
- Soporte nativo de hojas de estilo.
- Soporte de librerías de recursos externos.
- Soporte de modo desconectado.
- Se incluyeron muchos más controles visuales.
- Se mejoró el sistema de animaciones, agregando más
efectos visuales.
- Aceleración de gráficos por GPU.
2.2.4.4.5. HERRAMIENTAS
MICROSOFT VISUAL STUDIO 2010
A diferencia de versiones previas ofrece soporte completo
para desarrollar aplicaciones RIA Silverlight, incluyendo
todas las herramientas necesarias para el diseño de
contenido visual, la edición de código XAML, la depuración y
despliegue de aplicaciones Silverlight. Debido a que la 4ta
versión del producto (Silverlight 4) fue lanzada
posteriormente a Visual Studio 2010, Silverlight 4 se lanzó
también con Silverlight 4 Tools for Visual Studio 2010, la
73
cual actualiza Visual Studio para desarrollar aplicaciones
RIA Silverlight utilizando esta última versión.
MICROSOFT EXPRESSION STUDIO 4
Es un conjunto de herramientas graficas dirigidas a
diseñadores para la creación de contenido gráfico, audio y
video y el desarrollo de aplicaciones de escritorio y de
aplicaciones RIA basadas en Silverlight, está compuesto de
las siguientes aplicaciones:”
a) MICROSOFT EXPRESSION BLEND. Para la creación
de interfaces gráficas basadas en XAML, así como la
creación de animaciones y contenido interactivo.
b) MICROSOFT EXPRESSION DESIGN. Herramienta de
diseño gráfico.
c) MICROSOFT EXPRESSION MEDIA. Herramienta de
administración de medios de audio y video, edición,
conversión de formatos y su despliegue en aplicaciones
WPF.
2.2.4.5. HTML5
HTML5 (Hyper Text Markup Language, versión 5) es la quinta revisión
importante del lenguaje básico de la World Wide Web, HTML. HTML5
especifica dos variantes de sintaxis para HTML: un «clásico» HTML
(text/html), la variante conocida como HTML5 y una variante XHTML
conocida como sintaxis XHTML5 que deberá ser servida como XML
(XHTML) (application/xhtml+xml). Esta es la primera vez que HTML y
XHTML se han desarrollado en paralelo. HTML5 más que una
tecnología viene hacer un conjunto de especificación para el conjunto
de tecnologías HTML, JavaScript Y CSS. HTML5 propone estándares
para cada aspecto de la web y también un propósito claro para cada
una de las tecnologías involucradas. A partir de ahora, HTML provee
los elementos estructurales, CSS se encuentra concentrado en cómo
volver esa estructura utilizable y atractiva a la vista, y JavaScript tiene
todo el poder necesario para proveer dinamismo y construir
aplicaciones web completamente funcionales.
74
2.2.4.5.1. NUEVOS ELEMENTOS30
Estructura:
- section: Una parte o capítulo de un libro, sección de un
capítulo, o esencialmente cualquier cosa que tenga su
propio encabezado en HTML 4.
- header: El encabezado de la página; no es lo mismo que el
tag HEAD.
- footer: El pie de página, donde van las letras chicas,
copyright, emails, etc.
- nav: Una colección de links a otras páginas.
- article: Una entrada independiente en un blog, revista,
compendio o lo que sea.
Bloques semánticos:
- aside: Representa una nota, un consejo, un sidebar o lo que
sea que esté afuera del bloque narrativo.
- figure: Representa una imagen a nivel de bloque, junto con
su título.
- dialog: Un elemento diálogo representa una conversación
entre diferentes personas. El elemento „dt‟ señala al que
habla y „dd‟ señala el discurso.
Inlines semánticos:
- m (mark): Indica que el texto está “marcado” de alguna
manera pero no necesariamente enfatizado. Por ejemplo,
una página resaltada en un libro, o en google cache cuando
resalta los términos buscados. time: Bastante lógico,
representa una fecha. meter: Representa un valor numérico
en un rango especificado.
- progress: Representa el estado de un proceso en
ejecución, como las conocidas barras de progreso en las
ventanas de programas.
30
NUEVOS ELEMENTOS HTML5,Disponible en:[ http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-
lnxw01NewHTML]
75
Multimedia embebida:
- audio y video: Como sus nombres dicen, son para embeber
audio y video. La sintaxis es prácticamente la del viejo y
querido tag IMG.
Interactivos:
- details: Representa información adicional que podría no
mostrarse por defecto.
- datagrid: Sirve como control de “grillas”. Para árboles,
listados y tablas que pueden ser actualizados con scripts.
- menu y command: Menu existe desde la versión 2 de
HTML. Fue deprecado en la versión 4 pero retorna con
nuevo significado, conteniendo comandos que se van a
ejecutar al ser activados.
2.2.4.5.2. NUEVAS APIs JAVASSCRIPT31:
API para hacer Drag & Drop. Mediante eventos.
API para trabajar Off-Line. Permite descargar todos los
contenidos necesarios y trabajar en local.
API de Geoposicionamiento para dispositivos que lo
soporten.
API Storage. Facilidad de almacenamiento persistente en
local, con bases de datos (basadas en SQLite) o con
almacenamiento de objetos por aplicación o por dominio
Web (Local Storage y Global Storage). Se dispone de una
Base de datos con la posibilidad de hacer consultas SQL.
WebSockets. API de comunicación bidireccional entre
páginas. Similar a los Sockets de C.
WebWorkers. Hilos de ejecución en paralelo.
ESTÁNDAR FUTURO. SystemInformation API. Acceso al
hardware a bajo nivel: red, ficheros, CPU, memoria, puertos
31
DEFINICIÓN HTML5, Disponible en:[ http://es.wikipedia.org/wiki/HTML5]
76
USB, cámaras, micrófonos, etc. muy interesante pero con
numerosas salvedades de seguridad.
2.2.5. FREMEWORK
La palabra inglesa "framework" define, en términos generales, un
conjunto estandarizado de conceptos, prácticas y criterios para
enfocar un tipo de problemática particular que sirve como referencia,
para enfrentar y resolver nuevos problemas de índole similar.
En el desarrollo de software, un framework o infraestructura digital, es
una estructura conceptual y tecnológica de soporte definido,
normalmente con artefactos o módulos de software concretos, con
base a la cual otro proyecto de software puede ser más fácilmente
organizado y desarrollado. Típicamente, puede incluir soporte de
programas, bibliotecas, y un lenguaje interpretado, entre otras
herramientas, para así ayudar a desarrollar y unir los diferentes
componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones
generales de las entidades del dominio, y provee una estructura y una
especial metodología de trabajo, la cual extiende o utiliza las
aplicaciones del dominio.
2.2.6. PATRON DE DISEÑO32
Según Christopher Alexander, “cada patrón describe un problema que
ocurre una y otra vez en nuestro entorno, así como la solución a ese
problema, de tal modo que se pueda aplicar esta solución un millón de
veces, sin hacer lo mismo dos veces” .
Aunque Alexander se refería a patrones en ciudades y edificios, lo
que dice también es válido para patrones de diseño orientados a
objetos. Nuestras soluciones se expresan en términos de objetos e
interfaces, en vez de paredes y puertas, pero en la esencia de ambos
tipos de patrones se encuentra una solución a un problema dentro de
32
PATRONES DE DISEÑO (Elementos de software orientado a objetos reutilizables),Erich Gamma, Richard Helm, Ralph
Johnson, John Vlissides
77
un contexto.
En general, un patrón tiene cuatro elementos esenciales:
El nombre del patrón permite describir, en una o dos palabras,
un problema de diseño junto con sus soluciones y
consecuencias. Al dar nombre a un patrón inmediatamente
estamos incrementado nuestro vocabulario de diseño, lo que
nos permite diseñar con mayor abstracción. Tener un
vocabulario de patrones nos permite hablar de ellos con otros
colegas, mencionarlos en nuestra documentación y tenerlos
nosotros mismos en cuenta. De esta manera, resulta más fácil
pensar en nuestros diseños y transmitirlos a otros, junto con
sus ventajas e inconvenientes. Encontrar buenos nombres ha
sido una de las partes más difíciles al desarrollar nuestro
catálogo.
El problema describe cuándo aplicar el patrón. Explica el
problema y su contexto. Puede describir problemas concretos
de diseño (por ejemplo, cómo representar algoritmos como
objetos), así como las estructuras de clases u objetos que son
sintomáticas de un diseño inflexible. A veces el problema
incluye una serie de condiciones que deben darse para que
tenga sentido aplicar el patrón.
La solución describe los elementos que constituyen el diseño,
sus relaciones, responsabilidades y colaboraciones. La
solución no describe un diseño o una implementación en
concreto, sino que un patrón es más bien como una plantilla
que puede aplicarse en muchas situaciones diferentes. El
patrón proporciona una descripción abstracta de un problema
de diseño y cómo lo resuelve una disposición general de
elementos (en nuestro caso, clases y objetos).
Las consecuencias son los resultados así como las ventajas e
inconvenientes de aplicar el patrón. Aunque cuando se
describen decisiones de diseño muchas veces no se reflejan
sus consecuencias, éstas son fundamentales para evaluar las
78
alternativas de diseño y comprender los costes y beneficios de
aplicar el patrón. Las consecuencias en el software suelen
referirse al equilibrio entre espacio y tiempo. También pueden
tratar cuestiones de lenguaje e implementación. Por otro lado,
puesto que la reutilización suele ser uno de los factores de los
diseños orientados a objetos, las consecuencias de un patrón
incluyen su impacto sobre la flexibilidad, extensibilidad y
portabilidad de un sistema. Incluir estas consecuencias de un
modo explícito nos ayudará a comprenderlas y evaluarlas.
2.2.6.1. OBJETIVOS33
Proporcionar catálogos de elementos reusables en el diseño de
sistemas software.
Evitar la reiteración en la búsqueda de soluciones a problemas
ya conocidos y solucionados anteriormente.
Formalizar un vocabulario común entre diseñadores.
Estandarizar el modo en que se realiza el diseño.
Facilitar el aprendizaje de las nuevas generaciones de
diseñadores condensando conocimiento ya existente.
Asimismo, no pretenden:
Imponer ciertas alternativas de diseño frente a otras.
Eliminar la creatividad inherente al proceso de diseño.
No es obligatorio utilizar los patrones, solo es aconsejable en el
caso de tener el mismo problema o similar que soluciona el
patrón, siempre teniendo en cuenta que en un caso particular
puede no ser aplicable. "Abusar o forzar el uso de los patrones
puede ser un error".
33
OBJETIVOS DE PATRONES DE DISEÑO, Disponible en:[http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o]
79
2.2.6.2. CATEGORÍAS DE PATRONES34
Según la escala o nivel de abstracción:
Patrones de arquitectura: Aquellos que expresan un
esquema organizativo estructural fundamental para sistemas
de software.
Patrones de diseño: Aquellos que expresan esquemas para
definir estructuras de diseño (o sus relaciones) con las que
construir sistemas de software.
Dialectos: Patrones de bajo nivel específicos para un lenguaje
de programación o entorno concreto.
2.2.6.3. RELACIÓN DE PRINCIPALES PATRONES GOF (GANG OF
FOUR)35
2.2.6.3.1. Patrones creacionales:
1. Object Pool (no pertenece a los patrones especificados
por GoF): se obtienen objetos nuevos a través de la
clonación. Utilizado cuando el costo de crear una clase es
mayor que el de clonarla. Especialmente con objetos muy
complejos. Se especifica un tipo de objeto a crear y se utiliza
una interfaz del prototipo para crear un nuevo objeto por
clonación. El proceso de clonación se inicia instanciando un
tipo de objeto de la clase que queremos clonar.
2. Abstract Factory (fábrica abstracta): permite trabajar con
objetos de distintas familias de manera que las familias no
se mezclen entre sí y haciendo transparente el tipo de
familia concreta que se esté usando.
3. Builder (constructor virtual): abstrae el proceso de
creación de un objeto complejo, centralizando dicho proceso
en un único punto.
4. Factory Method (método de fabricación): centraliza en
una clase constructora la creación de objetos de un subtipo
34
CATEGORÍA DE PATRONES, Disponible en:[http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o] 35
RELACIÓN DE PRINCIPALES PATRONES DE DISEÑO, Disponible
en:[http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o]
80
de un tipo determinado, ocultando al usuario la casuística,
es decir, la diversidad de casos particulares que se pueden
prever, para elegir el subtipo que crear.
5. Prototype (prototipo): crea nuevos objetos clonándolos de
una instancia ya existente.
6. Singleton (instancia única): garantiza la existencia de una
única instancia para una clase y la creación de un
mecanismo de acceso global a dicha instancia.
2.2.6.3.2. Patrones estructurales:
1. Adapter (Adaptador): Adapta una interfaz para que pueda
ser utilizada por una clase que de otro modo no podría
utilizarla.
2. Bridge (Puente): Desacopla una abstracción de su
implementación.
3. Composite (Objeto compuesto): Permite tratar objetos
compuestos como si de uno simple se tratase.
4. Decorator (Envoltorio): Añade funcionalidad a una clase
dinámicamente.
5. Facade (Fachada): Provee de una interfaz unificada simple
para acceder a una interfaz o grupo de interfaces de un
subsistema.
6. Flyweight (Peso ligero): Reduce la redundancia cuando
gran cantidad de objetos poseen idéntica información.
7. Proxy: Mantiene un representante de un objeto.
8. Módulo: Agrupa varios elementos relacionados, como
clases, singletons, y métodos, utilizados globalmente, en
una entidad única.
2.2.6.3.3. Patrones de comportamiento
1. Chain of Responsibility (Cadena de responsabilidad):
Permite establecer la línea que deben llevar los mensajes
para que los objetos realicen la tarea indicada.
81
2. Command (Orden): Encapsula una operación en un objeto,
permitiendo ejecutar dicha operación sin necesidad de
conocer el contenido de la misma.
3. Interpreter (Intérprete): Dado un lenguaje, define una
gramática para dicho lenguaje, así como las herramientas
necesarias para interpretarlo.
4. Iterator (Iterador): Permite realizar recorridos sobre objetos
compuestos independientemente de la implementación de
estos.
5. Mediator (Mediador): Define un objeto que coordine la
comunicación entre objetos de distintas clases, pero que
funcionan como un conjunto.
6. Memento (Recuerdo): Permite volver a estados anteriores
del sistema.
7. Observer (Observador): Define una dependencia de uno-a-
muchos entre objetos, de forma que cuando un objeto
cambie de estado se notifique y actualicen automáticamente
todos los objetos que dependen de él.
8. State (Estado): Permite que un objeto modifique su
comportamiento cada vez que cambie su estado interno.
9. Strategy (Estrategia): Permite disponer de varios métodos
para resolver un problema y elegir cuál utilizar en tiempo de
ejecución.
10. Template Method (Método plantilla): Define en una
operación el esqueleto de un algoritmo, delegando en las
subclases algunos de sus pasos, esto permite que las
subclases redefinan ciertos pasos de un algoritmo sin
cambiar su estructura.
11. Visitor (Visitante): Permite definir nuevas operaciones
sobre una jerarquía de clases sin modificar las clases sobre
las que opera.
82
2.2.6.4. MODELO VISTA CONTROLADOR (MVC)36
Es un patrón o modelo de abstracción de desarrollo de software que
separa los datos de una aplicación, la interfaz de usuario, y la lógica
de negocio en tres componentes distintos. El patrón de llamada y
retorno MVC (según CMU), se ve frecuentemente en aplicaciones
web, donde la vista es la página HTML y el código que provee de
datos dinámicos a la página. El modelo es el Sistema de Gestión de
Base de Datos y la Lógica de negocio, y el controlador es el
responsable de recibir los eventos de entrada desde la vista.
Modelo: Esta es la representación específica de la información
con la cual el sistema opera. En resumen, el modelo se limita a
lo relativo de la vista y su controlador facilitando las
presentaciones visuales complejas. El sistema también puede
operar con más datos no relativos a la presentación, haciendo
uso integrado de otras lógicas de negocio y de datos afines con
el sistema modelado.
Vista: Este presenta el modelo en un formato adecuado para
interactuar, usualmente la interfaz de usuario.
Controlador: Este responde a eventos, usualmente acciones
del usuario, e invoca peticiones al modelo y, probablemente, a
la vista.
Muchos de los sistemas informáticos utilizan un Sistema de Gestión
de Base de Datos para gestionar los datos: en líneas generales del
MVC corresponde al modelo. La unión entre capa de presentación y
capa de negocio conocido en el patrón de la Programación por capas
representaría la integración entre Vista y su correspondiente
Controlador de eventos y acceso a datos, MVC no pretende
discriminar entre capa de negocio y capa de presentación pero si
pretende separar la capa visual gráfica de su correspondiente
programación y acceso a datos, algo que mejora el desarrollo y
mantenimiento de la Vista y el Controlador en paralelo, ya que ambos
cumplen ciclos de vida muy distintos entre sí.
36
DEFINICIÓN DE PATRÓN MODELO VISTA CONTROLADOR, Disponible
en:[http://es.wikipedia.org/wiki/Modelo_Vista_Controlador]
83
Aunque se pueden encontrar diferentes implementaciones de MVC, el
flujo que sigue el control generalmente es el siguiente:
El usuario interactúa con la interfaz de usuario de alguna forma
(por ejemplo, el usuario pulsa un botón, enlace, etc.)
El controlador recibe (por parte de los objetos de la interfaz-
vista) la notificación de la acción solicitada por el usuario. El
controlador gestiona el evento que llega, frecuentemente a
través de un gestor de eventos (handler) o callback.
El controlador accede al modelo, actualizándolo, posiblemente
modificándolo de forma adecuada a la acción solicitada por el
usuario (por ejemplo, el controlador actualiza el carro de la
compra del usuario). Los controladores complejos están a
menudo estructurados usando un patrón de comando que
encapsula las acciones y simplifica su extensión.
El controlador delega a los objetos de la vista la tarea de
desplegar la interfaz de usuario. La vista obtiene sus datos del
modelo para generar la interfaz apropiada para el usuario
donde se reflejan los cambios en el modelo (por ejemplo,
produce un listado del contenido del carro de la compra). El
modelo no debe tener conocimiento directo sobre la vista. Sin
embargo, se podría utilizar el patrón Observador para proveer
cierta indirección entre el modelo y la vista, permitiendo al
modelo notificar a los interesados de cualquier cambio. Un
objeto vista puede registrarse con el modelo y esperar a los
cambios, pero aun así el modelo en sí mismo sigue sin saber
nada de la vista. Este uso del patrón Observador no es posible
en las aplicaciones Web puesto que las clases de la vista están
desconectadas del modelo y del controlador. En general el
controlador no pasa objetos de dominio (el modelo) a la vista
aunque puede dar la orden a la vista para que se actualice.
Nota: En algunas implementaciones la vista no tiene acceso
directo al modelo, dejando que el controlador envíe los datos
del modelo a la vista. Por ejemplo en el MVC usado por Apple
84
en su framework Cocoa. Suele citarse como Modelo-Interface-
Control, una variación del MVC más puro
La interfaz de usuario espera nuevas interacciones del usuario,
comenzando el ciclo nuevamente.
2.2.6.5. MODELO VISTA PRESENTADOR (MVP)37
Este Patrón surge para ayudar a realizar pruebas automáticas de la
interfaz gráfica, para ello la idea es codificar la interfaz de usuario lo
más simple posible, teniendo el menor código posible, de forma que
no merezca la pena probarla. En su lugar, toda la lógica de la interfaz
de usuario, se hace en una clase separada (que se conoce como
Presentador), que no dependa en absoluto de los componentes de la
interfaz gráfica y que, por tanto, es más fácil de realizar pruebas. La
idea básica es que la clase Presentador haga de intermediario entre la
Vista (la interfaz gráfica de usuario) y el modelo de datos. La vista
tiene métodos en los que le pasan los datos que debe pintar ya
"mascados" (una lista de cadenas por ejemplo, en vez del modelo...).
Únicamente debe meter esos datos en los componentes gráficos
(cajas de texto, checkbox, etc.). También métodos get para obtener el
contenido de esos componentes. El Presentador hará de enlace entre
el modelo y la vista, y dotará de inteligencia a la vista. Como el
objetivo es poder probarlo fácilmente, el Presentador recibe las
interfaces que deben implementar el modelo y la vista, con los
métodos públicos a los que el Presentador debe llamar.
37
DEFINICIÓN DE MODELO VISTA PRESENTADOR, Disponible en:[http://WWW.imaginanet.com/blog/patron-mvp.html]
85
Figura 16: Flujo de Patrón Modelo Vista Presentador
Se puede decir que el patrón MVP es una mejora del patrón Modelo-
Vista-Controlador (MVC) basado en tres características:
La vista no conoce el modelo.
El presentador es independiente de la tecnología de interfaz de
usuario.
La vista y el presentador son testeables puesto que está
basada en un contrato.
2.2.6.5.1. MVP COMO CONTROLADOR SUPERVISADO38
Por un lado, podemos tener un presentador que no gestione la
forma en que la información es mostrada en la vista. Es la vista
quien define la lógica de cómo la información es formateada y
mostrada en la pantalla a partir de los controles que contiene. En
este caso, el presentador únicamente gestiona los casos más
complejos para facilitar el trabajo de la vista. Martin Fowler llama a
esta variación Controlador Supervisado.
38 MVP COMO CONTROLADOR SUPERVISADO, Disponible en: [http://theartoftheleftfoot.blogspot.com/2010/10/el-patron-
Gmodelo-vista-presentador-mvp.html]
86
Figura 17: Flujo de patrón Modelo Vista Presentador Supervisado
Cuando la vista recibe algún evento de ratón o teclado por parte del
usuario, delega el control del evento en el presentador. Este puede
realizar ciertas operaciones relacionadas con la vista como el
control del estado de los controles y después realizar la llamada a
algún comando en el modelo que realice la operación requerida por
el usuario. El modelo realiza las operaciones pudiendo realizar
cambios en su estado generando el evento correspondiente, el cual
es manejado por la vista para actualizar los controles de la pantalla.
Hay que tener en cuenta de que el hecho de que la vista pueda
hacer referencia al modelo nos da como resultado un diagrama
muy parecido al de MVC. Aunque este enfoque nos permita el uso
de técnicas de Data Binding. Con lo cual la cantidad de código que
la vista y presentador necesitan, se disminuye. Este enfoque nos
va a permitir el uso de técnicas de Data Binding sobre el modelo.
Por tanto, la cantidad de líneas de código fuente en la vista y el
presentador disminuyen. Si nos fijamos en el diagrama, este es
similar al de MVC por lo que hay que tener mucho cuidado en no
caer en un cambio de patrón.
87
2.2.6.5.2. MVP COMO VISTA PASIVA39
Por otro lado, podemos hacer que el presentador gestione
totalmente cómo la información se muestra en la vista. Es decir,
tenemos una vista "tonta", sin ningún tipo de lógica, cuya única
función es la de mostrar la información que se le pasa a través de
la interfaz de la vista. Martin Fowler llama a esta variación Vista
Pasiva.
Figura 18: Flujo de patrón modelo vista presentador con vista pasiva
En este caso, cuando un usuario realiza alguna operación sobre la
interfaz de usuario, la vista delega los eventos sobre el
presentador. Este realizará algún cambio sobre la vista para indicar
el cambio de estado y hará las llamadas a los comandos sobre el
modelo para llevar a cabo la operación requerida por el usuario.
Cuando el modelo provoque cambios en su estado, estos serán
recogidos por el presentador (al contrario que en el controlador
supervisado, que era la vista quien atendía a estos cambios de
estado en el modelo), el cual pedirá al modelo los cambios
realizados para luego actualizar la vista acorde a los cambios
recibidos.
39 MVP COMO VISTA PASIVA, Disponible en: [http://theartoftheleftfoot.blogspot.com/2010/10/el-patron-modelo-vista-
presentador-mvp.html]
88
2.2.6.6. JAVASCRIPT
JavaScript es un lenguaje de programación que se utiliza
principalmente para crear páginas web dinámicas.
Una página web dinámica es aquella que incorpora efectos como
texto que aparece y desaparece, animaciones, acciones que se
activan al pulsar botones y ventanas con mensajes de aviso al
usuario.
Técnicamente es un lenguaje de programación interpretado, por lo
que no es necesario compilar los programas para ejecutarlos. En
otras palabras, Es un lenguaje que se ejecuta en el ambiente de un
anfitrión. El navegador web es el ambiente más común pero no es el
único (los programas escritos con JavaScript se pueden probar
directamente en cualquier navegador sin necesidad de procesos
intermedios).
En un principio JavaScript comenzó con simples animaciones
introducidos en HTML, pero es usado ahora de modos mucho más
sofisticado. Los desarrolladores aprovechan la naturaleza orientada al
objeto del lenguaje para construir arquitecturas de código escalables
formadas por piezas reutilizables. JavaScript representa el tercer pilar
en el paradigma actual de las páginas Web que consiste en tres
partes claramente distinguibles: contenido (HTML), presentación
(CSS), y comportamiento (JavaScript).
2.2.8.6.1. ORIGENES40
Inicialmente, la Web fue concebida como una colección de
documentos HTML estáticos, unidos mediante hipervínculos. Pero
Con el crecimiento rápido de popularidad y tamaño de la Web, los
webmasters que estaban creando páginas web HTML estáticas
sentían que necesitaba algo más. Querían que la oportunidad para
la interacción del usuario sea más rica, principalmente impulsado
por el deseo de evitar consultas al Servidor para tareas simples,
tales como la validación de formularios. Se presentaron dos
40
JAVASCRIPT ORIENTADO A OBJETOs: Stoyan Stefanov
89
opciones para resolver dicho problema: Applets de Java (que no
llegaron a tener éxito) y LiveScript, que fue concebido por Netscape
en 1995 y más tarde incluido en el navegador Netscape 2.0, bajo el
nombre de JavaScript.
La capacidad de alterar de otro modo los elementos estáticos de
una página web fue muy bien recibida y otros exploradores
siguieron su ejemplo. Microsoft Internet Explorer (IE) 3.0 se incluye
con JScript, que era una copia del mismo lenguaje además de
algunas funciones específicas de IE. Con el tiempo se hizo un
esfuerzo para estandarizar las diversas implementaciones del
lenguaje y así es como ECMAScript (European Computer
Manufacturers Association) nació. Hoy tenemos el estándar,
llamado ECMA-262, y JavaScript es sólo una aplicación de esta
norma, aunque el más popular.
Para bien o para mal, la popularidad instantánea de JavaScript que
sucedió durante el período del Browser Wars I (aproximadamente
1996-2001). Eran los tiempos del boom de Internet inicial, cuando
los dos principales proveedores de navegador, Netscape y
Microsoft, estaban compitiendo por la cuota de mercado. Estos dos
vendedores estaban constantemente añadiendo características
para sus navegadores y sus versiones de JavaScript. Esta
situación, junto con la falta de un estándar trajo un montón de
malas opiniones sobre JavaScript. Muy a menudo, el desarrollo era
muy complicado: ya que una vez escrito el código para un
navegador, al probarlo en otro navegador simplemente no
funcionaba. Al mismo tiempo, los fabricantes de navegadores
añadían constantemente nuevas características a sus navegadores
obviando proporcionar herramientas adecuadas para el desarrollo,
generando con esto incompatibilidades molestas para los
desarrolladores web, pero esto fue sólo una parte del problema. La
otra parte del problema eran los mismos desarrolladores web, que
se añaden demasiadas características a sus páginas web. Los
desarrolladores estaban ansiosos por hacer uso de todas las
posibilidades que los nuevos navegadores para "mejorar" sus
90
páginas web con cosas como las animaciones en la barra de
estado, colores parpadeantes, textos parpadeantes, sacudiendo las
ventanas del navegador, copos de nieve y así sucesivamente. Este
abuso de JavaScript fue la otra razón por la que este lenguaje tuvo
mala reputación, haciendo que los programadores "reales" (los
desarrolladores con conocimientos de lenguajes más establecidos,
como Java o C / C + +) vieran a JavaScript nada más que como un
juguete para los diseñadores de front-end.
Causando en algunos proyectos, la prohibición de la programación
del lado del cliente en JavaScript y confiar sólo su Servidor
predecible y fiable.
2.2.8.6.2. EVOLUCION41
Una vez terminada la guerra de los navegadores se produjeron una
serie de procesos que reconfiguraron el panorama de desarrollo
web de una manera muy positiva.
Microsoft ganó la guerra y durante unos cinco años (que es un
periodo muy largo en el ámbito de Internet), dejaron de agregar
características a Internet Explorer y JScript. Este tiempo permitido
a otros navegadores, así como desarrolladores alcanzar e incluso
superar las capacidades de Internet Explorer. El movimiento por los
estándares web fue abrazado por los desarrolladores y
proveedores de navegadores por igual. Naturalmente a los
desarrolladores no les gustaba tener que implementar código para
cada navegador, por lo que la idea de tener estándares acordados
tuvo mucha aceptación.
Todavía estamos lejos de poder desarrollar de una manera
plenamente compatible con los estándares, pero lo ideal es
conseguir que esto suceda en el futuro.
Tanto desarrolladores como tecnologías fueron madurado y más
gente comenzó a preocuparse por cosas como la usabilidad,
técnicas progresivas de mejora y accesibilidad.
41
JAVASCRIPT ORIENTADO A OBJETOS: Stoyan Stefanov
91
En este entorno más saludable, los desarrolladores comenzaron a
descubrir nuevas y mejores formas de utilizar los instrumentos que
ya estaban disponibles. Después de la publicación de aplicaciones,
como Gmail y Google Maps, que eran ricos en la programación del
lado del cliente, se hizo evidente que JavaScript ya era una
tecnología madura, teniendo como uno de los mejores ejemplos de
su redescubrimiento la amplia adopción de la funcionalidad
proporcionada por el objeto XMLHttpRequest, que comenzó como
una innovación para Internet Explorer, pero luego se puso en
práctica por la mayoría de los navegadores.
XMLHttpRequest permite a JavaScript realizar peticiones HTTP y
obtener un nuevo contenido desde el Servidor a fin de actualizar
algunas partes de una página, sin una recarga de página completa.
Debido al amplio uso de XMLHttpRequest, una nueva generación
de aplicaciones web como de escritorio, llamada aplicaciones
AJAX, nació.
2.2.8.6.3. PRESENTE42
Una cosa interesante acerca de JavaScript es que siempre se
ejecuta en el ambiente de su anfitrión. El navegador es el anfitrión
más popular, pero no es el único. JavaScript puede ejecutar en el
Servidor, en el escritorio, las capacidades actuales de JavaScript
son:
Crear aplicaciones de internet enriquecidas y poderosas (el
tipo de aplicaciones que se ejecutan dentro del navegador
web, como Gmail)
Escribir el código de Servidor, tales como secuencias de
comandos ASP, el código que se ejecuta utilizando Rhino(un
motor de JavaScript escrito en Java)
Crear aplicaciones multimedia (Flash, Flex) con ActionScript,
que se basa en ECMAScript
42
JAVASCRIPT ORIENTADO A OBJETOS: Stoyan Stefanov
92
Escribir scripts que automatizan las tareas administrativas
en el escritorio de Windows, utilizando Windows Scripting
Host
Escribir extensiones / plugins para una gran cantidad de
aplicaciones de escritorio como Firefox, Dreamweaver, y
Fiddler
Crear aplicaciones web que almacenan la información en
una base de datos fuera de línea en el escritorio del usuario,
el uso de Google Gears.
Crear Yahoo! Widgets, widgets del Dashboard de Mac, o
aplicaciones de Adobe AIR que se ejecutan en el escritorio
2.2.8.6.4. ESPECIFICACIONES OFICIALES
ECMA ha publicado varios estándares relacionados con
ECMAScript. En Junio de 1997 se publicó la primera edición del
estándar ECMA-262. Un año después, en Junio de 1998 se
realizaron pequeñas modificaciones para adaptarlo al estándar
ISO/IEC-16262 y se creó la segunda edición. La tercera edición del
estándar ECMA-262 (publicada en Diciembre de 1999) es la
versión que utilizan los navegadores actuales y se puede consultar
gratuitamente en http://www.ecma-international.org/publications/
standards/Ecma-262.htm. Actualmente se encuentra en desarrollo
la cuarta versión de ECMA-262, que podría incluir novedades como
paquetes, namespaces, definición explícita de clases, etc. ECMA
también ha definido varios estándares relacionados con
ECMAScript, como el estándar ECMA-357, que define una
extensión conocida como E4X y que permite la integración de
JavaScript y XML.
93
2.2.8.6.5. CÓMO INCLUIR JAVASCRIPT EN DOCUMENTOS XHTML
La integración de JavaScript y XHTML es muy flexible, ya que
existen al menos tres formas para incluir código JavaScript en las
páginas web.
INCLUIR JAVASCRIPT EN EL MISMO DOCUMENTO XHTML
El código JavaScript se encierra entre etiquetas <script> y se
incluye en cualquier parte del documento. Aunque es correcto
incluir cualquier bloque de código en cualquier zona de la página,
se recomienda definir el código JavaScript dentro de la cabecera
del documento (dentro de la etiqueta <head>). Para que la página
XHTML resultante sea válida, es necesario añadir el atributo type a
la etiqueta <script>. Los valores que se incluyen en el atributo type
están estandarizados y para el caso de JavaScript, el valor correcto
es text/JavaScript. Este método se emplea cuando se define un
bloque pequeño de código o cuando se quieren incluir
instrucciones específicas en un determinado documento HTML que
completen las instrucciones y funciones que se incluyen por
defecto en todos los documentos del sitio web. El principal
inconveniente es que si se quiere hacer una modificación en el
bloque de código, es necesario modificar todas las páginas que
incluyen ese mismo bloque de código JavaScript.
DEFINIR JAVASCRIPT EN UN ARCHIVO EXTERNO
Las instrucciones JavaScript se pueden incluir en un archivo
externo de tipo JavaScript que los documentos XHTML enlazan
mediante la etiqueta <script>. Se pueden crear todos los archivos
JavaScript que sean necesarios y cada documento XHTML puede
enlazar tantos archivos JavaScript como necesite. Además del
atributo type, este método requiere definir el atributo src, que es el
que indica la URL correspondiente al archivo JavaScript que se
quiere enlazar. Cada etiqueta <script> solamente puede enlazar un
único archivo, pero en una misma página se pueden incluir tantas
etiquetas <script> como sean necesarias. Los archivos de tipo
94
JavaScript son documentos normales de texto con la extensión .js,
que se pueden crear con cualquier editor de texto como Notepad,
Wordpad, EmEditor, UltraEdit, Vi, etc. la principal ventaja de
enlazar un archivo JavaScript externo es que se simplifica el código
XHTML de la página, que se puede reutilizar el mismo código
JavaScript en todas las páginas del sitio web y que cualquier
modificación realizada en el archivo JavaScript se ve reflejada
inmediatamente en todas las páginas XHTML que lo enlazan.
2.2.8.6.6. COMO INCLUIR JAVASCRIPT EN DOCUMENTOS XHTML
INCLUIR JAVASCRIPT EN EL MISMO DOCUMENTO XHTML
El código JavaScript se encierra entre etiquetas <script> y se
incluye en cualquier parte del documento. Aunque es correcto
incluir cualquier bloque de código en cualquier zona de la página,
se recomienda definir el código JavaScript dentro de la cabecera
del documento (dentro de la etiqueta <head>)
INCLUIR JAVASCRIPT EN LOS ELEMENTOS XHTML43
Este método es el menos utilizado, ya que consiste en incluir trozos
de JavaScript dentro del código XHTML de la página por ejemplo:
<p onclick="alert('Un mensaje de prueba')">Un párrafo de
texto.</p> El mayor inconveniente de este método es que ensucia
innecesariamente el código XHTML de la página y complica el
mantenimiento del código JavaScript. En general, este método sólo
se utiliza para definir algunos eventos y en algunos otros casos
especiales, como se verá más adelante.
DEFINIR JAVASCRIPT EN UN ARCHIVO EXTERNO44
Las instrucciones JavaScript se pueden incluir en un archivo
externo de tipo JavaScript que los documentos XHTML enlazan
mediante la etiqueta <script>. Se pueden crear todos los archivos
43
INTRODUCCION A JAVASCRIP: Javier Eguíluz Pérez 44
INTRODUCCION A JAVASCRIP: Javier Eguíluz Pérez
95
JavaScript que sean necesarios y cada documento XHTML puede
enlazar tantos archivos JavaScript como necesite.
2.2.8.6.7. SINTAXIS
La sintaxis de un lenguaje de programación se define como el
conjunto de reglas que deben seguirse al escribir el código fuente
de los programas para considerarse como correctos para ese
lenguaje de programación. La sintaxis de JavaScript es muy similar
a la de otros lenguajes de programación como Java y C. Las
normas básicas que definen la sintaxis de JavaScript son las
siguientes:
No se tienen en cuenta los espacios en blanco y las nuevas
líneas: como sucede con XHTML, el intérprete de JavaScript
ignora cualquier espacio en blanco sobrante, por lo que el
código se puede ordenar de forma adecuada para
entenderlo mejor (tabulando las líneas, añadiendo espacios,
creando nuevas líneas, etc.) Se distinguen las mayúsculas y
minúsculas: al igual que sucede con la sintaxis de las
etiquetas y elementos XHTML. Sin embargo, si en una
página XHTML se utilizan indistintamente mayúsculas y
minúsculas, la página se visualiza correctamente, siendo el
único problema la no validación de la página. En cambio, si
en JavaScript se intercambian mayúsculas y minúsculas el
script no funciona.
No se define el tipo de las variables: al crear una variable, no
es necesario indicar el tipo de dato que almacenará. De esta
forma, una misma variable puede almacenar diferentes tipos
de datos durante la ejecución del script.
No es necesario terminar cada sentencia con el carácter de
punto y coma (;): en la mayoría de lenguajes de
programación, es obligatorio terminar cada sentencia con el
carácter “;”. Aunque JavaScript no obliga a hacerlo, es
conveniente seguir la tradición de terminar cada sentencia
con el carácter del punto y coma (;).
96
Se pueden incluir comentarios: los comentarios se utilizan
para añadir información en el código fuente del programa.
Aunque el contenido de los comentarios no se visualiza por
pantalla, sí se envía al navegador del usuario junto con el
resto del script, por lo que es necesario extremar las
precauciones sobre la información incluida en los
comentarios.
2.2.8.6.8. POSIBILIDADES Y LIMITACIONES45
Desde su aparición, JavaScript siempre fue utilizado de forma
masiva por la mayoría de sitios de Internet. La aparición de Flash
disminuyó su popularidad, ya que Flash permitía realizar algunas
acciones imposibles de llevar a cabo mediante JavaScript. Sin
embargo, la aparición de las aplicaciones AJAX programadas con
JavaScript le ha devuelto una popularidad sin igual dentro de los
lenguajes de programación web. En cuanto a las limitaciones,
JavaScript fue diseñado de forma que se ejecutara en un entorno
muy limitado que permitiera a los usuarios confiar en la ejecución
de los scripts. De esta forma, los scripts de JavaScript no pueden
comunicarse con recursos que no pertenezcan al mismo dominio
desde el que se descargó el script. Los scripts tampoco pueden
cerrar ventanas que no hayan abierto esos mismos scripts. Las
ventanas que se crean no pueden ser demasiado pequeñas ni
demasiado grandes ni colocarse fuera de la vista del usuario
(aunque los detalles concretos dependen de cada navegador).
Además, los scripts no pueden acceder a los archivos del
ordenador del usuario (ni en modo lectura ni en modo escritura) y
tampoco pueden leer o modificar las preferencias del navegador.
Por último, si la ejecución de un script dura demasiado tiempo (por
ejemplo por un error de programación) el navegador informa al
usuario de que un script está consumiendo demasiados recursos y
le da la posibilidad de detener su ejecución. A pesar de todo,
45
INTRODUCCIÓN A JAVASCRIPT: Javier Eguíluz Pérez
97
existen alternativas para poder saltarse algunas de las limitaciones
anteriores. La alternativa más utilizada y conocida consiste en
firmar digitalmente el script y solicitar al usuario el permiso para
realizar esas acciones.
2.2.8.6.9. PROGRAMACIÓN ORIENTADA A OBJETOS (OOP) CON
JAVASCRIPT
El lenguaje JavaScript está normalmente vinculado a la idea de
pequeños fragmentos de código que sirven para “enriquecer” las
páginas Web. Sin embargo, con las versiones que implementan
actualmente los navegadores, las tareas que pueden llevarse a
cabo empleando este lenguaje son de mucha mayor envergadura y
complejidad. Quizás una de las más interesantes estriba en la
posibilidad que tiene el programador de crear sus propios objetos,
a imagen y semejanza de otros objetos definidos por el estándar,
como son Date, Array, etc. Esto representa un avance considerable
a la hora de afrontar el desarrollo de sitios Web complejos (HTML,
DHTML, XML, XSL, etc.) y cambia por concepto la idea habitual de
que JavaScript es un lenguaje tan sencillo como limitado.
El lenguaje JavaScript se utiliza normalmente para crear pequeños
bloques de código dentro de las páginas web. Con ellos es posible
controlar los eventos originados por la interacción de los usuarios,
comprobar los formularios y en general, llevar a cabo todo un sinfín
de pequeñas tareas rutinarias y simples. Ahora bien, a medida que
las páginas se complican y ofrecen más posibilidades a los
usuarios, los scripts también crecen, en tamaño y complejidad. En
estos casos el código resultante suele ser bastante confuso,
ineficiente y poco reutilizable, debido principalmente a la falta de
conocimientos serios acerca de este lenguaje de programación, así
como al hecho de que normalmente no se le concede demasiada
importancia a este tipo de desarrollos. Sin embargo el lenguaje
JavaScript dispone de los recursos necesarios para trabajar con
orientación a objetos, que si no se ajusta por completo a la
metodología ortodoxa, sí permite al menos organizar el código
98
dando lugar a scripts más reducidos, eficientes y reutilizables.
Creación de objetos: el constructor, las propiedades y los métodos
El lenguaje JavaScript cuenta con varios objetos predefinidos. Por
ejemplo: window, document, form, etc. Todos ellos tienen una serie
de métodos y propiedades. De manera equivalente el programador
tiene la facultad de definir los objetos que considere necesarios. Un
objeto queda definido por su constructor. En JavaScript, éste no es
más que una función que se define de manera especial. El
siguiente fragmento de código muestra un ejemplo:
function MyDate(year, month, date)
{
this.year = year;
this.month = month;
this.date = date;
return this;
}
El objeto MyDate representa una fecha. Cuenta con tres
propiedades, year, month y date, que se corresponden
respectivamente con el año, el mes y el día de la fecha. La palabra
reservada this se emplea para hacer referencia al propio objeto.
2.2.8.6.10. LENGUAJES BASADOS EN CLASES vs BASADOS EN
PROTOTIPOS
Los lenguajes orientados a objetos basados en Clases, tales como
Java y C++, están fundamentados sobre los conceptos de clase e
instancia. Donde la clase establece la naturaleza compartida por un
grupo de objetos y las instancias son los objetos que comparten
dichos objetos.
Una clase define todas las propiedades (considerando los métodos
y los campos en Java, o miembros en C++, para considerarse
como propiedades) que caracterizan a un cierto conjunto de
objetos. Una clase es una cosa abstracta, más que cualquier
miembro particular de un conjunto de objetos que describe. Por
ejemplo, la clase Empleado podría representar el conjunto de todos
los empleados.
99
Una instancia, por otro lado, es la particularización de una clase (se
usa instanciación, por abuso de lenguaje); esto es, uno de sus
miembros. Por ejemplo, Victoria podría ser una instancia de la
clase Empleado, representando a un individuo particular como un
empleado. Una instancia tiene exactamente las propiedades de su
clase padre (no más, no menos)
Un lenguaje basado en prototipos, tal como JavaScript, no hace
esta distinción, simplemente tiene objetos, que son
simultáneamente clase e instancia: son clase con respecto de
aquellos objetos que se crean como instancias suyas y objetos en
si, tomados como instancias de una clase implícita, que se
establece con su creación, y se conoce como su prototipo. Un
lenguaje basado en prototipos tiene la noción de un objeto
prototipo, un objeto utilizado como una plantilla de la cual se
obtiene las propiedades iniciales para un nuevo objeto. Cualquier
objeto puede especificar sus propias propiedades, tanto al ser
creado como en tiempo de ejecución. Adicionalmente, cualquier
objeto puede estar asociado como el prototipo de cualquier otro
objeto, permitiendo que el segundo objeto comparta las
propiedades del primero. Y, el prototipo puede ser modificado
dinámicamente de modo que se afecten en cascada todos los
objetos que comparten tal prototipo.
DEFINIENDO UNA CLASE
En los lenguajes basados en clases, se define una clase en una
definición de clase separada. En esta definición puede especificar
métodos especiales, llamados constructores, para crear instancias
de una clase. Un método constructor puede especificar valores
iniciales para las propiedades de la instancia y desarrollando
procesamiento apropiado en tiempo de creación. Utilice el operador
new en asociación con el método constructor para crear instancias
de las clases.
JavaScript sigue un modelo similar, pero no tiene una definición de
clase por separado del constructor. En su lugar, define una función
100
constructora para crear objetos con un conjunto inicial particular de
propiedades y valores. Cualquier función JavaScript puede ser
utilizada como un constructor. Utilice el operador new con una
función constructora para crear un nuevo objeto.
SUBCLASES Y HERENCIA
Un lenguaje basado en clases, crea una jerarquía de clases por
medio de la definición de clases. En una definición de clases,
puede especificar que la nueva clase sea una subclase de una
clase ya existente. La subclase hereda todas las propiedades de la
superclase y adicionalmente puede añadir nuevas propiedades o
modificar las heredadas. Por ejemplo, asumiendo que la clase
Empleado incluye solamente las propiedades del nombre y
departamento y que Administrador es una subclase de Empleado
que añade la propiedad reporta. En este caso, una instancia de la
clase administrador puede tener tres propiedades: nombre,
departamento y reporta.
JavaScript implementa la herencia permitiendo asociar un objeto
prototipo con cualquier función constructora. Así que, puede crear
exactamente el ejemplo Empleado-Administrador, pero utiliza una
terminología ligeramente diferente. Primero defina la función
constructora de Empleado, especificando las propiedades del
nombre y departamento. Luego, defina una función constructora
Administrador, especificando la propiedad reporta. Finalmente,
asigne un nuevo objeto Empleado como el prototipo para la función
constructora Administrador. Luego, cuando cree un nuevo
Administrador, este hereda las propiedades de nombre y
departamento del objeto Empleado.
AÑADIENDO Y REMOVIENDO PROPIEDADES
En los lenguajes basados en clases, típicamente crea una clase en
tiempo de compilación y luego instancia la clase ya sea en tiempo
de compilación o en tiempo de ejecución. No puede cambiar el
número o tipo de las propiedades de una clase después de definir
101
la clase. En JavaScript, sin embargo, en tiempo de ejecución puede
añadir o eliminar propiedades de cualquier objeto. Si añade una
propiedad a un objeto que es utilizado como prototipo para un
conjunto de objetos, los objetos para los cuales este es el prototipo
también obtienen la nueva propiedad.
2.2.7. SCRUM46
Es un enfoque iterativo para el desarrollo de software estrechamente
alineado con los principios ágiles y el Manifiesto Ágil. Scrum se
compone de una serie de bloques de tiempo llamado sprints, que se
centran en la distribución de trabajo para el desarrollo de software. Un
sprint típico tiene una longitud de dos a cuatro semanas y se define
por un objetivo o contenido que ayuda a aclarar el objetivo del sprint.
Los sprints están aislados de cambios, permitiendo al equipo a
centrarse en la entrega de software de trabajo sin distracciones.
Scrum se enfoca en ayudar a la entrega del proyecto a las personas
comprometidas con el desarrollo del mismo.
Scrum, es un marco de trabajo para el desarrollo ágil de proyectos, en
principio surgido en la industria del software, pero de suficiente
sencillez y flexibilidad como para ser aplicado en contextos muy
diversos. Dentro de este marco, el proceso de desarrollo de un
proyecto se concibe como una sucesión de ciclos cortos de trabajo
denominados sprints, obteniendo de cada uno de ellos un producto
funcional que va completándose en forma iterativa.
Esta forma de concebir la gestión de proyectos es radicalmente
diferente al modo secuencial en que se afrontan tradicionalmente los
mismos, dividiéndolos en etapas, sucesivas y especializadas,
planificadas a priori en forma detallada; proponiendo en cambio un
desarrollo en forma iterativa, como trabajo de un equipo
multidisciplinario o crosfuncional (scrumteam) sobre una versión
completa del producto, centrada en el valor para el cliente o
destinatario.
Es así que uno de los roles clave definidos en Scrum es el 46
PRO AGILE .NET DEVELOPMENT WITH SCRUM , Jerrel Blankenship, Matthew Bussa, an Scott Millett.
102
denominado propietario del producto (product owner), que participa
activamente en el proceso de desarrollo, facilitando la comprensión
por parte del equipo de los aspectos prioritarios y centrales del
resultado esperado. Es quien representa al cliente, con una fuerte y
continua interacción con el equipo, facilita desde el inicio la clara
percepción de la visión del producto y de los aspectos que se
consideran de valor sustancial en el mismo. Al mismo tiempo que
provee retroalimentación continua al equipo sobre estos aspectos,
adquiere una comprensión de las posibilidades y dificultades a partir
de la comunicación con ellos.
Con el fin de guiar al equipo en los principios de trabajo implícitos en
un enfoque ágil de gestión, se define otro rol relevante: el scrum
master o facilitador, quien es responsable de orientar al equipo en la
aplicación de las prácticas adecuadas para lograrlos beneficios
esperados de esta modalidad de gestión, al mismo tiempo que se
encarga de remover impedimentos y reducir las fricciones que la
dinámica de trabajo pueda producir. Trabajar de esta forma exige en
etapas tempranas de un proyecto lograr una visión clara y enfocada
del objetivo a corto plazo, pues se apunta a obtener en un lapso de
tiempo reducido una versión “demostrable” del producto, aunque
restringida a sus características más importantes. Esto induce a
concentrarse en los aspectos de mayor relevancia. Se espera de cada
iteración o sprint, un entregable denominado “incremento” que es
considerado un producto potencialmente completo en su totalidad y
listo para su utilización. Esto promueve una gran transparencia
respecto a los problemas que se interponen en su desarrollo, así
como sobre las capacidades del equipo para lograrlo.
Este ciclo corto de trabajo también exige al equipo un alto grado de
interacción para concretar el objetivo, favoreciendo que surjan
tempranamente las dificultades o impedimentos que serán afrontados
diariamente a través de reuniones de seguimiento, breves y
enfocadas, tradicionalmente realizadas de pie (daily stand-up
meetings). Estas reuniones no sólo apuntan a realizar un control del
avance sino también a coordinar esfuerzos para superar obstáculos,
103
compartir estrategias y técnicas para afrontar situaciones y mejorar la
cohesión del equipo de trabajo.
Es así que cada sprint se desarrolla en tres fases: una reunión de
planificación, un período de trabajo a lo largo del cual se realizan las
reuniones diarias de seguimiento, y una reunión de revisión del
producto desarrollado en el sprint, denominado “incremento”, seguido
de una reunión de evaluación del proceso de trabajo con miras a
mejorarlo en forma continua, denominada “retrospectiva”. Un proyecto
completo entonces será visto como una sucesión de sprints a través
de los cuales se irá perfeccionando el producto objetivo hasta que el
product owner considere que se ha alcanzado el estado deseado. Este
enfoque iterativo de desarrollo permite una máxima flexibilidad a la
hora de especificar requisitos y recibir cambios en los mismos, al
mismo tiempo que produce en pocos ciclos de trabajo un equipo
cohesionado y sinérgico.
Este proceso se apoya a su vez en tres instrumentos que dan
visibilidad y soportan diferentes aspectos del mismo. Primero, una
lista de los requisitos o características del producto, también
conocidas como “historias de usuario”, porque representan el relato
desde el punto de vista del product owner, de lo que se necesita o
desea que el producto posea y proporcione como funcionalidad,
definiendo también el grado de prioridad entre ellas, denominada “Pila
del producto” (ProductBacklog). Segundo, una lista producida antes de
iniciar cada sprint, donde se define qué “historias de usuario” serán
satisfechas en ese ciclo de trabajo, así como las tareas necesarias
para lograrlo, denominada “Pila del sprint” (Sprint Backlog), que es
preparada por el equipo de trabajo con la colaboración del product
owner y finalmente contendrá la estimación del esfuerzo o tamaño de
cada tarea y la asignación del responsable. Tercero, a través del
desarrollo de un sprint, en base a cómo se irán completando las
tareas se construye lo que se denomina “gráfico de burndown”, una
herramienta que permite visualizar rápidamente la cantidad de trabajo
remanente y cómo se va concluyendo a través del tiempo, facilitando
la detección temprana de dificultades con el fin de actuar sobre ellas
104
en forma inmediata.
Resumiendo, Scrum se caracteriza por tres roles, tres reuniones y tres
artefactos:
Roles
o Propietario del Producto (product owner),
o Scrum Master o facilitador,
o Equipo (scrumteam).
Reuniones
o Planificación del Sprint (sprint planning),
o Seguimiento diario del Sprint (daily scrum),
o Revisión del Sprint y Retrospectiva (sprint review/
retrospective).
Artefactos
o Pila de producto (productbacklog),
o Pila de Sprint (sprint backlog),
o GraficoBurndown (burndown chart).
Figura 19: Flujo de trabajo entre elementos de Scrum
Fuente: Jerrel Blankenship, Matthew Bussa and Scott Millett, Pro Agile .NET
Development with Scrum
105
CAPITULO III
ESTUDIO DE
FRAMEWORKS PARA LA
IMPLEMENTACION DE
APLICACIONES WEB DEL
LADO DEL CLIENTE
BASADOS EN
JAVASCRIPT, CSS, HTML
106
3.1. DOJO TOOLKIT47
Dojo es un framework que contiene APIs y widgets (controles) para
facilitar el desarrollo de aplicaciones Web que utilicen tecnología AJAX.
Contiene un sistema de empaquetado inteligente, los efectos de UI, drag
and drop APIs, widget APIs, abstracción de eventos, almacenamiento de
APIs en el cliente, e interacción de APIs con AJAX.
Resuelve asuntos de usabilidad comunes como pueden ser la
navegación y detección del navegador, soportar cambios de URL en la
barra de URLs para luego regresar a ellas (bookmarking), y la habilidad
de degradar cuando AJAX/JavaScript no es completamente soportado
en el cliente. Es conocido como "la navaja suiza del ejército de las
bibliotecas JavaScript". Proporciona una gama más amplia de opciones
en una sola biblioteca JavaScript y es compatible con navegadores
antiguos.
3.1.1. ORIGEN Y DESARROLLO
Dojo Toolkit tiene su origen en 2004 con Alex Russell, quien inició un
proyecto para mejorar el desarrollo de DHTML. Para ello contactó con
otros programadores, de los cuales destacan David Schontzler y
Dylan Schiemann. Ellos, junto con Russell, son considerados los
fundadores de este framework. Sin embargo, no fueron los únicos:
una amplia comunidad de desarrolladores quisieron contribuir en el
proyecto, que concluyó en la formación de Dojo Foundation.
A día de hoy se han realizado ocho grandes actualizaciones en las
que han participado sesenta desarrolladores con más de un millón de
descargas.
Es de destacar que esta biblioteca es de código abierto y se puede
descargar de forma gratuita en su página oficial. La licencia nos
permite crear aplicaciones, utilizarlo en productos comerciales y
modificarlo. Cuenta con el patrocinio de IBM, Google, AOL y
Nexaweb.
Estas son algunas razones por las que esta caja de herramientas está
47
RESUMEN DE TECNOLOGÍA DOJO TOOLKIT, Disponible en: [http://es.wikipedia.org/wiki/Dojo_toolkit]
107
cubierta por una gran comunidad, con multitud de desarrolladores e
información que la hacen muy accesible y transparente de cara a
nuevos usuarios. De hecho, cualquier usuario puede navegar por el
chat IRC y conversar con contribuidores del proyecto e incluso
participar en reuniones oficiales para discutir temas estratégicos.
3.1.2. CARACTERÍSTICAS
3.1.2.1. COMPLEMENTOS
Los complementos de Dojo son componentes pre empaquetados de
código JavaScript, HTML y CSS que pueden ser usados para
enriquecer aplicaciones web.
Menús, pestañas y tooltips.
Tablas ordenables, gráficos dinámicos y dibujado de vectores
2D.
Efectos de animación y la posibilidad de crear animaciones
personalizables.
Soporte para arrastrar y soltar.
Formularios y rutinas de validación para los parámetros.
Calendario, selector de tiempo y reloj.
Editor online de texto enriquecido.
Núcleo de componentes (dijit) accesible desde versiones
anteriores y lector de pantalla.
3.1.2.2. COMUNICACIÓN ASÍNCRONA
Una característica importante de las aplicaciones AJAX es la
comunicación asíncrona entre el navegador y el Servidor.
Tradicionalmente, se realizaba con el comando JavaScript
XMLHttpRequest. Dojo provee de una capa de abstracción
(dojo.io.bind) para varios navegadores web con la que se pueden usar
otros transportes (como IFrames ocultos) y diferentes formatos de
datos. De esta forma podemos obtener los campos que se van a
enviar como parámetros del formulario de una manera sencilla.
108
3.1.2.3. SISTEMA DE PAQUETES
Dojo provee de un sistema de paquetes para facilitar el desarrollo
modular. El script de inicio inicializa una serie de jerarquías de
paquetes de espacios de nombre (io, event, etc.) bajo el paquete raíz
dojo. Después de la inicialización del paquete dojo, cualquier otro
paquete puede ser cargado (vía XMLHttpRequest o cualquier otro
transporte similar) usando las utilidades ofrecidas en el arranque.
También es posible inicializar paquetes adicionales dentro o al mismo
nivel que el paquete dojo, permitiendo extensiones o bibliotecas de
terceros.
Los paquetes de Dojo pueden contener múltiples archivos. Cualquier
paquete o archivo puede depender de otro. En este caso, cuando el
paquete es cargado, cualquier dependencia será también cargada.
Dojo también brinda una manera de crear perfiles; el sistema ofrece
una lista de paquetes y usa Apache Ant para crear un archivo
JavaScript comprimido que contiene dichos paquetes y dependencias.
De esta manera se tiene todo el código necesario para ser cargado y
es inicializado de una sola vez, permitiendo así el cacheado (la
mayoría de los navegadores web no permiten el cacheado de
archivos vía XMLHttpRequest).
3.1.2.4. ALMACENAMIENTO DE DATOS EN EL CLIENTE
Adicionalmente, ofrece funciones para leer y escribir cookies,
proporcionando en el lado cliente una abstracción llamada Dojo
Storage. Dojo Storage permite a la aplicación web almacenar datos en
el lado cliente, persistencia y seguridad. Cuando se incluye en una
página web, determina cual es el mejor método para almacenar la
información. Cuando la aplicación web ha sido cargada desde el
sistema de archivos (por ejemplo desde file://URL), Dojo Storage usa
de manera transparente XPCOM en Firefox y ActiveX en Internet
Explorer para mantener la persistencia de la información. El
desarrollador que use Dojo Storage no se tiene que preocupar de
esto, ya que Dojo tiene una capa de abstracción con métodos put() y
get().
109
3.1.2.5. ALMACENAMIENTO EN EL SERVIDOR
Desde enero de 2007, Dojo incluye las siguientes implementaciones
de almacenamiento de datos en el paquete dojo.data:
CsvStore: almacenamiento de sólo lectura y acceso CSV.
OpmlStore: almacenamiento de sólo lectura y lectura
jerárquica desde archivos en formato OPML.
YahooStore: almacenamiento de sólo lectura que obtiene los
resultados del servicio web del buscador de Yahoo Search!.
DeliciousStore: almacenamiento de sólo lectura que obtiene
los marcadores del servicio web que ofrece Del.icio.us.
RdfStore: almacenamiento de solo lectura que usa SPARQL
para comunicarse con el Servidor de datos RDF.
3.1.2.6. SOPORTE PARA ADOBE INTEGRATED RUNTIME (AIR)
Dojo permite usar aplicaciones Adobe AIR basadas en JavaScript. Ha
sido modificada para satisfacer los requisitos de seguridad de Adobe.
La consultora SitePen ha desarrollado una aplicación Adobe AIR
llamada Dojo Toolbox usando Dojo, en la que se incluye un API y un
sistema de construcción gráfico. Generalmente, el sistema de
construcción se ejecuta dentro de Rhino, pero esta aplicación AIR
puede ejecutarse desde el mismo AIR, sin el uso de Java.
3.1.3. ARQUITECTURA
Como caja de herramientas, la arquitectura de Dojo Toolkit consta de
una serie de componentes principales.
DOJO BASE.
Dojo Base es el kernel de Dojo: una biblioteca compacta y optimizada
que, entre otras muchas cosas, ofrece utilidades AJAX y un sistema
de paquetes y herramientas para crear y manipular jerarquías de
herencia. La Base se recoge en un único archivo llamado dojo.js.
Todas las funcionalidades de Base son accesibles a través de
funciones o atributos dojo.*.
DOJO CORE.
Dojo Core se construye sobre Dojo Base y ofrece soluciones más
110
avanzadas como son los efectos de animación, funcionalidades "drag
and drop" o el manejo de cookies. Cualquier recurso externo a dojo.js
que se tiene que importar de manera explícita es parte de Core. El
sistema de paquetes de Dojo utiliza mecanismos simples como los
#include de C o import de Java para acceder a sus servicios.
DIJIT.
Dijit (Dojo Widget) es una biblioteca de widgets para crear interfaces
gráficos. Está construida directamente sobre Dojo Core y en
ocasiones no requiere de código JavaScript para ser utilizada. Los
widgets son altamente portables y se pueden compartir fácilmente en
cualquier Servidor o incluso funcionar localmente sin Servidor web
mediante el protocolo file//.
DOJOX.
DojoX (Dojo Extensions) es una colección independiente de
subproyectos en estado de incubación que no encajan a la perfección
en Dojo Core o Dijit. Cada subproyecto suele incluir un archivo
readme con información sobre su estado. Se trata de la parte del
proyecto abierta a nuevas ideas. Su independencia permite que las
altas expectativas y la estabilidad del resto de componentes de Dojo
Toolkit no se vean comprometidas.
UTIL.
Util es una colección de utilidades que incluye una unidad de prueba y
herramientas para crear versiones personalizadas de Dojo. Estas
herramientas pueden disminuir el tamaño del código e incluir capas
con distintos archivos JavaScript. Esta disminución se consigue a
través de ShrinkSafe, un eficiente motor de compresión independiente
de Dojo.
3.2. EXTJS48
ExtJS es el framework de JavaScript que consta de varias Apis para el
desarrollo de aplicaciones web interactivas usando tecnologías como
AJAX, DHTML y DOM. Fue desarrollada por Sencha. Originalmente
48
EXTJS IN ACTION: Jesus Garcia.
111
construida como una extensión de la biblioteca YUI por Jack Slocum, en
la actualidad puede usarse como extensión para las bibliotecas YUI,
jQuery y Prototype. Desde la versión 1.1 puede ejecutarse como una
aplicación independiente.
El ExtJS no sólo proporciona widgets de interfaz de usuario sino que
también contiene una serie de otras características. Estas se dividen en
seis áreas principales:
core
UI components
comunicación remota
data services
drag and drop
general utilities
Figura 20: Arquitectura de Librerias de ExtJS in Action: Jesus Garcia
3.2.1. CORE
Está compuesta de muchas de las características básicas tales como
comunicación mediante Ajax, manipulación DOM, y gestión de
eventos. Todo lo demás es dependiente de este núcleo pero el
núcleo no depende de nada.
3.2.2. UI COMPONENTS49
Textfield._ Añade características al campo de entrada HTML
existente como validaciones básicas, un método de validación
49
EXTJS IN ACTION: Jesus Garcia.
112
personalizado, cambio de tamaño automático, y el filtrado de
teclado a través de expresiones regulares.
Textarea._ Extiende el TextField y es un campo de entrada de
varias líneas.
NumberField._ Este control hace casi el total de las
validaciones para los números enteros y flotantes.
ComboBox._ Es una combinación de un campo de texto de
entrada general y una casilla desplegable para darle una
combinación de campos de entrada flexible y altamente
configurable. El ComboBox tiene la capacidad de ejecución
automática de texto (conocido como de escritura anticipada) en
el área de introducción de texto, y junto con un almacén de
datos remoto, se puede trabajar con el Servidor para filtrar los
resultados. Si el cuadro combinado está realizando una
solicitud a distancia contra un gran conjunto de datos, puede
habilitar la paginación resultado estableciendo la propiedad
pageSize.
La Figura xxx ilustra la anatomía de una carga remota y
ComboBox con paginación.
Figura 21:Ejemplo de Renderizado de controles ExtJS
TimeField._ Es otro control que permite agregar fácilmente un
selector de tiempo a un formulario.
113
HTMLEditor._ Conocido en Extjs como WYSIWYG, o lo que
ves es lo que obtienes, editor. Este control permitir a los
usuarios introducir texto rico en formato HTML sin tener que
obligarnos a dominar HTML y CSS. permitiendo configurar los
botones de la Barra de herramientas para prevenir ciertas
interacciones por el usuario.
DateField._ Es un pequeño widget que permite al usuario
introducir un fecha a través de un campo de entrada o
seleccionarla de un DatePicker.
CheckBox._ Control de selección que puede ser agrupado en
un contenedor CheckboxGroup que proporciona un conjunto de
métodos de conveniencia, validaciones y la disposición para
organizar las casillas de verificación en las columnas.
RadioGroup._ Este control extiende la clase CheckboxGroup,
con la única diferencia que solo puede seleccionarse un radio a
la vez.
TabPanels._ También llamados pestañas sirven para dividir la
información por secciones o por categorías.
ToolBars._ Este control actúa como contenedor agrupando
múltiples controles en la parte superior de un formulario.
ExtJS Desktop ._Este control actúa como un escritorio virtual y
permite registrar múltiples iconos (lanzadores de aplicaciones),
en su interior mostrándolos de forma similar a la del escritorio
de Windows.
Layouts._ y maquetación._ Componente que permite organizar
nuestros controles de diferentes formas según el layout
elegido.
Sliders._ Control deslizante dotado de posibilidades como
múltiples punteros deslizantes y configuración a través de CSS.
Charts._ Desde la versión tres de la librería de Ext JS es la
posibilidad crear fácilmente gráficas de barras, lineares y de
pastel a partir de un Store.
ListBoxy TreeView._ Estos controles permiten la carga de
114
datos desde un Store,
GridPanel._ Grid que puede actuar en modo de solo lectura o
también en modo escritura permitiendo el desplazamiento y
ordenamiento de columnas
3.2.3. WEB REMOTING
Es un medio de JavaScript (a distancia) para realizar llamadas a
métodos que son definidos y expuestos en el Servidor, lo que se
conoce comúnmente como un procedimiento remoto o RPC. Es
conveniente para los entornos de desarrollo en los que desea exponer
los métodos del Servidor al cliente y evitar el trabajo adicional que
genera la gestión de métodos en Ajax.
3.2.4. DATA SERVICES
Esta sección se encarga de las necesidades de datos, que incluyen ir
a buscar, analizar y cargar la información en los stores (encargados
de alimentar de datos a las interfaces de usuario), mediante la lectura
de Array, XML y JSON (JavaScript Object Notation serializado).
3.2.5. DRAG AND DROP
Es un pequeño framework dentro ExtJS, que permite dotar a los
componentes ExtJs o a cualquier elemento HTML de la posibilidad de
arrastrar y soltar. Este framework incluye todo lo necesario para
gestionar el proceso de arrastrar y soltar.
3.2.6. GENERAL UTILITIES
La sección de utilidades comprende clases interesantes, utilidades
que ayudan con las tareas rutinarias. Por ejemplo Ext.util.Format,
permite dar formato transformar datos con facilidad. Otra utilidad
interesante es el singleton CSS, que permite crear, actualizar, cambiar
y eliminar hojas de estilo, así como solicitar el navegador para
Actualizar su caché.
115
3.3. YUI (INTERFAZ DE USUARIO YAHOO)
YUI es una biblioteca JavaScript de código abierto para la construcción
de aplicaciones web ricas en interactividad, la misma que hace uso de
técnicas tales como Ajax, DHTML y DOM scripting.
La página de Yahoo! fue la primera en usar YUI en el verano de 2005.
YUI fue lanzado para el uso público en febrero de 2006. Su activo
desarrollo por parte del equipo de ingenieros de Yahoo! permitió que en
septiembre de 2009, Yahoo! lanzara YUI 3, una nueva versión
reconstruida desde cero con el objetivo de modernizar la biblioteca e
incorporar las lecciones aprendidas de YUI 2. Entre las mejoras
incorporadas están un selector de CSS accionado por un motor para la
recuperación de elementos DOM, un mayor énfasis en la granularidad
de módulos, un archivo base más pequeño que carga otros módulos
cuando sea necesario, y una variedad de modificaciones sintácticas
destinados a hacer que la escritura de código sea más rápida y fácil.
Esta biblioteca se divide en seis componentes que su vez se
descompone en componentes individuales que pueden ser utilizados
según sea necesario sin tener que incluir toda la biblioteca en un
proyecto. Todos los componentes tienen una dependencia en el objeto
YAHOO Global que establece algunas bases necesarias. Después de
eso, la mayoría de los componentes también necesitan la colección
DOM y la Utilidad de eventos. Cada componente se presenta en una
versión miniaturizada, una versión estándar, y una versión de
depuración, esta última registra todos los tipos de información que
permite el funcionamiento interno de los componentes a ser depurados.
3.3.1. NÚCLEO50
El núcleo de YUI es un ligero conjunto de herramientas (31KB la
versión compacta) para manejar eventos y manipular el árbol DOM.
YAHOO Global Object: Los Objetos Globales Yahoo
contienen utilidades y otras infraestructuras base para la
biblioteca.
DomCollection: Ayuda para la manipulación del árbol DOM,
50
RESUMEN DE YAHOO UI LIBRARY, Disponible en: [http://es.wikipedia.org/wiki/Yahoo!_UI_Library]
116
incluyendo posicionamiento de elementos y gestión de estilos
CSS.
EventUtility: Permite acceder de forma segura y sencilla a los
eventos de un navegador web y, mediante el objeto
CustomEvent, publicar y suscribirse a eventos customizados.
3.3.2. UTILIDADES51
Animation: Ayuda a crear efectos animados.
Browser History Manager: Ayuda complementaria para el
botón Atrás y la gestión de Marcadores/Favoritos de los
navegadores web.
Connection Manager: Ayuda para manejar el objeto
XMLHttpRequest.
Cookie: Permite gestionar las cookies.
DataSource: Proporciona una interfaz común para que otros
componentes puedan interactuar con diferentes tipos de datos.
Drag and Drop: Facilita la creación de eventos y elementos
que pueden ser arrastrados.
Element: Proporciona una capa para los elementos que facilita
el añadido de escuchadores, manipulación del árbol DOM y
atributos 'get' y 'set'.
Get: La utilidad Get soporta la carga asíncrona de datos y
archivos de estilos CSS externos.
ImageLoader: Permite aplazar la carga de imágenes que no
son visibles durante la carga de la página, proporcionando un
aumento del rendimiento.
JSON: Proporciona métodos para el tratamiento de datos
JSON. Estos métodos están basados en el trabajo de Douglas
Crockford.
Resize: Permite redimensionar los elementos HTML.
Selector: Permite referenciar elementos HTML mediante la
sintaxis CSS3.
51
UTILIDADES DE YAHOO UI LIBRARY, Disponible en: [http://es.wikipedia.org/wiki/Yahoo!_UI_Library]
117
YUI Loader: Es un cargador del lado cliente que permite la
carga de forma dinámica de cualquier componente y
dependencia de la biblioteca al vuelo.
3.3.3. CONTROLES / WIDGETS
AutoComplete: Proporciona la función de auto completado
(lista de sugeridos) para los usuarios. Soporta varios formatos
de datos, tanto del lado cliente como del lado Servidor (vía
XMLHttpRequest).
Button: Permite la creación de botones gráficos que funcionan
como un botón tradicional en HTML.
Calendar: Un calendario gráfico y de control dinámico.
Charts: Permite la creación de diferentes tipos de gráficos
(lineales, de barras, etc.).
Color Picker: Proporciona una interfaz gráfica para la
selección de colores.
Container: Proporciona una interfaz gráfica como Tooltip,
paneles, cuadros de diálogo, etc.
DataTable: Una potente herramienta para mostrar tablas
tabulares en una página web. Permite la ordenación de
columnas tanto en el lado cliente como en el Servidor,
paginación, scroll, selección de filas, redimensionado de
columnas y edición inline.
ImageCropper: Proporciona una interfaz gráfica para recortar
una imagen desde el lado cliente.
Layout Manager.
Menu: Proporciona una API para la creación de menús
flotantes, barras de menú y menús de contexto.
Rich Text Editor: Es un sofisticado editor de texto rico modular
del lado cliente y muy configurable.
Slider: Proporciona un elemento genérico que permite al
usuario elegir entre un rango de valores.
TabView: Permite la navegación entre pestañas, soportando la
118
carga dinámica de contenido vía XMLHttpRequest.
TreeView: Añade un árbol de contenido con nodos que se
pueden contraer y expandir para navegar por los elementos.
Uploader: Permite la carga de varios archivos mostrando una
barra de progreso.
3.3.4. CSS HERRAMIENTAS52
Aunque YUI es ante todo un marco de JavaScript, también
proporciona recursos CSS. El apoyo de YUI a CSS se remonta a
versiones muy tempranas de YUI 2, ahora en su nueva versión
incluyen:
YUI CSS Reset, que anula fuera de estilos por defecto del
navegador.
YUI CSS Base, que junto con YUI Cambiar CSS, establece
que todos los navegadores tienen una línea de base común ver
y sentir.
YUI CSS Fonts, lo que proporciona un conjunto coherente de
tamaños de fuente en todos los navegadores.
YUI Grids CSS, que le permite crear rápidamente diseños
sofisticados que utilizan un mínimo CSS.
Aunque se desarrolló junto a la API de JavaScript YUI 3, las
hojas de estilo de ninguna manera están atadas a YUI JS 3.
Esta biblioteca trabaja muy bien con YUI 2, con otras
bibliotecas JavaScript o sin JavaScript en absoluto.
3.3.5. HERRAMIENTAS DE DESARROLLO
Logger: Permite escribir mensajes de log en una consola, o
utilizar las que proporcionan la extensión Firebug para el
navegador Mozilla Firefox o la consola JavaScript del
navegador Safari.
Profiler: Para perfilar el código JavaScript.
ProfilerViewer: Usado con el anterior componente (Profiler)
52
YUI3 COOKBOOK: Evan Goer
119
proporciona un perfilado visual.
YUI Test: Permite añadir unidades de testeo al código
JavaScript.
3.3.6. HERRAMIENTAS DE CONTRUCCIÓN
YUI Compressor Es un compresor de código JavaScript y
CSS diseñado para proporcionar un resultado 100% seguro.
120
CAPITULO IV
IMPLEMENTACION DE
FRAMEWORK MODELO
VISTA PRESENTADOR
PARA APLICACIONES WEB
DEL LADO DEL CLIENTE
BASADOS EN
JAVASCRIPT, CSS, HTML
121
4.1. DESCRIPCION DEL PROBLEMA
Actualmente existe un conjunto de Framework como EXTJS, YUI, DOJO
TOOLKIT que están basado en HTML, JavaScript y CSS que nos
permiten la implementación y desarrollo de aplicaciones web del lado del
cliente, Estos Framework constan de un conjunto de librerías que
facilitan el desarrollo de aplicaciones Web, permitiendo resolver asuntos
de usabilidad comunes como pueden ser la navegación y detección del
navegador, soportar cambios de URL en la barra de URLs para luego
regresar a ellas (bookmarking).
Cuentan con un número considerable widgets o controles de usuario que
nos permiten interactuar con el usuario de manera similar a las
aplicaciones de escritorio, Así como también de Frameworks necesarios
para poder implementar el patrón modelo vista controlador.
Actualmente estos Framework que si bien es cierto facilitan la
implementación de aplicaciones web del lado del cliente, a la hora de
utilizarlos muestran deficiencias en algunos aspectos como son:
Definición de Interface de Usuario._ El problema principal en
la definición de interfaces de usuario es el uso del lenguaje
JavaScript el cual no fue diseñado para definir Interfaces de
usuario sino más bien para poder interactuar con las mismas.
Actualización de datos en los Patrones de Diseño._ Esta
deficiencia obliga al programador a definir controladores
encargados de sincronizar los datos de las diferentes capas.
Debido a estas deficiencias es necesario desarrollar un Framework que
permita la implementación de un patrón de diseño mucho más simple
como es el patrón Modelo Vista Presentador, así como también un motor
generador de interfaz gráfica de usuario en base a descriptores XML.
4.2. RESUMEN DEL PROYECTO
Este proyecto se encarga de la implementación de un Framework
Modelo Vista Presentador como controlador supervisado basado en las
librerías del Framework ExtJS la misma que fue elegida por estar entre
los Framework más utilizados, de mayor simplicidad en su uso y por
disponer de un número considerable de controles de usuario.
122
Entre las características principales que tendrá este Framework:
Definición de interfaz de usuario mediante documentos XML
(Extensible Markup Language).
Sincronización de la vista y el presentador a través de
descriptores en el Documento XML que define la interfaz de
usuario.
Sincronización del modelo y la vista en función a descriptores
definidos en un documento XML.
4.3. BENEFICIOS
Mejorar la reutilización de código e interfaces.
Mejorar la mantenibilidad de los proyectos.
Reducir el tiempo de desarrollo de aplicación web del lado del
cliente.
Poseer un Framework que nos permita la implementación del
patrón modelo vista presentador.
Delegar el diseño de interfaces de usuario a especialistas en el
área sin necesidad de que estos tengan conocimiento de
lenguajes de programación.
4.4. DESCRIPCIÓN DE LA METODOLOGÍA DE TRABAJO
4.4.1. INTRODUCCIÓN
Este documento describe la implementación de la metodología de
trabajo Scrum en el desarrollo de la tesis para obtener el Título
Profesional de Ingeniero Informático y de Sistemas de los Bachilleres
Jorge Francisco Castro Alvarez y Luis Rafael Callapiña Cosio para la
gestión de la implementación del proyecto RAFMVP.
Incluye junto con la descripción de este ciclo de vida iterativo e
incremental para el proyecto, los artefactos o documentos con los que
se gestionan las tareas de adquisición y suministro: requisitos,
monitorización y seguimiento del avance, así como las
responsabilidades y compromisos de los participantes en el proyecto.
123
4.4.1.1. PROPÓSITO DE ESTE DOCUMENTO
Facilitar la información de referencia necesaria a las personas
implicadas en la implementación y calificación del Framework
RAFMVP.
4.4.1.2. ALCANCE
Personas y procedimientos implicados en la implementación y
calificación del Framework RAFMVP.
4.4.2. DESCRIPCIÓN GENERAL DE LA METODOLOGÍA
4.4.2.1. FUNDAMENTACIÓN
Las principales razones del uso de un ciclo de desarrollo iterativo e
incremental de tipo Scrum para la ejecución de este proyecto son:
Sistema modular. Las características del sistema [Nombre del
sistema] permiten desarrollar una base funcional mínima y
sobre ella ir incrementando las funcionalidades o modificando
el comportamiento o apariencia de las ya implementadas.
Entregas frecuentes y continuas al cliente de los módulos
terminados, de forma que puede disponer de una funcionalidad
básica en un tiempo mínimo y a partir de ahí un incremento y
mejora continua del sistema.
Previsible inestabilidad de requisitos.
Es posible que el sistema incorpore más funcionalidades de las
inicialmente identificadas.
Es posible que durante la ejecución del proyecto se altere el
orden en el que se desean recibir los módulos o historias de
usuario terminadas.
Para el cliente resulta difícil precisar cuál será la dimensión
completa del sistema, y su crecimiento puede continuarse en el
tiempo suspenderse o detenerse.
124
4.4.2.2. VALORES DE TRABAJO
Los valores que deben ser practicados por todos los miembros
involucrados en el desarrollo y que hacen posible que la metodología
Scrum tenga éxito son:
Autonomía del equipo
Respeto en el equipo
Responsabilidad y auto-disciplina
Foco en la tarea
Información transparencia y visibilidad.
4.4.3. PERSONAS Y ROLES DEL PROYECTO.
Tabla Nº 6
Persona Contacto Rol
Luis Rafael Callapiña Cosio [email protected] Scrum Master
Jorge Francisco Castro Alvarez [email protected] Dueño de producto
Jorge Francisco Castro Alvarez [email protected] Equipo
Luis Rafael Callapiña Cosio [email protected] Equipo
Fuente: Elaboración propia
4.4.4. ARTEFACTOS
Documentos
Pila de producto o Product Backlog
Pila de sprint o Sprint Backlog
Sprint
Incremento
Gráficas para registro y seguimiento del avance.
Gráfica de producto o Burn Up
Gráfica de avance o Burn Down.
Comunicación y reporting directo.
Reunión de inicio de sprint
Reunión técnica diaria
Reunión de cierre de sprint y entrega del incremento
125
4.4.2.3. PILA DE PRODUCTO
Es el equivalente a los requisitos del sistema o del usuario en esta
metodología.
Se trata de una lista que contiene elementos denominados historias
de usuario, las cuales son descripciones genéricas de los
requerimientos con estimaciones a groso modo sobre la importancia
de la historia y el esfuerzo que costará desarrollarlas.
La pila de producto es elaborada por el dueño de producto (gestor de
producto) con la ayuda del Scrum Master (facilitador). El resultado de
este trabajo es la pila siguiente:
Tablas Nº 7
ID Nombre Cómo probarlo Importancia Estimación
1 Crear los componentes básicos adecuados para el modelo MVP.
Deben existir componentes Modelo, Vista y Presentador
10 13
2 Desarrollar las clases para el componente Presentador
Al modificar el valor de una variable enlazable en el Presentador, este cambio debe reflejarse en el Modelo o la Vista, según con quien sea enlazado esta variable.
9 5
3 Desarrollar las clases para el componente Vista
Al modificar el valor de una variable mediante la Vista, esta debe ser reflejada en el Modelo y en el Presentador.
8 8
4 Desarrollar las clases para el componente Modelo
El Modelo debe ser capaz de enlazarse al Presentador mediante descriptores en un documento XML y debe ser capaz de invocar servicios del lado del Servidor (RPC
9 8
126
o REST)
5 Procesador de XML que renderiza vistas en HTML y JavaScript
Definir una vista en XML y verla en HTML y JavaScript en el navegador.
7 5
6 Mecanismo para invocar eventos y métodos desde los documentos XML
Definir eventos y métodos en el Presentador y enlazarlos en las definiciones XML de las vistas y que estas funcionen.
5 8
7 Mecanismo de reutilización de componentes existentes
Embeber (anidar) vistas ya creadas con XML dentro de otras y que se rendericen sin problema en el navegador.
5 8
8 Mecanismo de Binding entre propiedades y vistas.
Al modificar el valor de una propiedad en el Presentador, esta se debe de modificarse en la Vista y viceversa.
7 21
9 Mecanismo de Binding entre métodos y eventos de las vistas.
Al invocar los eventos de la vista, estos deben invocar a métodos definidos dentro del Presentador.
7 21
10 Mecanismos de invocación de servicios del lado del cliente.
Se deben de obtener datos desde servicios REST desde el lado del Servidor.
9 34
11 Crear mecanismos de asistencia a desarrolladores (plugins)
El plugin debe estar disponible para algún IDE de desarrollo web.
7 21
Fuente: Elaboración propia
4.4.2.4. PILA DEL SPRINT
Es el documento de registro de los requisitos detallados o tareas que
va a desarrollar el equipo técnico en la iteración (actual o que está
preparándose para comenzar).
127
Los responsables de este trabajo son el dueño de producto, que
absuelve dudas respecto de las historias a ser desarrolladas, el
equipo de desarrolladores, que se divide las tareas, colocan
estimaciones más exactas y otras, y el Scrum master que dirige la
reunión.
4.4.2.5. SPRINT
Cada una de las iteraciones del ciclo de vida iterativo Scrum. La
duración de cada sprint en la mayoría de casos es fija para todas,
pero esto no es una regla fija. Se puede acordar la duración de estos
según las tareas que se estén asignadas a este periodo de trabajo.
Para el control del proyecto se usó un sistema de control de proyectos
ágiles llamado PangoScrum y mostramos la lista de los sprints que se
desarrollaron y las fechas en las que se desarrollaron:
Figura 22: Pila de definición de Sprints
4.4.2.6. INCREMENTO
Parte o subsistema que se produce en un sprint y se entrega al gestor
del producto completamente terminado y operativo.
128
4.4.2.7. Gráfica de avance (Burn Down)
Gráfico que muestra el estado de avance del trabajo del sprint en
curso. El dueño del producto no tiene responsabilidades específicas
en este artefacto, salvo el de estar informado de este. El Scrum
master mantiene actualizado este gráfico con los datos obtenidos de
las reuniones diarias con el equipo de desarrollo.
4.4.2.8. REUNIÓN DE INICIO DE SPRINT
Reunión para determinar las funcionalidades o historias de usuario
que se van a incluir en el próximo incremento. En esta reunión
participan: el dueño de producto, el scrum master y el equipo de
desarrollo.
4.4.2.9. REUNIÓN TÉCNICA DIARIA
Puesta en común diaria del equipo con presencia del Coordinador del
proyecto o Scrum Manager de duración máxima de 10 minutos. Las
reuniones diarias durante este proyecto se realizaron por la mañana
antes del inicio de cada jornada, donde se intercambiaron los avances
del día anterior y el avance previsto para ese día.
4.4.2.10. REUNIÓN DE CIERRE DE SPRINT Y ENTREGA DEL
INCREMENTO.
Reunión para probar y entregar el incremento al gestor del producto.
En esta reunión participan el dueño de producto para realizar las
pruebas necesarias, el equipo de producto que realiza la
demostración y el scrum master que coordina y cumple la función de
facilitador. En algunos sprints la reunión de retroalimentación se
realizó al día siguiente de la entrega y hubo un descanso el resto de la
semana. En los últimos sprints las reuniones de entrega y de
retroalimentación se realizaron el mismo día, debido a la proximidad
de la fecha final prevista para la entrega final. Estos últimos sprints
fueron muy cortos y sin periodos de descanso.
129
4.4.5. RESUMEN DE SPRINTS
Para mostrar el desarrollo de cada uno de los sprints mostraremos las
capturas de los siguientes artefactos:
Pila de Sprint (Backlog).
Calendario.
Gráfico Burn Down.
4.4.2.11. SPRINT 1
Tabla Nº8
Objetivo Fecha de Inicio Fecha de Término
Componentes MVP terminados 03-09-2012 25-09-2012
Fuente: Elaboración propia
Figura 23: Tiempo Estimado para la entrega del Sprint 1
130
Figura 24: Definición de Tareas del Sprint 1
Figura 25: Grafico Burndown que refleja el avance del Sprint 1 en función del tiempo
131
4.4.2.12. SPRINT 2
Tabla Nº9
Objetivo Fecha de Inicio Fecha de Término
Renderizador de HTML listo 01-10-2012 23-10-2012
Fuente: Elaboración propia
Figura 26: Tiempo Estimado para la entrega del Sprint 2
Figura 27: Definición de Tareas del Sprint 2
132
Figura 28: Grafico Burndown que refleja el avance del Sprint 2 en función del tiempo
4.4.2.13. SPRINT 3
TablaNº10
Objetivo Fecha de Inicio Fecha de Término
Binding de métodos y propiedades listos
29-10-2012 12-11-2012
Fuente: Elaboración propia
133
Figura 29: Tiempo Estimado para la entrega del Sprint 3
Figura 30: Definición de Tareas del Sprint 2
134
Figura 31: Grafico Burndown que refleja el avance del Sprint 3 en función del tiempo
4.4.2.14. SPRINT 4
Tabla Nº11
Objetivo Fecha de Inicio Fecha de Término
Integración con servicios del lado del Servidor terminados
13-11-2012 26-11-2012
Fuente: Elaboración propia
135
Figura 32: Tiempo Estimado para la entrega del Sprint 4
Figura 33: Definición de Tareas del Sprint 4
136
Figura 34: Grafico Burndown que refleja el avance del Sprint 4 en función del tiempo
4.4.2.15. SPRINT 5
Tabla Nº12
Objetivo Fecha de Inicio Fecha de Término
Plugins de desarrollo terminados 27-11-2012 07-12-2012
Fuente: Elaboración propia
137
Figura 35: Tiempo Estimado para la entrega del Sprint 5
Figura 36: Definición de Tareas del Sprint 5
138
Figura 37: Grafico Burndown que refleja el avance del Sprint en función del tiempo
139
CAPITULO V
DISCUSIÓN RESULTADOS
140
CONCLUSIONES
1. Los Framework basados en Javascript y HTML son un resultado de la
evolución de capacidades implementadas en JavaScript teniendo como
base la orientación a documentos lo cual genera inconvenientes a la
hora de implementar aplicaciones web del lado del cliente.
2. Los Framework para la implementación de aplicaciones web del lado del
cliente basadas en JavaScript y HTML superan las limitaciones de
usabilidad e interacción de las aplicaciones web tradicionales debido a
que estas librerías se encarga de gestionar las solicitudes al servidor de
manera asíncrona.
3. La aparición de HTML5 reduce la brecha entre las aplicaciones de
escritorio y las aplicaciones web.
4. Se estudiaron las principales Framework orientados a desarrollo de
aplicaciones Web, estudio que sirvió para la elección del Framework en
el cual se basaría el desarrollo del framework modelo vista presentador
planteado en esta tesis.
5. Se implementó un Framework Modelo vista presentador para el
desarrollo de aplicaciones Web del lado del cliente el cual nos permite
enlazar los datos y métodos de los diferentes componentes en base a
descriptores definidos en documentos XML.
141
RECOMENDACIONES
1. Los Framework para desarrollo de aplicaciones Web del lado del cliente
son nuevos y complejos generando con esto problemas de
vulnerabilidad, fallas de usabilidad y seguridad. Para asegurarse de que
los usuarios de estas aplicaciones Web no sufran estos inconvenientes,
futuros trabajos deben buscar metodologías de probar la usabilidad y
seguridad de estas aplicaciones en el contexto de la experiencia del
usuario.
2. Para poder desarrollar aplicaciones web se recomienda el uso de los
diferentes patrones de diseño para así poder evitar problemas de
escalabilidad, mantenibilidad y reutilización de código.
3. Se propone como futuras investigaciones, El desarrollo de Controles de
Usuarios basados en JavaScript y HTML con mayor orientación al
desarrollo de aplicaciones Web.
4. Se propone como futuras investigaciones, El desarrollo de Frameworks
modelo vista controlador para las librerías como Dojo ToolKit y Yahoo UI
que permitan en desarrollo de aplicaciones Web del lado del cliente con
una menor orientación a documentos,
142
BIBLIOGRAFÍA
LIBROS
GOER, EVAN. Yui 3 Cookbook. Editorial O‟Reilly Media, Inc. Edición 2012
OSMANI, ADDY. Developing Backbone.Js Applications. Editorial ISBN edición 2012
GRONER, LOIANE. Ext Js 4 First Look. Editorial Packt Publishing Copyright © 2011
PALACIO, JUAN. Flexibilidad con Scrum Principios de Diseño e Implantación de Campos de Scrum. Editorial Safecreative Edición Octubre – 2008
PALACIO, JUAN Y RUATA, CLAUDIA. Scrum Manager: Proyectos – Formación. Editorial Safecreative Edición 1.3.2 Octubre – 2010
GARCIA, JESUS. Ext Js In Action. Editorial Manning Publications Edición 2011
RAMON, JORGE Ext.Js.3.0.Cookbook. Editorial Packt Publishing Edición Octubre 2009
MACLEES, NATALIE. Jquery For Designers Beginner's Guide. Editorial Packt Publishing Copyright © 2012
SNIDER, MATT. Yahoo User Interface 2.X Cookbook. Editorial Packt Publishing Copyright © 2010
GILL RAWLD, RIECKE CRAIG & RUSSELL ALEX. Mastering Dojo Javascript And Ajax Tools For Great Web Experiences. Editorial ISBN Edición 2008
Scrum Manager Proyectos Apuntes De Formación. Editorial Safecreative 2009
DEEMER PETE, BENEFIELD GABRIELLE, LARMAN CRAIG & VODDE BAS. Información Básica De Scrum (The Scrum Primer). Versión 1.1 2009
KNIBERG, HENRIK. Scrum y XP Desde Las Trincheras Como Hacemos Scrum. Editorial C4Media Inc Edición © 2007
143
ORCHARD LESLIE MICHAEL, PEHLIVANIAN ARA, KOON SCOTT & JONES HARLEY. Professional Javascript Frameworks Prototype, Yui, Ext Js, Dojo And Mootools. Editorial Wiley Publishing, Inc. Edición 2009
BLANKENSHIP JERREL, BUSSA MATTHEW & MILLETT SCOTT. Pro Agile .Net Development With Scrum. Editorial Apress Edición 2010
P. CLARK, MARTIN. Data Networks, Ip And The Internet: Protocols, Design And Operation. Editorial John Wiley& Sons, Ltd., 2003
BERGSTEN, HANS. Java Server Pages™. Editorial O'Reilly Edición 2nd Edition, 2002
MORITZ, FLORIAN. Rich Internet Applications (Ria):A Convergence Of User Interface Paradigms Of Web And Desktop Exemplified. Edición 2008
BRINZAREA-IAMANDI BOGDAN, DARIE CRISTIAN & HENDRIX AUDRA. Ajax And Php Building Modern Web Applications. Editorial Packt Publishing 2nd Edition, 2009.
GASSNE, DAVID. Flash Builder 4 And Flex 4 Bible. Editorial Wiley Publishing, 2010.
FALKNER JAYSON & JONES KEVIN. Servlets And Java Server Pages™: The J2ee™ Technology Web Tier. Editorial Addison Wesley, 2003
GASSNER, DAVID. Flash Builder 4 And Flex 4 Bible. Editorial Wiley Publishing, 2010
HORN, SHANNON. Microsoft Silverlight 3: A Beginner‟s Guide. Editorial McGraw Hill, 2010
GAMMA ERICH, HELM RICHARD, JOHNSON RALPH & VLISSIDES JOHN. Patrones De Diseño (Elementos De Software Orientado A Objetos Reutilizables).
STEFANOV, STOYAN. Javascript Orientado A Objetos.
EGUÍLUZ PÉREZ, JAVIER. Introduccion A Javascrip.
BLANKENSHIP JERREL, BUSSA MATTHEW & MILLETT SCOTT. Pro Agile .Net Development With Scrum.
144
TESIS
ADRIÁN YAZYI, SERGIO. Una Experiencia Práctica de Scrum a Través del Aprendizaje Basado en Proyectos Mediado por Tic en un Equipo Distribuido. Salamanca (España). Universidad de Salamanca. Junio 2011
OCHOA TAPIA, GRETTY MAIBELY Y TEJADA AUCCACUSI, JORGE CARLOS. Estudio de las Tecnologías Ria y Data Push de Servicios Multimedia en Tiempo Real. Cusco (Perú). Universidad Nacional de San Antonio Abad del Cusco. Agosto 2010
PÁGINAS WEB
Wikipedia.org, Comparativa de navegadores web [en línea]. Fundación
Wikimedia Inc. [actualizado 23 Dic 2012; accesado 24 Dic 2012].
Disponible en:
http://es.wikipedia.org/wiki/Anexo:Comparativa_de_navegadores_web
DesarrolloWeb.com, Ranking Navegadores Octubre 2012 [en línea].
Miguel Angel Alvarez Director de DesarrolloWeb.com [actualizado 07
Nov 2012; accesado 14 Dic 2012]. Disponible en:
http://www.desarrolloweb.com/de_interes/ranking-navegadores-octubre-
2012-7634.html
Mate.asfusion.com, Ejemplo de Ciclo de Vida de Mate [en línea].
WPDesigner. [actualizado 08 Ene 2009; accesado 24 Nov 2012]
Disponible en: http://mate.asfusion.com/archives/category/examples
Swizframework.jira.com, Que es Swiz? [en línea]. Administrador Brian
Kotek [actualizado 22 May 2009; accesado 12 Set 2012] Disponible en:
http://swizframework.jira.com/wiki/display/SWIZ/Home
Webvigo.com, Backbone.js estructura MVC en cliente [en línea].
Administrador Jacobo Varela 2010, accesado 12 Set 2012] Disponible
en: http://www.webvigo.com/blog/backbone-js-estructura-mvc-en-cliente/
Sproutcore.com, Statecharts en SproutCore [en línea]. Escrito por
Joachim Haagen Skeie, [actualizado 12 Dic 2012; accesado 01 Dic
2012] Disponible en: http://blog.sproutcore.com/tag/statecharts/
Slideshare.net, ExtJS4 Arquitectura MVC Mapa Mental [en línea].
Trabajo hecho por Loiane Groner, [actualizado 17 Jul 2012; accesado
10 Oct 2012] Disponible en: http://www.slideshare.net/loianeg/extjs-4-
mvc-architecture-mind-map-13669488
145
Mclibre.org, Historia de la Web: los navegadores [en línea]. Esta página
forma parte del curso "Páginas web HTML / XHTML y hojas de estilo
CSS" Autor: Bartolomé Sintes Marco, [actualizado 27 Nov 2012;
accesado 10 Oct 2012] Disponible en:
http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadore
s.html
Wikipedia.org, Navegador web [en línea]. Fundación Wikimedia Inc.
[actualizado 17 dic 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Navegador_web
Wikipedia.org, Navegador web [en línea]. Fundación Wikimedia Inc.
[actualizado 17 dic 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Navegador_web
Wikipedia.org, Mozilla Firefox [en línea]. Fundación Wikimedia Inc.
[actualizado 29 Dic 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Mozilla_Firefox
Wikipedia.org, Java Servlet [en línea]. Fundación Wikimedia Inc.
[actualizado 28 Dic 2012; accesado 10 Oct 2012] Disponible en:
http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers
Microsoft.com, Guía básica de ASP.NET [en línea]. Microsoft
Corporation [actualizado 29 Jun 2012; accesado 18 Set 2012]
Disponible en: http://support.microsoft.com/?scid=kb;es;305140
Microsoft.com, .NET Framework [en línea]. Microsoft Corporation
[actualizado 01 Ene 2012; accesado 10 Oct 2012] Disponible en:
http://msdn.microsoft.com/es-pe/netframework/default.aspx
Wikipedia.org, WYSIWYG [en línea]. Fundación Wikimedia Inc.
[actualizado 21 Dic 2012; accesado 10 Oct 2012] Disponible en:
http://en.wikipedia.org/wiki/WYSIWYG
Wikipedia.org, PHP [en línea]. Fundación Wikimedia Inc. [actualizado 30
Dic 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/PHP
Wikipedia.org, Applet Java [en línea]. Fundación Wikimedia Inc.
[actualizado 09 Nov 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Applet_Java
146
Wikipedia.org, Applet [en línea]. Fundación Wikimedia Inc. [actualizado
24 Oct 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Applet
Wikipedia.org, Kit de Herramientas de Ventana Abstracta [en línea].
Fundación Wikimedia Inc. [actualizado 24 Dic 2012; accesado 10 Oct
2012] Disponible en:
http://es.wikipedia.org/wiki/Abstract_Window_Toolkit
Wikipedia.org, Swing [en línea]. Fundación Wikimedia Inc. [actualizado
12 Jul 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Swing_(biblioteca_gráfica)
Microsoft.com, Common Language Runtime (CLR) [en línea]. Microsoft
Corporation [actualizado 30 Ago 2012; accesado 10 Oct 2012]
Disponible en: http://msdn.microsoft.com/es-pe/library/8bs2ecf4.aspx
Ibm.com, Nuevos elementos en HTML 5 [en línea]. International
Business Machines [actualizado 07 Ago 2009; accesado 10 Oct 2012]
Disponible en: http://www.ibm.com/developerworks/library/x-
html5/?ca=dgr-lnxw01NewHTML
Wikipedia.org, HTML5 [en línea]. Fundación Wikimedia Inc. [actualizado
15 Dic 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/HTML5
Wikipedia.org, Patrón de diseño [en línea]. Fundación Wikimedia Inc.
[actualizado 25 Oct 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o
Wikipedia.org, Modelo Vista Controlador [en línea]. Fundación Wikimedia
Inc. [actualizado 24 Dic 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Modelo_Vista_Controlador
TheArtofTheLeftFoot.blogspot.com, El patrón Modelo-Vista-Presentador
(MVP) [en línea]. Blog de Oscar Arrivi [actualizado 03 Oct 2010;
accesado 05 Oct 2012] Disponible en:
http://theartoftheleftfoot.blogspot.com/search/label/MVP
Wikipedia.org, Dojo toolkit [en línea]. Fundación Wikimedia Inc.
[actualizado 31 Oct 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Dojo_toolkit
147
Wikipedia.org, Yahoo! UI Library [en línea]. Fundación Wikimedia Inc.
[actualizado 10 Oct 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Yahoo!_UI_Library
Wikipedia.org, Estilo Vancouver [en línea]. Fundación Wikimedia Inc.
[actualizado 28 Oct 2012; accesado 10 Oct 2012] Disponible en:
http://es.wikipedia.org/wiki/Estilo_Vancouver#Libros_y_otras_monograf.
C3.ADas