TesisFinal 30-12-12

Contenido
CAPITULO I .................................................................................................................................. 10 PLANTEAMIENTOS GENERALES ................................................................................................... 10 1.1. 1.2. 1.3. DESCRIPCION DEL PROBLEMA..................................................................................... 11 PLANTEAMIENTO DEL PROBLEMA .............................................................................. 11 OBJETIVOS ................................................................................................................... 11 OBJETIVO PRINCIPAL ........................................................................................... 11 OBJETIVOS ESPECFICOS ...................................................................................... 12 JUSTIFICACION..................................................................................................... 12 MTODOLOGIA DE INVESTIGACIN .................................................................... 13 LIMITACIONES ..................................................................................................... 14 BENEFICIOS DEL PROYECTO ................................................................................ 14
1.3.1. 1.3.2. 1.3.3. 1.3.4. 1.3.5. 1.3.6.
CAPITULO II ................................................................................................................................. 15 REVISION BIBLIOGRAFICA .............................................................. Error! Marcador no definido. 2.1. ANTECEDENTES ........................................................................................................... 16 CAIRNGORM ........................................................................................................ 16 MATE ................................................................................................................... 18 SWIZ..................................................................................................................... 19 BACKBONE ........................................................................................................... 20 SPROUTCORE MVC .............................................................................................. 21 SAMMY ................................................................................................................ 22 MVC EXTJS ........................................................................................................... 23
2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.1.7. 2.2.
MARCO CONCEPTUAL ................................................................................................. 24 INTERNET ............................................................................................................. 24 LA WORL WIDE WEB (WWW).............................................................................. 25 TECNOLOGIAS DEL LADO DEL SERVIDOR ............................................................ 53 TECNOLOGIAS DEL LADO DEL CLIENTE................................................................ 58 FRAMEWORK ....................................................................................................... 76 PATRON DE DISEO ............................................................................................ 76 SCRUM ............................................................................................................... 101
2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7.
CAPITULO III .............................................................................................................................. 105 ESTUDIO DE FRAMEWORKS PARA LA IMPLEMENTACION DE APLICACIONES WEB DEL LADO DEL CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML ........................................................................ 105 1
3.1.
DOJO TOOLKIT ........................................................................................................... 106 ORIGEN Y DESARROLLO ..................................................................................... 106 CARACTERSTICAS.............................................................................................. 107 ARQUITECTURA ................................................................................................. 109
3.1.1. 3.1.2. 3.1.3. 3.2.
EXTJS .......................................................................................................................... 110 CORE .................................................................................................................. 111 UI COMPONENTS............................................................................................... 111 WEB REMOTING ................................................................................................ 114 DATA SERVICES .................................................................................................. 114 DRAG AND DROP ............................................................................................... 114 GENERAL UTILITIES ............................................................................................ 114
3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.2.5. 3.2.6. 3.3.
YUI (INTERFAZ DE USUARIO YAHOO) ........................................................................ 115 NCLEO ............................................................................................................. 115 UTILIDADES........................................................................................................ 116 CONTROLES / WIDGETS..................................................................................... 117 CSS HERRAMIENTAS .......................................................................................... 118 HERRAMIENTAS DE DESARROLLO ..................................................................... 118 HERRAMIENTAS DE CONTRUCCIN .................................................................. 119
3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5. 3.3.6.
CAPITULO IV .............................................................................................................................. 120 IMPLEMENTACION DE FRAMEWORK MODELO VISTA PRESENTADOR PARA APLICACIONES WEB DEL LADO DEL CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML ................................................ 120 4.1. 4.2. 4.3. 4.4. DESCRIPCION DEL PROBLEMA................................................................................... 121 RESUMEN DEL PROYECTO ......................................................................................... 121 BENEFICIOS................................................................................................................ 122 DESCRIPCIN DE LA METODOLOGA DE TRABAJO.................................................... 122 INTRODUCCIN ................................................................................................. 122 DESCRIPCIN GENERAL DE LA METODOLOGA................................................. 123 PERSONAS Y ROLES DEL PROYECTO. ................................................................. 124 ARTEFACTOS ...................................................................................................... 124 RESUMEN DE SPRINTS ....................................................................................... 129
4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5.
CONCLUSIONES ......................................................................................................................... 139 RECOMENDACIONES ................................................................................................................. 141 BIBLIOGRAFA .. 142
PRESENTACIN
SEOR DECANO DE LA FACULTAD DE CIENCIAS QUMICAS, FSICAS Y MATEMTICAS DE LA UNIVERSIDAD NACIONAL SAN ANTONIO ABAD DEL CUSCO. SEORES MIEMBROS DEL JURADO: De acuerdo al Reglamento de Grados y Ttulos vigentes para optar el Ttulo Profesional de Ingeniero Informtico y de Sistemas ponemos a vuestra disposicin la Tesis colectiva, intitulada FRAMEWORK PARA LA
IMPLEMENTACIN DEL PATRN MODELO VISTA PRESENTADOR EN CLIENTES WEB (HTML-JAVASCRIPT) que abarca el estudio de frameworks para la implementacin 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 seores dictaminantes y miembros del jurado, dispensen las deficiencias encontradas y valoren el contenido desarrollado que trata de dar un aporte tecnolgico a la sociedad en general.
Los Tesistas.
AGRADECIMIENTOS
Agradecer de manera especial a nuestro Asesor, Lic. Jos Mauro Pillco Quispe por el tiempo y la dedicacin prestados para el desarrollo de esta Tesis.
A todas las personas que han colaborado en el desarrollo de esta Tesis.
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, an sin saberlo, en lograr este objetivo.
Jorge Francisco Castro Alvarez
A mis padres Por su apoyo incondicional a pesar que no siempre supe corresponderles tanto cario y paciencia, que tuvieron en todos estos aos. 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 estn ah lejos o cerca de uno, pero que siempre estarn en mi corazn.
Luis Rafael Callapia Cosio
Slo un exceso es recomendable en el mundo: el exceso de gratitud. Jean de la Bruyre
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 da esas experiencias de usuario enriquecidas son mayormente implementadas en tecnologas 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 tecnologas 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
aplicacin web del lado Servidor haciendo de esta forma la actualizacin modificacin y migracin de tecnologa en el cliente mucho ms flexible e independiente de la implementacin del Servidor. Generando con esto el desarrollo de diferentes Frameworks implementados en JavaScript para la comunicacin entre el cliente y el Servidor as como para el manejo, control y actualizacin del DOM (Modelo de Objetos de Documento). Hoy en da se cuenta con un nmero considerable de frameworks que permiten la implementacin 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 ms completos, maduros, que gozan de una popularidad considerable y permiten la implementacin 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 patrn modelo vista presentador (MVP), haciendo uso de inyeccin de dependencia y de archivos XML para la definicin de las interfaces grficas. Ofrece informacin preliminar acerca de la Web, una
7
visin general de tecnologas del lado del cliente, e identifica las diferentes soluciones existentes para la implementacin patrones de diseo como modelo vista controlador (MVC) en aplicacin web del lado del cliente basadas en HTML, JavaScript y CSS.
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.
9
CAPITULO I PLANTEAMIENTOS GENERALES
10
1.1. DESCRIPCION DEL PROBLEMA

Actualmente existe un nmero considerable de framework para la implementacin de patrones de programacin en el desarrollo de aplicaciones web. Sin embargo la mayora de estos fueron
implementados en tecnologas 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 tecnologas como XML, JSON, HTML, JavaScript y CSS3 ha permitido la aparicin de diferentes Framework que facilitan el manejo del DOM (Modelo de Objetos de Documento), la comunicacin entre el cliente y el Servidor as como tambin la implementacin de patrones de diseo como modelo vista controlador, modelo vista presentador, etc. A pesar de existir mltiples Framework para la implementacin de patrones de programacin basados en HTML, JavaScript y CSS3, estos carecen de claridad y eficiencia a la hora de utilizarlos y en especial en la definicin de las interfaces de usuario ya que las definen mediante cdigo JavaScript, generando problemas sustancialmente importantes que afectan el trfico, la mantenibilidad, la escalabilidad del sistema y tiempo de aprendizaje de los desarrolladores.
1.2. PLANTEAMIENTO DEL PROBLEMA

Cmo resolver el problema de legibilidad, mantenibilidad, escalabilidad y reutilizacin de cdigo 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 reutilizacin de cdigo?
1.3. OBJETIVOS
1.3.1. OBJETIVO PRINCIPAL
Implementar un Framework para la implementacin del patrn Modelo
11
Vista Presentador en clientes web basados en tecnologas HTML y JavaScript.
1.3.2.
OBJETIVOS ESPECFICOS
Definir y implementar las clases y mecanismos necesarios para registrar el contrato que debe de existir entre los diferentes componentes del patrn modelo vista presentador (VistaPresentador, 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 funcin 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 funcin 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 aplicacin, misma que ha de implementar los mecanismos necesarios para notificar de sus cambios al presentador y modificarse as mismo en funcin 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 implementacin de patrones de diseo en aplicaciones web del lado del cliente, aplicaciones que han sido siempre difciles de escribir, difcil de organizar y difcil de mantener. Teniendo una tendencia de crecimiento rpido y sin control a medida que agrega ms funcionalidad y desarrolladores a un proyecto.
12
Los Frameworks existentes como EXTJS, YUI (interfaz de usuario Yahoo) y Dojo Toolkit permiten crear aplicaciones web del lado del cliente con caractersticas similares a las de una aplicacin de escritorio a travs del acceso al DOM y facilitando la comunicacin e intercambio de datos con el Servidor, pero utilicemos la librera que utilicemos lo comn es tener un montn de cdigo JavaScript que despus 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 cdigo HTML para que sigan funcionando como se espera. A pesar de que estos frameworks nos permiten implementar el patrn de diseo modelo vista control an siguen generando problemas en el desarrollo, escalabilidad y mantenimiento de las aplicaciones especialmente en la definicin de las interfaces de usuario ya estas son definidas en el leguaje JavaScript el cual no fue creado para la definicin de interfaces de usuario sino ms bien para dar funcionalidad a las mismas. Otras de las limitaciones que presentan estos framework son las inherentes a la implementacin 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 patrn Modelo vista controlador y el patrn modelo vista presentador ya que el primero obliga a implementar un controlador por cada vista para poder ejecutar las acciones solicitadas a travs de las interacciones con el usuario. Mientras que en el segundo la vista es la encargada de responder al usuario.
1.3.4.
MTODOLOGIA DE INVESTIGACIN
La metodologa del trabajo de investigacin es Descriptiva y Aplicativa. Descriptiva porque describir las caractersticas del proyecto. Aplicativa porque permitir resolver el problema, alcanzar los objetivos y evaluar los resultados. La metodologa tecnolgica que
13
se usara ser el marco de trabajo denominado SCRUM que se apoya sobre la metodologa de Programacin 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 implementacin del patrn modelo vista presentador en aplicaciones clientes basados en tecnologa HTML, JavaScript y CSS. En este entender el proyecto no se encargara del desarrollo de libreras para el manejo del Modelo de Objetos del Documento (DOM), as como tampoco de la implementacin de controles de usuario para la renderizacion de las vistas motivo por el cual se usaran libreras implementadas por terceros.
1.3.6.
BENEFICIOS DEL PROYECTO

Al implementar el Framework Modelo Vista Presentador podr resolverse la mayora de los problemas existentes en la
implementacin 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.
14
CAPITULO II MARCO TERICO
15
2.1. ANTECEDENTES
El primer intento de mejorar la usabilidad de las aplicaciones web, acercndolas ms a sus contrapartes de escritorio, fue realizado por Sun Microsystems con la introduccin de los Applets Java. En un principio la nica tecnologa que nos permita desarrollar clientes web, a pesar de sus ventajas, en dicha poca los ordenadores carecan del poder de computo necesario para poder ejecutar ligeramente este tipo de aplicaciones, as como la falta de velocidades aceptables para la conexin conllevaron a una mala aceptacin de esta tecnologa, impidiendo que se logren desarrollar frameworks dedicados a la implementacin de patrones de diseo. Otra tecnologa que intento llevar la experiencia de las interfaces de escritorio a la web es Adobe Flash. La misma que gozo de gran aceptacin en su momento, permitiendo el desarrollo de frameworks especializados en la implementacin de diferentes patrones de diseo, entre los que podemos mencionar:
2.1.1.
CAIRNGORM
Es el ms antiguo y el ms conocido de los framework hechos para Flex Builder. En realidad, es una micro-arquitectura, es decir, una coleccin de patrones de diseo que han demostrado que funcionan bien con otros, Se basa en el patrn MVC y ha diseado especficamente para facilitar la sincronizacin de estados y de datos entre el cliente y el Servidor, mientras se mantiene la programacin de la capa de vista separada de la aplicacin de datos. La construccin de un proyecto en Cairngorm implica dividir la aplicacin 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 acta como un repositorio de datos-representa el estado del programa. La naturaleza de la clase singleton garantiza que todos los
SINGLETON: est diseado para restringir la creacin de objetos pertenecientes a una clase o el valor de un tipo a un nico
objeto, vase: http://es.wikipedia.org/wiki/Singleton.
16
componentes del programa tienen acceso a los mismos datos. ServiceLocator._ es otro singleton que acta con una ubicacin centralizada para el almacenamiento de servicios tales como HTTP Services. Una vez ms, porque esta clase es un producto nico, todos los componentes del programa tendrn acceso a los mismos servicios. Lgica empresarial._ se encapsula en clases de comandos que implementan el patrn de comando. Estas clases representan la lgica 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-cairngormdesarrollando.html
17
2.1.2.
MATE
Fue creado para poder implementar el patrn 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 bsicas MXML para poder enlazar las vistas con el presentador. Mate tambin implementa la idea de inyeccin 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 travs de inyeccin 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
18
2.1.3.
SWIZ
Swiz es un framework de inversin de dependencia (IoC) framework que proporciona metodologas para simplificar la gestin de eventos y llamadas asincrnicas a mtodos 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, especficamente huye de la imposicin 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 aplicacin. En su esencia, Swiz es una fbrica centralizada. Los componentes se cargan en la fbrica a travs de una clase BeanLoader. Cuando se inicia la aplicacin, la fbrica se encarga de la creacin de instancias de sus componentes. Swiz tambin proporciona gestin de la dependencia a travs de metatag (informacin adicional de la cual hace uso el framework para poder definir la dependencia entre objetos) personalizado llamado Autowire. Esta etiqueta es un mtodo de definicin de las dependencias entre clases Swiz.
Fig.3.Flujo de SWIZ Fuente: http://swizframework.jira.com/wiki/display/SWIZ/Home
19
Posteriormente la evolucin y mejoras de tecnologas como HTML, JavaScript y CSS. Permitieron crear clientes aplicaciones ricas en internet, lo que conllevo al desarrollo de mltiples tipos de frameworks para el manejo del DOM, sincronizacin de datos con el Servidor e implementacin de diferentes patrones de diseo entre los que podemos mencionar:
2.1.4.
BACKBONE
Backbone fue creado para poder implementar en clientes web JavaScript el Patrn Modelo Vista Controlador permitindonos configurar/separar nuestra aplicacin 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 almacn de datos y comunicacin con el Servidor. Backbone.Model y Backbone.Collection, en donde cada una tiene sus funciones y mtodos especficos. Capa Vista._ Aqu Backbone provee una sola clase llamada Backbone.View, que cuenta con mtodos y funciones que permiten administrar los eventos realizados por el usuario al interactuar con los elementos de la pgina. Capa Controlador._ Backbone cambia el nombre de sta capa por otro concepto, pero que bsicamente realizan la misma funcin: Backbone.Router, su funcin es manejar los enlaces, URL y funcionar como una central de acciones.
20
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 cdigo abierto, permite implementar el Patrn de Diseo "Modelo, Vista, Controlador", en clientes web (HTML- JavaScript). Este Framework extiende la arquitectura MVC tradicional mediante la adicin de ms de tres capas: Interfaz de Servidor, Display y Responders. Models._ Esta capa se encarga de contener los datos de aplicacin y gran parte de la lgica de negocio, tales como contactos, fotos o correos electrnicos. Views._ La funcin de esta capa es de manejar la pantalla y responder a eventos de usuario, pero en general tienen poco o ningn conocimiento especfico 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
21
el modo fuera de lnea. 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 cdigo 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 pequeo y poco conocido, idneo para pequeos proyectos, tiene una estructura basada en plugins y tambin nos permite implementar el patrn de diseo "Modelo, Vista, Controlador, basada en respuesta a URL mediante funcin JS las mismas que responde con contenidos HTML que posteriormente
actualizara las secciones correspondientes de la pgina. DataModel._ Capa encargada del manejar las entidades y la comunicacin 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
22
capa ViewModel (conjunto de direcciones URL especfica).
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 patrn de
diseo 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 estara 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 coleccin de datos para luego poder desplegar la informacin en un widget como un Grid, View, Combo box, o algn otro control que permita la visualizacin de colecciones de datos. Controlador._ Esta clase nos permite agregar la interaccin y funcionalidad a nuestra aplicacin 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 vendra a representar la capa de datos el cual se encarga de almacenar los modelos para luego ser usados en un Grid.
23
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 comunicacin interconectadas, que utilizan la familia de protocolos TCP (Control de Transmisin) /IP (Protocolo de Internet), garantizando que las redes fsicas heterogneas que la componen funcionen como una red lgica nica, de alcance mundial. Sus orgenes se remontan a 1969, cuando se estableci la primera conexin de computadoras, conocida como ARPANET, entre tres universidades en California y una en Utah, EE.UU. Uno de los servicios que ms xito ha tenido en Internet ha sido la World Wide Web (WWW, o "la Web"), Al contrario de lo que se piensa comnmente, Internet no es sinnimo 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 informacin mucho ms reciente, desarrollado inicialmente por Tim
2
OCHOA TAPIA GRETTY MAIBELY,TEJADA AUCCACUSI JORGE CARLOS, Estudio De Las Tecnologas Ria Y Data Push De Servicios Multimedia En Tiempo Real, Universidad Nacional de San Antonio Abad Del Cusco,2010:Pag23
24
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 transmisin.
2.2.2.
LA WORL WIDE WEB (WWW)3

La World Wide Web (WWW) emergi en los inicios de la dcada de los 90s y se ha convertido rpidamente en el recurso ms poderoso para compartir informacin. Ha revolucionado los negocios, haciendo posibles cosas que eran antes inconcebibles, como compras electrnicas, banca electrnica, televisin en lnea, apuestas en lnea, bsquedas en lnea, video llamadas, correo electrnico, etc.
Fig. 7. La World Wide Web (WWW): una combinacin 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 tecnologas surgieron a inicios de los 90s para dar origen a la World Wide Web. Estas son:
MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 : 473
25
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
especificacin del Sistema de nombres de dominios (DNS). Antes del sistema de nombres de dominios, ya era comn en el
sistema operativo UNIX la creacin de enlaces de nombres. Estos enlaces eran registrados bajo un archivo de configuracin donde se relacionaba el nombre de un computador con su ubicacin 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 dems Servidores. Inicialmente todas los direcciones de cada host en la ARPANET eran administradas de manera centralizada, pero a medida que el tamao de la red creca y el nmero de equipos conectados a la red se empezaba a multiplicar, este modelo se convirti poco prctico, 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 bsicamente para mapear un nombre (hostname) de Servidor en la red con una direccin IP, para localizar dicho Servidor y establecer comunicacin con este. As es posible resolver la direccin web www.servidor.com a una direccin IP (por ejm.: 37.168.153.232) del Servidor relacionado. Utilizando la direccin IP, el Servidor puede ser contactado usando cualquiera de los protocolos IP.
26
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 bsicos del sistema de nombres de dominio: El espacio de nombres de dominio.- Define un esquema de nombres jerrquico para todos los hosts y subredes en un dominio determinado. Los Servidores de nombres.- Son programas de Servidor que almacenan informacin 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 resolucin.- Son programas que se ejecutan en las computadoras del usuario. Extraen, usan y almacenan en cache informacin procedente de los Servidores de nombres en respuesta a pedidos DNS del cliente (denominados consultas). Un programa de resolucin funciona tpicamente en un sistema operativo cliente. Un navegador web usualmente integra esta funcionalidad de resolucin.
27
Fig. 9. El Sistema de Nombre de Dominios (DNS) provee de un servicio de bsqueda 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 mltiples archivos de texto e imgenes, donde cada uno de estos archivos puede ser almacenado en un computador distinto. Un hiperenlace es una clase de puntero usado para marcar la posicin en un documento donde un texto, imagen u otro deben de apuntar a la ubicacin donde el archivo se encuentra almacenado.
Frecuentemente el hiperenlace aparece en texto como una direccin de nombre de dominio, precedido por http://www. HTTP es el protocolo que recupera el archivo sealado por el hiperenlace. La versin actual del protocolo es la versin 1.2 (HTTP/1.2). El protocolo de transferencia de hipertexto permite: Transferencia de datos basada en punteros (por tanto la recuperacin de datos, capacidades de bsqueda o anotacin de documentos cientficos con referencias bibliogrficas a otros documentos o reportes). Hiperenlazar datos mediante enlaces a archivos. El protocolo HTTP es usado entre un cliente HTTP (tambin llamado el
5
28
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 peticin 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 travs del puerto TCP 80. Los intermediarios HTTP pueden ser proxys o caches. Dichos dispositivos no estn 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 peticin 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.
29
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 peticin al Servidor de origen. URIs, URLs y URNs7 El URI de solicitud (Universal Resource Identifier / Identificador de Recurso Universal) es una combinacin 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 estndar: http://host [:puerto] / ruta_abs [?consulta] Donde host es el nombre de dominio del Servidor HTTP, puerto es el nmero 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 informacin relacionada con la solicitud. Si el puerto no se especfica, el puerto por defecto (80) es usado. Un ejemplo de URI podra 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 informacin: Un mtodo de solicitud (por ejm. Un comando como GET, POST, PUT, DELETE, etc.); Un identificador de recurso universal (URI) (Universal Resource Identifier) (tambin llamado identificador de documento
7
universal)
un
URI
es
equivalente
la
MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 : 472 HANS BERGSTEN. JAVA SERVER PAGES, 2nd Edition, O'Reilly, 2002 : 20
30
combinacin 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 versin del protocolo HTTP. Informacin acerca del cliente que realiza la solicitud; y Informacin adicional que forma parte de la solicitud (si se requiere). Los primeros tres elementos listados arriba forman juntos la lnea de solicitud HTTP. Una lnea de solicitud HTTP podra ser: GET http://www.servidor.com/ventas/ordenes.html HTTP/1.1 De entre los tres parmetros el ms importante es el mtodo. HTTP/1.1 incorpora ocho mtodos, aunque slo obliga a
implementar GET y HEAD, siendo todos los dems opcionales. En cualquier caso, los Servidores que implementen alguno de los mtodos adicionales, deben atenerse a la especificacin de los mismos. Existe tambin la posibilidad de implementar mtodos extendidos, a los que la especificacin no pone ningn lmite.
METODOS HTTP Tabla N1

Mtodo GET HEAD Significado Devuelve el recurso identificado en la URL pedida. Funciona como el GET, pero sin que el Servidor devuelva el cuerpo del mensaje. Es decir, slo se devuelve la informacin de encabezado. POST Indica al Servidor que se prepare para recibir informacin del cliente. Suele usarse para enviar informacin desde formularios. PUT Enva el recurso identificado en la URL desde el
31
cliente hacia el Servidor. OPTIONS Pide informacin sobre las caractersticas de
comunicacin proporcionadas por el Servidor. Le permite al cliente negociar los parmetros de comunicacin. TRACE Inicia un ciclo de mensajes de peticin. Se usa para depuracin 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 mtodo se reserva para uso con proxys. Permitir que un proxy pueda dinmicamente convertirse en un tnel. Por ejemplo para
comunicaciones con SSL.

Fuente: MARTIN P. CLARK. DATA NETWORKS
El mtodo GET es el mtodo por defecto para seguir enlaces y enviar datos a travs de Internet. Despus de pulsar sobre un enlace, el navegador enviar el mtodo GET. Si pulsamos sobre el botn de envo (Submit) de un formulario y dentro de la etiqueta <FORM> su propiedad METHOD es igual a GET. En HTTP/1.0 slo se especificaban tres mtodos, GET, POST y HEAD. Estos son, con mucha diferencia, los tres ms extendidos y utilizados Despus del mtodo completo de peticin, se suele enviar los encabezados de solicitud HTTP. ENCABEZADOS DE SOLICITUD HTTP Tablas N 2
Nombre Accept Descripcin Tipo de contenido aceptado por el navegador (por ejemplo, texto/html). Accept-Charset Juego de caracteres que el navegador espera
32
Accept-Encoding
Codificacin de datos que el navegador acepta Idioma que el navegador espera (de forma
Accept-Language
predeterminada, ingls) Identificacin del navegador en el Servidor Tipo de codificacin para el cuerpo de la solicitud
Authorization Content-Encoding
Content-Language Tipo de idioma en el cuerpo de la solicitud Content-Length Extensin del cuerpo de la solicitud Tipo de contenido del cuerpo de la solicitud (por ejemplo, texto/html). Consulte Tipos de MIME Fecha en que comienza la transferencia de datos Utilizado por equipos intermediarios entre el navegador y el Servidor Permite especificar la direccin de correo electrnico del cliente Vnculo entre dos direcciones URL Direccin URL donde se origin la solicitud Direccin URL desde la cual se realiz la solicitud Cadena con informacin sobre el cliente, por ejemplo, el nombre y la versin del navegador y el sistema operativo
Content-Type
Date
Forwarded
From
Link Orig-URL Referer
User-Agent
El encabezado de peticin Accept es el ms usado, indica al Servidor que tipo de respuesta puede tratar el navegador. El encabezado de peticin Accept tiene la siguiente sintaxis general: Accept: tipo-informacion; calidad El tipo de datos o informacin 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
33
extender las caractersticas del correo electrnico, hoy su uso se ha generalizado, tambin puede llamrseles 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 xqueda 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 tpico puede manejar los datos de tres maneras distintas segn el tipo MIME indicado en Content-Type : Visualizar el documento, por ejemplo con tipos text/html . Llamar a una aplicacin 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 negociacin de contenido. El cliente, en su peticin 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
34
Encapsular una o ms entidades dentro del cuerpo de mensaje, mediante los tipos MIME multipart. Quiz el ejemplo ms conocido sea el tipo: multipart/form-data El tipo multipart/form-data ha sido definido para encapsular los datos de un formulario en su envo hacia el Servidor mediante el mtodo POST. En la siguiente tabla aparecen los tipos MIME ms comunes: Tabla N3
Tipo MIME Application Descripcin Indica al Servidor que aplicacin ejecutar basndose en la extensin 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. Comnmente 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.
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 enviarn los datos completos de la URL, sino una versin ms 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 extensin para limitar
35
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 mtodo GET y el encabezado Accept son los encabezados de peticin HTTP ms comunes. Y dentro de los tipos MIME, los ms comunes son los de texto (text), audio (audio) e imgenes (image). Los textos estndar dentro de Internet son html y plain, y para las imgenes son vlidos los formatos jpeg y gif. RESPUESTA HTTP El Servidor HTTP (Servidor de origen) responde a una peticin http con una respuesta http que incluye: Una Lnea de Estado de respuesta (a cual est comprendida por la versin del protocolo HTTP y un cdigo de xito o de error). Los campos del encabezado de respuesta, que son un conjunto de lneas opcionales que permiten aportar
informacin adicional sobre la respuesta y/o el Servidor. Cada una de estas lneas 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 estndares conteniendo informacin proporcionada por el Servidor en el cuerpo de la respuesta a la peticin. Otra informacin de respuesta.
ENCABEZADOS DE RESPUESTA Tablas N4

Nombre ContentEncoding Descripcin
Tipo de codificacin para el cuerpo de la respuesta
36
ContentLanguage Content-Length
Tipo de idioma en el cuerpo de la respuesta
Extensin del cuerpo de la respuesta Tipo de contenido del cuerpo de la respuesta (por ejemplo, texto/html). Fecha en que comienza la transferencia de datos Fecha lmite de uso de los datos Utilizado por equipos intermediarios entre el navegador y el Servidor Redireccionamiento a una nueva direccin URL
Content-Type
Date Expires
Forwarded
Location
asociada con el documento Caractersticas del Servidor que envi la respuesta
Server
LOS CDIGOS DE RESPUESTA Son los cdigos que se ven cuando el navegador no puede mostrar la pgina solicitada. El cdigo de respuesta est formado por tres dgitos: el primero indica el estado y los dos siguientes explican la naturaleza exacta del error. Tabla N5
Cdigo 200 202 Resultado OK Descripcin La peticin se ha servido sin problemas La peticin ha sido aceptada pero todava se est procesando. El documento se ha trasladado a una nueva localizacin. El documento est en el Servidor pero en una localizacin diferente. La sintaxis de la peticin es incorrecta.
Accepted
301
Moved
302
Found
400
BadRequest
37
401
Unauthorized (AUTH_TYPE)
El Servidor tiene restricciones sobre este documento. La peticin se ha prohibido, debido a derechos de accesos o por otras razones. La peticin no se ha podido encontrar. El Servidor ha fallado inesperadamente al intentar servir la peticin El Servidor no puede procesar ms peticiones ahora.
403
Forbidden.
404 500
NotFound
Internal Error
502
Serviceisoverloaded
2.2.2.2.3.
HIPERTEXT MARKUP LANGUAGE (HTML-LENGUAJE DE MARCAS DE HIPERTEXTO) Es un lenguaje usado para formatear documentos para su visualizacin el cual incluye comandos para recuperar texto, imgenes y otros recursos en la World Wide Web. HTML es una aplicacin de SGML (Standard Generalized Markup Language) el cual es un sistema para la organizacin y etiquetado de documentos, este sirve para especificar las reglas de etiquetado de documentos y no impone ningn conjunto de etiquetas en especial. El propsito principal del HTML era las referencias cruzadas entre investigaciones cientficas con hiperenlaces que daban acceso directo a los documentos referidos. En noviembre de 1995 se aprob el estndar HTML 2.0 para la creacin de pginas web. Se cre con objetivos divulgativos, orientado a la actividad acadmica, en el que el contenido de las pginas era ms importante que el diseo. Pero esta versin del HTML careca de muchas herramientas que permitieran controlar el diseo de las pginas y aadir contenido multimedia, por lo que Netscape (cuyos navegadores eran los ms utilizados por aquellos aos) comenz a incluir nuevas etiquetas que no existan en el estndar.
38
El comit encargado de establecer los estndares dentro de Internet, comenz a trabajar en el borrador de una nueva versin 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 creacin de otras muchas etiquetas nuevas. Por ello, no fue bien aceptado por el mercado y varias compaas se unieron para formar un nuevo comit encargado de establecer los estndares del HTML. Este comit pas a llamarse W3C. En enero de 1997 se aprob el estndar HTML 3.2. Este nuevo estndar inclua las mejoras proporcionadas por los navegadores Internet Explorer y Netscape Navigator, que ya haban realizado extensiones sobre el estndar HTML 2.0. En diciembre de 1997 se aprob el estndar HTML 4.0, creado para estandarizar los marcos (frames), las hojas de estilo y los scripts. En septiembre de 2001 se aprob el estndar 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 parmetros 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 parmetro="xxxx"> ...</directiva> HTML no es sensible a maysculas y minsculas. Para HTML es equivalente <HTML> y <html>, con algunas excepciones. Aunque es recomendable es escribir los nombres de las etiquetas en minsculas ya que las nuevas generaciones del HTML estn basadas en SGML que requiere de documentos bien formados: Nombres de etiquetas y atributos en minsculas. Etiquetas de cierre para elementos no vacos.
39
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 disear y construir documentos, administrar y transferir informacin. Y es de esta posibilidad de donde naci un hbrido que se esperara fuera un nuevo estndar de internet. De la unin de estos dos lenguajes, HTML y XML es de donde naci un nuevo estndar, del cual el W3C lanz la recomendacin en el ao 2000, en un intento por regresar al HTML as motivo e idea principal que era la representacin semntica de la informacin. El W3C busc revertir lo que las empresas haban estado haciendo al tratar de convertir al HTML visual. Sin embargo el resultado nunca dej de cuajar ni ser el estndar esperado, y para el ao 2002 el grupo de trabajo en el W3C dedicado al desarrollo y bsqueda de mejoras en el XHTML dej de funcionar teniendo en puerta la recomendacin de XHTML 2.0. El desarrollo continu, sin embargo este se volvi irrelevante. Tambin en 2007 se reintento abrir el grupo encargado de XHTML 2.0 sin embargo volvi cerrar a tan solo 2 aos despus de su creacin. ESTRUCTURA DE UN DOCUMENTO HTML Todas las pginas web tienen la siguiente estructura: <html> <head> <title>Primerapgina</title> </head> <body> </body> </html> En la primera lnea encontramos la etiqueta <html>. Esta le indica al cliente que comienza un documento HTML.
40
Luego viene <head>, la cabecera, donde se pone informacin sobre el documento, que no se ve en la pantalla del navegador. Aqu puede ir el ttulo <title> del documento, es lo que veremos como ttulo de la ventana en los navegadores que lo permitan y como se conocer nuestra pgina en algunos buscadores y en la lista de favoritos de los usuarios (es importante pensar bien el ttulo del documento). Tras la cabecera viene <body>, el cuerpo, que es donde se coloca la informacin 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 navegacin web (como Internet Explorer, Mozilla Firefox o Safari) asume el formato de estilo grfico que se le intent dar para su visualizacin posterior por parte del usuario (en vez del formato de etiquetas del documento de texto/html original). La funcionalidad bsica de un navegador web es permitir la visualizacin de documentos de texto, posiblemente con recursos multimedia incrustados. Los documentos pueden estar ubicados en la computadora en donde est el usuario, pero tambin pueden estar en cualquier otro dispositivo que est conectado a la computadora del usuario o a travs de Internet, y que tenga los recursos necesarios para la transmisin de los documentos (un software Servidor web). Tales documentos, comnmente denominados pginas web, poseen hipervnculos que enlazan una porcin de texto o una imagen a otro documento, normalmente relacionado con el texto o la imagen.
41
Fig. 11. El Navegador Web Internet Explorer 8
El seguimiento de enlaces de una pgina a otra, ubicada en cualquier computadora conectada a la Internet, se llama navegacin; 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 grfico, pero slo funcionaba en estaciones NeXT. MOSAIC10 Creado por el Centro Nacional de Aplicaciones de
Supercomputacin (Universidad de Illinois, EE.UU.) fue el primer navegador que populariz el uso de la web. Cuando se public la primera versin, en 1993, el acceso a Internet todava 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]
10
HISTORIA DE LA WEB: NAVEGADORES, disponible en: [http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadores.html]
42
NETSCAPE Apareci en 1994 y hasta 1997 fue el navegador ms popular, por varios motivos: Aunque en algn 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 ms complejos Antes de 1994 las empresas de comunicacin no podan ofrecer acceso a Internet, pero en su lugar ofrecan acceso a comunidades cerradas a los clientes (la ms grande era entonces AOL, America On Line). A partir de 1994, las leyes permitieron el acceso de particulares, pero las empresas seguan sin cambiar el chip: por ejemplo hasta 1996 Microsoft no incluy en Windows un navegador web, aunque s ofreca 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 fundacin 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 ao 2000 Netscape es irrelevante. Desde 2008, el desarrollo de Netscape se dio por terminado. INTERNET EXPLORER Microsoft present Internet Explorer en agosto de 1995, basndose en una versin 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:
43
Se publicaron versiones prcticamente cada ao: 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 posicin dominante en Estados Unidos y Europa. Cada versin inclua nuevas caractersticas avanzadas, superando a Netscape en muchos aspectos. A partir del ao 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 incluan prcticamente nuevas caractersticas. En 2003, Microsoft lleg a anunciar que slo habra nuevas versiones de Internet Explorer cuando hubiera nuevas versiones de Windows. A partir de 2005, ante la aparicin 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 ms rpido: IE 7 (octubre de 2006), IE 8 (marzo de 2009) e IE 9 (marzo de 2011). Las nuevas versiones volvieron a incluir caractersticas 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 ao de IE 7, para instalarlo era necesario validar Windows, pero desde entonces esa limitacin no se ha vuelto a utilizar.
44
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 desaparicin de IE6. El 26 de octubre del 2012 Microsoft ha publicado Internet Explorer 10, incluyndolo en Windows Server 2012 y Windows 8. Actualmente (noviembre 2012) el 13 de noviembre sali una versin preliminar para Windows 7 SP1 pero no se sabe cundo se publicar la versin final. OPERA Es un navegador que comenz en 1994 como proyecto de investigacin de Telenor, una compaa telefnica Noruega, pero que desde 1995 desarrolla la compaa Opera Software. La primera versin, Opera 2.1, se public en diciembre de 1996 y desde entonces ha ido publicando versiones tanto para PCs como para dispositivos mviles. Su principal caracterstica ha sido siempre el cumplimiento de las recomendaciones del W3C (no en vano Hkon Wium Lie, uno de los padres de las hojas de estilo, pertenece a esta compaa). Hasta el ao 2000 se trataba de un navegador de pago (con versin de prueba temporal), pero desde entonces es gratuito. Nunca ha tenido una gran cuota de mercado, salvo en dispositivos mviles, donde siempre ha sido bastante utilizado (aunque la competencia importancia). MOZILLA Mozilla era el apodo del navegador Netscape dentro de la misma empresa Netscape. En enero de 1998 Netscape anunci que de Safari y Android estn reduciendo esa
45
liberaba el cdigo fuente de su navegador y el proyecto de continuar el desarrollo de ese cdigo recibi el nombre de Mozilla. Tras unos comienzos titubeantes en los que hubo que desechar gran parte del cdigo, 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 inclua tanto el navegador como el cliente de correo electrnico, 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 aos, la financiacin del proyecto provena de AOL, que utilizaba Mozilla como base para las versiones de Netscape que siguieron publicndose durante unos aos. Pero en mayo de 2003 AOL alcanz un acuerdo con Microsoft para poner fin a las demandas por abuso de posicin dominante. Microsoft pag a AOL 750 millones de dlares y, a cambio, AOL pas a utilizar Internet Explorer en vez de Netscape. AOL anunci entonces que dejara de financiar el desarrollo de Mozilla. Para poder continuar el desarrollo de Mozilla, se cre en 2004 la Mozilla Foundation, fundacin sin nimo de lucro, que recibe la mayor parte de sus ingresos de Google. De 2002 a 2004 todava 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 electrnico Firebird, etc.). Mozilla 1.7, la ltima versin de Mozilla, se public en junio de 2004 y Firefox 1.0, la primera versin 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 haca Mozilla. SeaMonkey est basada en Firefox y Thunderbird y el proyecto, aunque no forma parte de la Fundacin Mozilla, se aloja en sus Servidores. Desde 2005, el desarrollo de Mozilla se dio por terminado.
46
FIREFOX Firefox es el navegador creado por la Fundacin Mozilla y es continuacin del navegador Mozilla, que a su vez es continuacin del navegador Netscape. Firefox 1.0 se public en noviembre de 2004 y su objetivo es permitir que la web sea pblica, abierta y accesible. Adems de cumplir las recomendaciones del W3C (no solamente respecto al HTML y a CSS, sino tambin SVG o MathML), Firefox pone el nfasis en la usabilidad (pestaas, interface, etc.), facilitando adems la personalizacin y ampliacin a travs de extensiones. Es el navegador que ha conseguido acabar con la dominacin absoluta de Internet Explorer y permitir que resurja la innovacin 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 aparicin 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 ms o menos una vez al ao. 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 rpidamente a los usuarios las nuevas funcionalidades. Este modelo de desarrollo rpido crea conflictos en los entornos empresariales, en los que se utiliza una misma versin de los programas durante mucho tiempo. La solucin ofrecida ha sido crear una versin ESR (Extended Support Release), que se publicar cada siete versiones de Firefox (7x6 = 42 semanas). La primera versin ESR fue Firefox 10 y las siguientes sern Firefox 17, Firefox 24, etc. El tiempo dir si este plazo, inferior a un ao, es adecuado para los entornos empresariales. Este modelo de desarrollo rpido tambin crea conflictos para los creadores de extensiones, ya que los cambios internos de cada versin pueden hacer que cualquier extensin deje de funcionar.
47
Este problema se agravaba en las primeras versiones porque Firefox supona que las extensiones eran incompatibles si no se haban 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 travs de donaciones a la Fundacin Mozilla. A cambio, la pgina de inicio inicial de Firefox es la pgina 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 dispona de su propio navegador web, sino que inclua 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 ao (en los ltimos aos 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 rpido, aunque no se publica a intervalos regulares, como Firefox. La versin 1.0 se public en diciembre de 2008, actualmente (Noviembre de 2012) 6 de noviembre de 2012 ya va por la versin 23. Ha destacado siempre por su interfaz minimalista y por la velocidad de ejecucin del cdigo JavaScript, lo que oblig a Firefox y a Internet Explorer a mejorar estos aspectos.
48
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 tcnicamente posible que el navegador se convierta en la nica aplicacin del ordenador, con todos los datos en Internet y las aplicaciones ejecutndose en HTML5 y JavaScript. Otros recuerdan que ms o menos esa fue ya la promesa de Java hace 15 aos, que no se cumpli. En cualquier caso, los prximos aos prometen ser apasionantes. 2.2.2.2.5. LA GUERRA DE LOS NAVEGADORES11 En 1994, la primera versin del navegador Netscape sali al mercado, escrita por los inventores del navegador Mosaic. En 1996, se introdujo Netscape 2 con nuevas caractersticas: frames y JavaScript. Con Netscape 3 JavaScript 1.1 se volvi un estndar,
estandarizado por la ECMA (European Computer Manufacturers Association) como ECMAScript. En 1997 se estableci DHTML (Dynamic HTML) con la salida de Netscape 4. Este inclua ms etiquetas HTML y partes del estndar de la W3C (World Wide Web Consortium) CSS 1 (Cascading Style Sheets). En combinacin con CSS 2 y JavaScript 1.2 se poda modificar la posicin, estilo y visibilidad de una pgina. En 1997 apareci el concepto de layer (capa) introducido por el navegador Microsoft Internet Explorer 4 que inclua muchas caractersticas no estndar para competir con su rival Netscape Navigator. Los aos posteriores las tecnologas citadas anteriormente se convirtieron ms avanzadas. Microsoft Internet Explorer fue incluido directamente como parte del sistema operativo Microsoft Windows, convirtindose de esta manera en el navegador ms utilizado.
11
FLORIAN MORITZ, Rich Internet Applications (RIA):A Convergence of User Interface Paradigms of Web and Desktop Exemplified, 2008
49
Cada
navegador,
Netscape
Internet
Explorer,
utilizaban
tecnologas diferentes, las cuales no estaban estandarizadas e implementaban incorrectamente los estndares establecidos. Esta falta de estandarizacin haca la programacin para los
desarrolladores web difcil. El ao 2000 con la salida de Opera 4 nace el primer navegador que cumple los estndares de la W3C. En el ao 2001 se libera Internet Explorer 6, pero su soporte CSS era inferior comparado al Motor Gecko. El motor Gecko es un motor de disposicin para el manejo de HTML y CSS, el cual fue publicado el 2002. Basado en este motor apareci un proyecto Open Source denominado Mozilla. Ms tarde el grupo Mozilla produjo el navegador Mozilla Firefox con mucho xito. Otro navegador importante es Safari, desarrollado por Apple Inc.; tambin 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 aos, hasta el 2006, ao en el que libera Internet Explorer 7, esta versin implementa mejoras en funcionalidad, estabilidad y compatibilidad entre aplicaciones que usan CSS. El 2009 lanza Internet Explorer 8. El 2009 tambin fue lanzada La versin 3.5 de Mozilla Firefox (antes numerada como la versin 3.1). Es compatible con la etiqueta <video> cmo define la especificacin HTML 5; en el cual incluye compatibilidad nativa con los cdecs libres OggTheora y OggVorbis. Esta versin incluye caractersticas que no pudieron ser desarrolladas a tiempo para Firefox 3. 2.2.2.2.6. FUNCIONAMIENTO La gran mayora de los navegadores cuentan con un campo de direccin donde el usuario escribe las direcciones web, que vendran a ser las Lneas de Peticin en formato HTTP, al presionar la tecla Enter activan el hiperenlace (que activa el agente de usuario o navegador). La primera accin tomada por el
50
navegador es la resolucin DNS del nombre de dominio a su direccin IP equivalente. Una vez que la direccin ha sido resuelta el navegador establece una conexin TCP a esta direccin 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 interacta con los hiperenlaces del documento, un nuevo proceso comienza nuevamente que involucra al DNS, TCP/IP y HTTP12 La mayora de los navegadores soportan otros protocolos como FTP, Gopher y HTTPS (una versin cifrada de HTTP basada en Secure Socket Layer o Capa de Conexin Segura (SSL)). A pesar de que la funcin 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 imgenes, sonidos e incluso
vdeos streaming en diferentes formatos y protocolos. Adems, permiten almacenar la informacin en el disco o
crear marcadores (bookmarks) de las pginas ms visitadas. Los primeros navegadores web slo soportaban una versin muy simple de HTML. El rpido desarrollo de los navegadores web propietarios condujo al desarrollo de dialectos no estndares de HTML y a problemas de interoperabilidad en la web. Los ms modernos (como Amaya, Mozilla, Netscape, Opera y versiones recientes de Internet Explorer) soportan los estndares HTML y XHTML (comenzando con HTML 4.01, los cuales deberan visualizarse de la misma manera en todos ellos)13 Actualmente el navegador ms utilizado en el mundo es Google Chrome, seguido en esta clasificacin por Internet Explorer y Mozilla Firefox segn los datos de Statcounter.
12
MARTIN P. CLARK. DATA NETWORKs, IP and the Internet: Protocols, Design and Operation. John Wiley& Sons, Ltd., 2003 : 479 NAVEGADORES WEB, Disponible en: [http://es.wikipedia.org/wiki/Navegador_web]
13
51
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 travs 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 ms tarde son compiladas o interpretadas por el Servidor de aplicaciones que genera una salida HTML la cual es mostrada por el navegador.
52
Fig. 13. Ejemplo de una aplicacin 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 haban dado cuenta an sobre el qu hacer con este nuevo canal. De hecho, al comienzo de la World Wide Web, las pginas web corporativas frecuentemente mostraban solo informacin de contacto y alguna documentacin. Sin embargo, no paso mucho tiempo para que los usuarios web desearan una experiencia mucho ms dinmica, en la cual el contenido de las pginas cambia de acuerdo al tiempo, a las preferencias del usuario y miles de otros atributos. El paso inmediatamente posterior en la evolucin de las aplicaciones web fue la inclusin de un mtodo para elaborar pginas dinmicas que permitieran que lo mostrado tuviese carcter dinmico (es decir, generado a partir de los datos de la solicitud).
53
2.2.2.5. COMMON GATEWAY INTERFACE(CGI)14 Brindaba los mecanismos necesarios para generar contenido dinmico 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 enva una solicitud como si fuera para una pgina HTML. El Servidor web reconoce que el recurso solicitado corresponde a un programa externo. El Servidor web ejecuta el programa externo, pasndole a este la solicitud HTTP recibida del navegador del usuario. El programa externo realiza el procesamiento y enva los resultados (HTML) al Servidor. El Servidor web enva 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 generacin de contenido dinmico. Sin embargo a medida que la Web creca en popularidad, el trfico hacia los sitios web tambin creca. Debido a muchas deficiencias CGI no era suficiente para soportar esa carga. Afortunadamente con el paso de los aos surgieron muchas alternativas de solucin a CGI, que resolvan sus limitaciones. En la actualidad aunque existen muchas variaciones posibles, una aplicacin web est normalmente estructurada como una aplicacin de tres-capas. En su forma ms comn, el navegador web ofrece la primera capa; un motor capaz de usar alguna tecnologa web dinmica (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
54
El navegador web manda peticiones a la capa de intermedia que ofrece servicios valindose 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 ejecucin de Servlets, combina la funcionalidad bsica de un Servidor web con un ambiente de ejecucin Java y se encarga de gestionar el ciclo de vida de cada Servlet que tiene registrado. Provee de un ambiente de ejecucin para todos los Servlets en el Servidor. 2.2.2.2.8. JAVA SERVLETS16 . En el mundo Java, los Servlets fueron diseados 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 dinmica. Adicionalmente definen un ciclo de vida eficiente que maneja de manera ptima las solicitudes. Los Servlets sirven de base para otras tecnologas 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 envindolas 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 creacin de contenido dinmico, Sun introdujo JSP (Java Server Pages). Una pgina JSP en realidad cuando es procesada por un ServletContainer es convertida en un
15 16
DEFINICIN DE SERVLETCONTAINERS, Disponible en: [http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers]
JAYSON FALKNER, KEVIN JONES, Servlets and Java Server Pages: The J2EE Technology Web Tier. Addison Wesley, 2003
55
Servlet que luego es ejecutado por este. Pero a diferencia de los Servlets una pgina JSP puede contener cdigo HTML a manera de una pgina web tradicional y tambin elementos especiales JSP que permiten insertar contenido dinmico en la pgina. 2.2.2.7. ASP NET17 Es un componente central de Microsoft .NET Framework18 y
proporciona la infraestructura para aplicaciones Web .NET dinmicas desarrolladas fcilmente. ASP.NET no slo 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 caractersticas nuevas. ASP.NET est construido sobre el Common Language Runtime19, permitiendo a los programadores escribir cdigo 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 comn y, por tanto, reducir la cantidad de cdigo que el desarrollador tiene que escribir, la habilidad de los desarrolladores para estructurar de forma clara las pginas en un estilo ordenado, y la habilidad de las herramientas de desarrollo de proporcionar un potente soporte de diseo WYSIWYG20 para las pginas.
17 18
DEFINICIN DE ASP.NET ,Disponible en: [http://support.microsoft.com/?scid=kb;es;305140]
NET FRAMEWORK :es el modelo de programacin de cdigo administrado de Microsoft para la creacin de aplicaciones en clientes de Windows, Servidores y dispositivos mviles 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 ejecucin que ejecuta el cdigo 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). Trmino utilizado para describir un sistema en el cual el contenido mostrado durante la edicin es muy similar al resultado final. [http://en.wikipedia.org/wiki/WYSIWYG]
56
2.2.2.8. PHP21
Es un lenguaje interpretado de propsito general ampliamente usado y que est diseado especialmente para desarrollo web y puede ser incrustado dentro de cdigo HTML. Generalmente se ejecuta en un Servidor web, tomando el cdigo en PHP como su entrada y creando pginas web como salida. El gran parecido que posee PHP con los lenguajes ms comunes de programacin estructurada, como C y Perl, permiten a la mayora de los programadores crear aplicaciones web con una curva de aprendizaje muy corta. Cuando el cliente hace una peticin al Servidor para que le enve una pgina web, el Servidor ejecuta el intrprete de PHP. Este procesa el script solicitado que generar el contenido de manera dinmica (por ejemplo obteniendo informacin de una base de datos). El resultado es enviado por el intrprete al Servidor, quien a su vez se lo enva al cliente. 2.2.2.9. COLDFUSION Adobe Coldfusion es un Servidor de aplicaciones y un lenguaje de programacin usado para desarrollar aplicaciones de Internet, generalmente sitios web generados dinmicamente. En este aspecto, es un producto similar a ASP.NET, JSP o PHP. Las partes dinmicas de una pgina ColdFusion son generadas insertando elementos de marcado similares a HTML o XML en una pgina 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 programacin, as como etiquetas para realizar tareas de acceso a base de datos, archivos, correo, generacin de PDF, etc.
21
DEFINICIN DE PHP , disponible en: [http://es.wikipedia.org/wiki/PHP]
57
Coldfusion es una aplicacin web Java, que se puede desplegar sobre un contenedor de Servlets o un Servidor de Aplicaciones Java JEE, tambin posee un Servidor JEE incorporado denominado JRun.
2.2.4.
TECNOLOGIAS DEL LADO DEL CLIENTE22

Todo comenz con una simple versin de HTML propuesta para crear la estructura bsica de pginas web, organizar su contenido y compartir informacin. El lenguaje y la web misma nacieron principalmente con la intencin de comunicar informacin por medio de texto. El limitado objetivo de HTML motiv a varias compaas a desarrollar nuevos lenguajes y programas para agregar caractersticas 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 ms exitosas; ambas fueron masivamente adoptadas y ampliamente consideradas como el futuro de Internet. Sin embargo, tan pronto como el nmero de usuarios se increment e Internet pas de ser una forma de conectar amantes de los ordenadores a un campo estratgico para los negocios y la interaccin social, limitaciones presentes en estas dos tecnologas probaron ser una sentencia de muerte. El mayor inconveniente de Java y Flash puede describirse como una falta de integracin. 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 exista comunicacin e integracin alguna entre aplicaciones y documentos. La falta de integracin result ser crtica y prepar el camino para la evolucin 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.
58
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, despus de algunos aos de intentos fallidos para promoverlo y algunos malos usos, el mercado nunca lo adopt plenamente y pronto su popularidad declin. Los detractores tenan buenas razones para oponerse a su adopcin. 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 reproduccin de video se estaban convirtiendo en una parte esencial de la web y solo eran efectivamente ofrecidas a travs de estas tecnologas. A pesar del suceso inicial, el uso de Java comenz a declinar. La naturaleza compleja del lenguaje, su evolucin lenta y la falta de integracin disminuyeron su importancia hasta el punto en el que hoy da no es ms usado en aplicaciones web de importancia. Sin Java, el mercado volc su atencin a Flash. Pero el hecho de que Flash comparte las mismas caractersticas bsicas que su competidor en la web lo hace tambin 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 tcnicas rpidas de acceso a la red, los navegadores tambin mejoraron gradualmente sus intrpretes JavaScript. Ms potencia trajo ms 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 podran proveer las herramientas que ellos necesitaban para crear las aplicaciones demandadas por un nmero 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 innovacin y los increbles resultados obtenidos llamaron la atencin de ms programadores. Pronto lo que fue llamado la "Web 2.0" naci y la percepcin de JavaScript en la comunidad de programadores cambi
59
radicalmente. JavaScript era claramente el lenguaje que permita a los
desarrolladores innovar y hacer cosas que nadie haba podido hacer antes en la web. En los ltimos aos, programadores y diseadores web alrededor del mundo surgieron con los ms increbles trucos para superar las limitaciones de esta tecnologa y sus iniciales deficiencias en portabilidad. Gracias a estas nuevas implementaciones,
JavaScript, HTML y CSS se convirtieron pronto en la ms perfecta combinacin que pronto seria llamada HTM5, quien terminara 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 pgina web. Cuando un navegador carga una pgina 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 pgina web en su navegador. El navegador que carga y ejecuta el Applet se conoce en trminos genricos como el "contenedor" de los Applets. El kit de desarrollo de software para Java Standard Edition 7 (1.7.1 --Versin ms 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 pgina web. Los Applet java pueden hacer uso de diferentes tecnologas creadas para el renderizado de interfaz grfica como AWT, Swing y JavaFX. As como tambin las diferentes implementaciones de formatos de socializacin de datos para comunicacin con el Servidor, como Json, Json-RPC, Xml-Rpc, etc.
23 24
DEFINICIN DE APPLET JAVA, disponible en [http://es.wikipedia.org/wiki/Applet_Java] DEFINICIN DE APPLET, disponible en [ http://es.wikipedia.org/wiki/Applet]
60
2.2.4.1.1.
AWT25 La Abstract Window Toolkit (AWT, en espaol Kit de Herramientas de Ventana Abstracta) es un kit de herramientas de grficos, 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 estndar para suministrar una interfaz grfica de usuario (GUI) para un programa Java. Cuando Sun Microsystems liber Java en 1995, AWT suministr solo un nivel de abstraccin muy fino sobre la interfaz de usuario nativa subyacente. Por ejemplo, crear una caja de verificacin AWT causara que AWT directamente llame a la subrutina nativa subyacente que cree una caja de verificacin. Sin embargo, una caja de verificacin en Microsoft Windows no es exactamente lo mismo que una caja de verificacin 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 integracin con las aplicaciones nativas. En otras palabras, un programa GUI escrito usando AWT parece como una aplicacin nativa Microsoft Windows cuando se ejecuta en Windows, pero el mismo programa parece una aplicacin 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 grfica para el lenguaje de programacin Java desarrollada originalmente por Netscape y que se public en 1996.
25
DEFINICIN DE AWT, Disponible en:[http://es.wikipedia.org/wiki/Abstract_Window_Toolkit] DEFINICIN DE SWING, Disponible en:[ http://es.wikipedia.org/wiki/Swing_(biblioteca_grfica])
26
61
Desde sus inicios el entorno Java ya contaba con una biblioteca de componentes grficos conocida como AWT. Esta biblioteca estaba concebida como una API estandarizada que permita utilizar los componentes nativos de cada sistema operativo. Entonces una aplicacin Java corriendo en Microsoft Windows usara el botn estndar de Windows y una aplicacin corriendo en UNIX usara el botn estndar de Motif. En la prctica esta tecnologa no funcion: Al depender fuertemente de los componentes nativos del sistema operativo el programador AWT estaba confinado al mximo denominador comn entre ellos. Es decir que slo se disponen en AWT de las funcionalidades comunes en todos los sistemas operativos. El comportamiento de los controles vara mucho de sistema a sistema y se vuelve muy difcil construir aplicaciones portables. Fue por esto que el eslogan de Java "Escrbalo una vez, ejectelo en todos lados" fue parodiado como "Escrbalo una vez, prubelo en todos lados". En cambio, los componentes de IFC eran mostrados y controlados directamente por cdigo 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. Adems al estar enteramente desarrollado en Java aumenta su portabilidad asegurando un comportamiento idntico en diferentes plataformas. En 1997, Sun Microsystems y Netscape Communications
Corporation anunciaron su intencin de combinar IFC con otras tecnologas de las Java Foundation Classes. Adems de los componentes ligeros suministrados originalmente por la IFC, Swing introdujo un mecanismo que permita que el aspecto de cada componente de una aplicacin pudiese cambiar sin introducir cambios sustanciales en el cdigo de la aplicacin. La introduccin 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. Tambin contiene un
62
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 compaa SeeBeyond, en la que un ingeniero de software de nombre de Chris Oliver cre un lenguaje rico en grficos de secuencias de comandos conocido como F3 (Form Follows Function). F3 lenguaje que ms tarde fue presentado por Sun Microsystems como JavaFX en la conferencia JavaOne 2007. Posteriormente Oracle Corporation anunci la adquisicin de Sun Microsystems, con lo que Oracle se convirti en el nuevo administrador de JavaFX, la misma que volvi a crear esta tecnologa desde cero, basada en el lenguaje java eliminando de esta manera el lenguaje de script JavaFX. Con estos cambios JavaFX se convertira en la prxima generacin de herramientas para el desarrollador y construccin de
aplicaciones multiplataforma con interfaces grfica enriquecidas de usuario (GUI), Proporciona a travs de grficos acelerados por hardware y diseo de interfaces de programacin que permiten a los desarrolladores combinar grficos, animaciones, y los controles de interfaz de usuario. JavaFX 2.0 API puede ser utilizado por los diferentes lenguajes que ejecutan en la mquina virtual Java (Visage, Jython, Groovy, JRuby, y Scala). 2.2.4.2. AJAX27 AJAX es acrnimo de Asynchronous JavaScript and XML. El elemento clave es su naturaleza asncrona. En pocas palabras, AJAX es una tcnica para realizar llamadas asncronas 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.
63
actualizando porciones de la pgina web sin provocar refrescos de pgina. AJAX permite la comunicacin entre el cliente y el Servidor mientras el usuario est utilizando la pgina web. Es necesario enfatizar que AJAX es una tcnica del lado del cliente, trabaja con cualquier tecnologa del lado del Servidor. Junto con JavaScript, se necesita cierta familiaridad con otras tecnologas como HTML, DOM y CSS. Estas tecnologas son implementadas por todos los navegadores web de hoy en da, 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 pgina HTML. El objeto XMLHttpRequest, que permite realizar llamadas asncronas al Servidor en segundo plano mediante JavaScript. A excepcin de aplicaciones simples, se requiere de una tecnologa del lado del Servidor que recepcionen las solicitudes del lado del cliente JavaScript. El cdigo del cliente JavaScript y el cdigo del lado del Servidor requieren de una manera de pasar datos y recibirlos respectivamente. El objeto XMLHttpRequest permite enviar valores utilizando
solicitudes HTTP mediante mtodos GET y POST. Por lo cual es muy fcil interpretar estos datos con cualquier script del lado del Servidor. El script del lado del Servidor enva 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 prctica, se requerir de un formato de datos que pueda ser usado para pasar datos estructurados. Los 2 formatos de datos ms populares utilizados en aplicaciones AJAX son XML y JSON (JavaScript Object Notation).
64
INTERACCION AJAX DE EJEMPLO

Aplicacin Web AJAX
3
XMLHttpRequest
5
function callback(){ //actualizar interfaz }
Script de lado del servidor
Evento
Cliente Servidor
Figura 14: Interaccin en una aplicacin 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 accin especfica del usuario. Con un cdigo como el siguiente:
<input type = text id=email name=email onblur=validateEmail();>
2. Una instancia del objeto XmlHttpRequest es creada. Usando el mtodo open, la llamada se configura. El URL con el mtodo HTTP correspondiente, tpicamente GET o POST. La solicitud es generada llamando al mtodo 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;
65
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 funcin 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. Tpicamente estas llamadas se centralizan en una librera que ser utilizada por la aplicacin web, o se utilizara una de las tantas disponibles en la actualidad. En general estos frameworks se encargan de las funcionalidades bsicas e interacciones con el navegador, otras agregan componentes JavaScript para la interfaz de usuario. 2.2.4.3. ADOBEFLEX28 En su versin ms 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 aos de existencia, la mayora de elementos desarrollados para este eran animaciones y elementos visuales creados en su mayora por diseadores. 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 programacin. Desde su segunda versin (Adobe Flex 2) brinda un
28
FLASH BUILDER 4 AND FLEX 4 BIBLE ,David Gassne. Wiley Publishing, 2010.
66
mbito de trabajo similar a herramientas existentes como Visual Studio, Delphi, y JBuilder. El desarrollador escribe cdigo (El lenguaje utilizado es ActionScript 3) lo compila localmente y luego sube la aplicacin 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 ejecucin basado en navegadores y multiplataforma que ofrece una
visualizacin sin compromiso de aplicaciones expresivas, contenido y vdeos en diferentes pantallas y exploradores. Flash Player 10.1 est optimizado para un alto rendimiento en pantallas de dispositivos mviles y est diseado para aprovechar las funciones nativas del dispositivo, permitiendo experiencias de usuario ms profundas y envolventes. El resultado de compilar una aplicacin 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 aplicacin del archivo SWF. Una de las principales ventajas del Adobe Flash Player es su gran nivel de penetracin en la Web. Cada nueva versin de este ha alcanzado una tasa rpida de crecimiento de instalacin con respecto a versiones previas. A junio del 2010, la tasa de penetracin de las versiones 7, 8 y 9 fueron del 99%, y la versin 10 del Flash Player ya tiene una tasa de penetracin 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:
67
ActionScript 3. La versin ms reciente del lenguaje que evolucion a lo largo del ciclo de vida del Adobe Flash Player hasta convertirse en un lenguaje de programacin completo, orientado a objetos. MXML. Un lenguaje basado en XML que se utiliza para definir una aplicacin Flex y sus componentes. Muchos de los elementos en MXML tienen sus clases equivalentes en ActionScript 3 y forman parte de la librera de clases Flex. FXG. Un lenguaje basado en XML que permite representar objetos grficos como marcado XML. Este lenguaje es soportado por herramientas de Adobe como Illustrator, Photoshop y Fireworks para permitir exportar objetos grficos hacia Adobe Flex. Cuando una aplicacin es compilada, el cdigo MXML es interpretado y se genera su correspondiente cdigo en ActionScript 3, lo cual hace que sea ms fcil definir partes de la aplicacin en MXML, que escribirlas completamente en ActionScript 3. Se puede utilizar MXML y ActionScript de manera intercambiable en muchas situaciones. MXML se usa comnmente para definir la disposicin de los elementos visuales de la aplicacin. 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 librera de clases implementada en ActionScript 3 que comprende la mayora de componentes visuales, animacin, servicios de datos y otros que forman parte del framework: Controles de manejo de formularios. Controles de mens. Componentes de audio y video. Contenedores de disposicin de elementos visuales. Componentes de datos.
68
Formateadores y validadores. Manejo de cursor. Manejo de estado. Efectos. Animacin. Manejo de historial. Componentes de arrastrar y soltar. Administracin de estilos. Tambin 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 visualizacin de datos y otros controles visuales avanzados. Herramientas de optimizacin 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 diseo, depuracin y despliegue de estas.
69
ADOBE FLEX 4
Herramientas de Desarrollo
Flex 4 SDK (Gratuito)
Flash Builder 4 (Comercial)
Lenguajes
MXML y FXG (Basados en XML)
ActionScript 3
Entornos de ejecucin
Flash Player (Web)
AIR (Escritorio)
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 tecnologa 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 ejecucin de contenido enriquecido en la web. Una aplicacin 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 versin especfica del Common Language Runtime (CLR). Un gran beneficio, ya que contiene una versin recortada de la Base Class Library (BCL) de .NET, en total el plugin de Silverlight tiene un tamao de 5 MB.
29
SHANNON HORN, Microsoft Silverlight 3: A Beginners Guide, McGraw Hill, 2010.
70
2.2.4.4.4.
FUNDAMENTOS WINDOWS PRESENTATION FOUNDATION (WPF) Es una versin rediseada y mejorada de las tecnologas .NET utilizadas para crear aplicaciones Windows, trabajar con grficos, crear animaciones e incrustar medios. Las tecnologas Windows Forms (para ventanas y formularios Windows) y GDI+ (para manipulacin de grficos) seguirn siendo soportadas por Microsoft y pueden ser an utilizadas, pero carecen de muchas de las bondades disponibles en WPF. EXTENSIBLE (XAML) Es un lenguaje basado en XML creado para su utilizacin en WPF. Su propsito principal es la definicin de interfaces grficas y elementos visuales. Un archivo XAML es utilizado para definir componentes visuales y su ubicacin en la aplicacin. Un intrprete lee el archivo XAML y genera el cdigo 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 tambin extiende y utiliza muchas de las funcionalidades de ASP.NET AJAX. Al ser diseada 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 versin 5.1 Desde sus inicios las distintas versiones fueron evolucionando de la siguiente manera: La versin 1.0 fue lanzada en el 2007, e inclua las siguientes funcionalidades: Grficos y animacin. APPLICATION MARKUP LANGUAGE
71
Audio y video en formatos MP3 y Windows Media Video (WMV).
Imgenes en formato JPG y PNG. Utilizacin del Document Object Model (DOM) usando JavaScript.
Silverlight 2 fue lanzado en septiembre del 2008, agregaba las siguientes funcionalidades: Soporte de cdigo administrado, en C#, Visual Basic, IronPython e IronRuby. Controles de interfaz de usuario Acceso a datos mejorado.
Silverlight 3, lanzado en marzo del 2009, aada las siguientes funcionalidades: Soporte para validacin de datos en los controles visuales. Soporte nativo de hojas de estilo. Soporte de libreras de recursos externos. Soporte de modo desconectado. Se incluyeron muchos ms controles visuales. Se mejor el sistema de animaciones, agregando ms efectos visuales. 2.2.4.4.5. Aceleracin de grficos por GPU.
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 diseo de contenido visual, la edicin de cdigo XAML, la depuracin y despliegue de aplicaciones Silverlight. Debido a que la 4ta versin del producto (Silverlight 4) fue lanzada
posteriormente a Visual Studio 2010, Silverlight 4 se lanz tambin con Silverlight 4 Tools for Visual Studio 2010, la
72
cual actualiza Visual Studio para desarrollar aplicaciones RIA Silverlight utilizando esta ltima versin. MICROSOFT EXPRESSION STUDIO 4 Es un conjunto de herramientas graficas dirigidas a diseadores para la creacin de contenido grfico, 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 creacin de interfaces grficas basadas en XAML, as como la creacin de animaciones y contenido interactivo. b) MICROSOFT EXPRESSION DESIGN. Herramienta de diseo grfico. c) MICROSOFT EXPRESSION MEDIA. Herramienta de administracin de medios de audio y video, edicin, conversin de formatos y su despliegue en aplicaciones WPF. 2.2.4.5. HTML5 HTML5 (Hyper Text Markup Language, versin 5) es la quinta revisin importante del lenguaje bsico de la World Wide Web, HTML. HTML5 especifica dos variantes de sintaxis para HTML: un clsico 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 ms que una tecnologa viene hacer un conjunto de especificacin para el conjunto de tecnologas HTML, JavaScript Y CSS. HTML5 propone estndares para cada aspecto de la web y tambin un propsito claro para cada una de las tecnologas involucradas. A partir de ahora, HTML provee los elementos estructurales, CSS se encuentra concentrado en cmo 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.
73
2.2.4.5.1.
NUEVOS ELEMENTOS30 Estructura: section: Una parte o captulo de un libro, seccin de un captulo, o esencialmente cualquier cosa que tenga su propio encabezado en HTML 4. header: El encabezado de la pgina; no es lo mismo que el tag HEAD. footer: El pie de pgina, donde van las letras chicas, copyright, emails, etc. nav: Una coleccin de links a otras pginas. article: Una entrada independiente en un blog, revista, compendio o lo que sea. Bloques semnticos: 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 ttulo. dialog: Un elemento dilogo representa una conversacin entre diferentes personas. El elemento dt seala al que habla y dd seala el discurso. Inlines semnticos: m (mark): Indica que el texto est marcado de alguna manera pero no necesariamente enfatizado. Por ejemplo, una pgina resaltada en un libro, o en google cache cuando resalta los trminos buscados. time: Bastante lgico, representa una fecha. meter: Representa un valor numrico en un rango especificado. progress: Representa el estado de un proceso en ejecucin, 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=dgrlnxw01NewHTML]
74
Multimedia embebida: audio y video: Como sus nombres dicen, son para embeber audio y video. La sintaxis es prcticamente la del viejo y querido tag IMG. Interactivos: details: Representa informacin adicional que podra 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 versin 2 de HTML. Fue deprecado en la versin 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 aplicacin 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 comunicacin bidireccional entre pginas. Similar a los Sockets de C. WebWorkers. Hilos de ejecucin en paralelo. ESTNDAR FUTURO. SystemInformation API. Acceso al hardware a bajo nivel: red, ficheros, CPU, memoria, puertos
31
DEFINICIN HTML5, Disponible en:[ http://es.wikipedia.org/wiki/HTML5]
75
USB, cmaras, micrfonos, etc. muy interesante pero con numerosas salvedades de seguridad.
2.2.5.
FREMEWORK
La palabra inglesa "framework" define, en trminos generales, un conjunto estandarizado de conceptos, prcticas y criterios para enfocar un tipo de problemtica 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 tecnolgica de soporte definido, normalmente con artefactos o mdulos de software concretos, con base a la cual otro proyecto de software puede ser ms fcilmente organizado y desarrollado. Tpicamente, 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 metodologa de trabajo, la cual extiende o utiliza las aplicaciones del dominio.
2.2.6.
PATRON DE DISEO32
Segn Christopher Alexander, cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, as como la solucin a ese problema, de tal modo que se pueda aplicar esta solucin un milln de veces, sin hacer lo mismo dos veces . Aunque Alexander se refera a patrones en ciudades y edificios, lo que dice tambin es vlido para patrones de diseo orientados a objetos. Nuestras soluciones se expresan en trminos de objetos e interfaces, en vez de paredes y puertas, pero en la esencia de ambos tipos de patrones se encuentra una solucin a un problema dentro de
32
PATRONES DE DISEO (Elementos de software orientado a objetos reutilizables),Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
76
un contexto. En general, un patrn tiene cuatro elementos esenciales: El nombre del patrn permite describir, en una o dos palabras, un problema de diseo junto con sus soluciones y
consecuencias. Al dar nombre a un patrn inmediatamente estamos incrementado nuestro vocabulario de diseo, lo que nos permite disear con mayor abstraccin. Tener un vocabulario de patrones nos permite hablar de ellos con otros colegas, mencionarlos en nuestra documentacin y tenerlos nosotros mismos en cuenta. De esta manera, resulta ms fcil pensar en nuestros diseos y transmitirlos a otros, junto con sus ventajas e inconvenientes. Encontrar buenos nombres ha sido una de las partes ms difciles al desarrollar nuestro catlogo. El problema describe cundo aplicar el patrn. Explica el problema y su contexto. Puede describir problemas concretos de diseo (por ejemplo, cmo representar algoritmos como objetos), as como las estructuras de clases u objetos que son sintomticas de un diseo inflexible. A veces el problema incluye una serie de condiciones que deben darse para que tenga sentido aplicar el patrn. La solucin describe los elementos que constituyen el diseo, sus relaciones, responsabilidades y colaboraciones. La
solucin no describe un diseo o una implementacin en concreto, sino que un patrn es ms bien como una plantilla que puede aplicarse en muchas situaciones diferentes. El patrn proporciona una descripcin abstracta de un problema de diseo y cmo lo resuelve una disposicin general de elementos (en nuestro caso, clases y objetos). Las consecuencias son los resultados as como las ventajas e inconvenientes de aplicar el patrn. Aunque cuando se describen decisiones de diseo muchas veces no se reflejan sus consecuencias, stas son fundamentales para evaluar las
77
alternativas de diseo y comprender los costes y beneficios de aplicar el patrn. Las consecuencias en el software suelen referirse al equilibrio entre espacio y tiempo. Tambin pueden tratar cuestiones de lenguaje e implementacin. Por otro lado, puesto que la reutilizacin suele ser uno de los factores de los diseos orientados a objetos, las consecuencias de un patrn incluyen su impacto sobre la flexibilidad, extensibilidad y portabilidad de un sistema. Incluir estas consecuencias de un modo explcito nos ayudar a comprenderlas y evaluarlas.
2.2.6.1. OBJETIVOS33
Proporcionar catlogos de elementos reusables en el diseo de sistemas software. Evitar la reiteracin en la bsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario comn entre diseadores. Estandarizar el modo en que se realiza el diseo. Facilitar el aprendizaje de las nuevas generaciones de diseadores condensando conocimiento ya existente. Asimismo, no pretenden: Imponer ciertas alternativas de diseo frente a otras. Eliminar la creatividad inherente al proceso de diseo. No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrn, 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 DISEO, Disponible en:[http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o]
78
2.2.6.2. CATEGORAS DE PATRONES34 Segn la escala o nivel de abstraccin: Patrones de arquitectura: Aquellos que expresan un
esquema organizativo estructural fundamental para sistemas de software. Patrones de diseo: Aquellos que expresan esquemas para definir estructuras de diseo (o sus relaciones) con las que construir sistemas de software. Dialectos: Patrones de bajo nivel especficos para un lenguaje de programacin o entorno concreto. 2.2.6.3. RELACIN 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 travs de la clonacin. 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 clonacin. El proceso de clonacin se inicia instanciando un tipo de objeto de la clase que queremos clonar. 2. Abstract Factory (fbrica 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 creacin de un objeto complejo, centralizando dicho proceso en un nico punto. 4. Factory Method (mtodo de fabricacin): centraliza en una clase constructora la creacin de objetos de un subtipo
34 35
CATEGORA DE PATRONES, Disponible en:[http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o] RELACIN DE PRINCIPALES PATRONES DE DISEO, Disponible en:[http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o]
79
de un tipo determinado, ocultando al usuario la casustica, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear. 5. Prototype (prototipo): crea nuevos objetos clonndolos de una instancia ya existente. 6. Singleton (instancia nica): garantiza la existencia de una nica instancia para una clase y la creacin 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 podra utilizarla. 2. Bridge (Puente): implementacin. 3. Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase. 4. Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente. 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 idntica informacin. 7. Proxy: Mantiene un representante de un objeto. 8. Mdulo: Agrupa varios elementos relacionados, como clases, singletons, y mtodos, utilizados globalmente, en una entidad nica. 2.2.6.3.3. Patrones de comportamiento 1. Chain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Desacopla una abstraccin de su
80
2. Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma. 3. Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo. 4. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementacin de estos. 5. Mediator (Mediador): Define un objeto que coordine la comunicacin 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-amuchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automticamente 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 mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin. 10. Template Method (Mtodo plantilla): Define en una operacin 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 jerarqua de clases sin modificar las clases sobre las que opera.
81
2.2.6.4. MODELO VISTA CONTROLADOR (MVC)36 Es un patrn o modelo de abstraccin de desarrollo de software que separa los datos de una aplicacin, la interfaz de usuario, y la lgica de negocio en tres componentes distintos. El patrn de llamada y retorno MVC (segn CMU), se ve frecuentemente en aplicaciones web, donde la vista es la pgina HTML y el cdigo que provee de datos dinmicos a la pgina. El modelo es el Sistema de Gestin de Base de Datos y la Lgica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista. Modelo: Esta es la representacin especfica de la informacin 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 tambin puede operar con ms datos no relativos a la presentacin, haciendo uso integrado de otras lgicas 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 informticos utilizan un Sistema de Gestin de Base de Datos para gestionar los datos: en lneas generales del MVC corresponde al modelo. La unin entre capa de presentacin y capa de negocio conocido en el patrn de la Programacin por capas representara la integracin entre Vista y su correspondiente Controlador de eventos y acceso a datos, MVC no pretende discriminar entre capa de negocio y capa de presentacin pero si pretende separar la capa visual grfica de su correspondiente programacin 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
DEFINICIN DE PATRN MODELO VISTA CONTROLADOR, Disponible en:[http://es.wikipedia.org/wiki/Modelo_Vista_Controlador]
82
Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: El usuario interacta con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botn, enlace, etc.) El controlador recibe (por parte de los objetos de la interfazvista) la notificacin de la accin solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a travs de un gestor de eventos (handler) o callback. El controlador accede al modelo, actualizndolo, posiblemente modificndolo de forma adecuada a la accin solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos estn a menudo estructurados usando un patrn de comando que encapsula las acciones y simplifica su extensin. 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 podra utilizar el patrn Observador para proveer cierta indireccin 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 patrn Observador no es posible en las aplicaciones Web puesto que las clases de la vista estn 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 enve los datos del modelo a la vista. Por ejemplo en el MVC usado por Apple
83
en su framework Cocoa. Suele citarse como Modelo-InterfaceControl, una variacin del MVC ms puro La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
2.2.6.5. MODELO VISTA PRESENTADOR (MVP)37 Este Patrn surge para ayudar a realizar pruebas automticas de la interfaz grfica, para ello la idea es codificar la interfaz de usuario lo ms simple posible, teniendo el menor cdigo posible, de forma que no merezca la pena probarla. En su lugar, toda la lgica 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 grfica y que, por tanto, es ms fcil de realizar pruebas. La idea bsica es que la clase Presentador haga de intermediario entre la Vista (la interfaz grfica de usuario) y el modelo de datos. La vista tiene mtodos 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 grficos (cajas de texto, checkbox, etc.). Tambin mtodos 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 fcilmente, el Presentador recibe las interfaces que deben implementar el modelo y la vista, con los mtodos pblicos a los que el Presentador debe llamar.
37
DEFINICIN DE MODELO VISTA PRESENTADOR, Disponible en:[http://WWW.imaginanet.com/blog/patron-mvp.html]
84
Figura 16: Flujo de Patrn Modelo Vista Presentador
Se puede decir que el patrn MVP es una mejora del patrn ModeloVista-Controlador (MVC) basado en tres caractersticas: La vista no conoce el modelo. El presentador es independiente de la tecnologa 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 informacin es mostrada en la vista. Es la vista quien define la lgica de cmo la informacin es formateada y mostrada en la pantalla a partir de los controles que contiene. En este caso, el presentador nicamente gestiona los casos ms complejos para facilitar el trabajo de la vista. Martin Fowler llama a esta variacin Controlador Supervisado.
38
MVP COMO CONTROLADOR SUPERVISADO, Disponible en: [http://theartoftheleftfoot.blogspot.com/2010/10/el-patronGmodelo-vista-presentador-mvp.html]
85
Figura 17: Flujo de patrn Modelo Vista Presentador Supervisado
Cuando la vista recibe algn evento de ratn 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 despus realizar la llamada a algn comando en el modelo que realice la operacin 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 tcnicas de Data Binding. Con lo cual la cantidad de cdigo que la vista y presentador necesitan, se disminuye. Este enfoque nos va a permitir el uso de tcnicas de Data Binding sobre el modelo. Por tanto, la cantidad de lneas de cdigo 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 patrn.
86
2.2.6.5.2.
MVP COMO VISTA PASIVA39 Por otro lado, podemos hacer que el presentador gestione totalmente cmo la informacin se muestra en la vista. Es decir, tenemos una vista "tonta", sin ningn tipo de lgica, cuya nica funcin es la de mostrar la informacin que se le pasa a travs de la interfaz de la vista. Martin Fowler llama a esta variacin Vista Pasiva.
Figura 18: Flujo de patrn modelo vista presentador con vista pasiva
En este caso, cuando un usuario realiza alguna operacin sobre la interfaz de usuario, la vista delega los eventos sobre el presentador. Este realizar algn 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 operacin requerida por el usuario. Cuando el modelo provoque cambios en su estado, estos sern recogidos por el presentador (al contrario que en el controlador supervisado, que era la vista quien atenda 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-vistapresentador-mvp.html]
87
2.2.6.6. JAVASCRIPT JavaScript es un lenguaje de programacin que se utiliza
principalmente para crear pginas web dinmicas. Una pgina web dinmica 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. Tcnicamente es un lenguaje de programacin 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 anfitrin. El navegador web es el ambiente ms comn 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 ms sofisticado. Los desarrolladores aprovechan la naturaleza orientada al objeto del lenguaje para construir arquitecturas de cdigo escalables formadas por piezas reutilizables. JavaScript representa el tercer pilar en el paradigma actual de las pginas Web que consiste en tres partes claramente distinguibles: contenido (HTML), presentacin (CSS), y comportamiento (JavaScript). ORIGENES40 Inicialmente, la Web fue concebida como una coleccin de documentos HTML estticos, unidos mediante hipervnculos. Pero Con el crecimiento rpido de popularidad y tamao de la Web, los webmasters que estaban creando pginas web HTML estticas sentan que necesitaba algo ms. Queran que la oportunidad para la interaccin del usuario sea ms rica, principalmente impulsado por el deseo de evitar consultas al Servidor para tareas simples, tales como la validacin de formularios. Se presentaron dos
40
2.2.8.6.1.
JAVASCRIPT ORIENTADO A OBJETOs: Stoyan Stefanov
88
opciones para resolver dicho problema: Applets de Java (que no llegaron a tener xito) y LiveScript, que fue concebido por Netscape en 1995 y ms tarde incluido en el navegador Netscape 2.0, bajo el nombre de JavaScript. La capacidad de alterar de otro modo los elementos estticos de una pgina 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 adems de algunas funciones especficas 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 estndar, llamado ECMA-262, y JavaScript es slo una aplicacin de esta norma, aunque el ms popular. Para bien o para mal, la popularidad instantnea de JavaScript que sucedi durante el perodo 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 aadiendo caractersticas para sus navegadores y sus versiones de JavaScript. Esta situacin, junto con la falta de un estndar trajo un montn de malas opiniones sobre JavaScript. Muy a menudo, el desarrollo era muy complicado: ya que una vez escrito el cdigo para un navegador, al probarlo en otro navegador simplemente no funcionaba. Al mismo tiempo, los fabricantes de navegadores aadan constantemente nuevas caractersticas a sus navegadores obviando proporcionar herramientas adecuadas para el desarrollo, generando con esto incompatibilidades molestas para los
desarrolladores web, pero esto fue slo una parte del problema. La otra parte del problema eran los mismos desarrolladores web, que se aaden demasiadas caractersticas a sus pginas web. Los desarrolladores estaban ansiosos por hacer uso de todas las posibilidades que los nuevos navegadores para "mejorar" sus
89
pginas 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 razn por la que este lenguaje tuvo mala reputacin, haciendo que los programadores "reales" (los desarrolladores con conocimientos de lenguajes ms establecidos, como Java o C / C + +) vieran a JavaScript nada ms que como un juguete para los diseadores de front-end. Causando en algunos proyectos, la prohibicin de la programacin del lado del cliente en JavaScript 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 aos (que es un periodo muy largo en el mbito de Internet), dejaron de agregar caractersticas 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 estndares web fue abrazado por los desarrolladores y y confiar slo su Servidor
proveedores de navegadores por igual. Naturalmente a los desarrolladores no les gustaba tener que implementar cdigo para cada navegador, por lo que la idea de tener estndares acordados tuvo mucha aceptacin. Todava estamos lejos de poder desarrollar de una manera plenamente compatible con los estndares, pero lo ideal es conseguir que esto suceda en el futuro. Tanto desarrolladores como tecnologas fueron madurado y ms gente comenz a preocuparse por cosas como la usabilidad, tcnicas progresivas de mejora y accesibilidad.
41
JAVASCRIPT ORIENTADO A OBJETOS: Stoyan Stefanov
90
En este entorno ms saludable, los desarrolladores comenzaron a descubrir nuevas y mejores formas de utilizar los instrumentos que ya estaban disponibles. Despus de la publicacin de aplicaciones, como Gmail y Google Maps, que eran ricos en la programacin del lado del cliente, se hizo evidente que JavaScript ya era una tecnologa madura, teniendo como uno de los mejores ejemplos de su redescubrimiento la amplia adopcin de la funcionalidad proporcionada por el objeto XMLHttpRequest, que comenz como una innovacin para Internet Explorer, pero luego se puso en prctica por la mayora 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 pgina, sin una recarga de pgina completa. Debido al amplio uso de XMLHttpRequest, una nueva generacin 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 anfitrin. El navegador es el anfitrin ms 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 cdigo de Servidor, tales como secuencias de comandos ASP, el cdigo 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
91
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 informacin en una base de datos fuera de lnea 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 estndares relacionados con
ECMAScript. En Junio de 1997 se public la primera edicin del estndar ECMA-262. Un ao despus, en Junio de 1998 se realizaron pequeas modificaciones para adaptarlo al estndar ISO/IEC-16262 y se cre la segunda edicin. La tercera edicin del estndar ECMA-262 (publicada en Diciembre de 1999) es la versin 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 versin de ECMA-262, que podra incluir novedades como paquetes, namespaces, definicin explcita de clases, etc. ECMA tambin ha definido varios estndares relacionados con
ECMAScript, como el estndar ECMA-357, que define una extensin conocida como E4X y que permite la integracin de JavaScript y XML.
92
2.2.8.6.5.
CMO INCLUIR JAVASCRIPT EN DOCUMENTOS XHTML La integracin de JavaScript y XHTML es muy flexible, ya que existen al menos tres formas para incluir cdigo JavaScript en las pginas web.
INCLUIR JAVASCRIPT EN EL MISMO DOCUMENTO XHTML El cdigo JavaScript se encierra entre etiquetas <script> y se incluye en cualquier parte del documento. Aunque es correcto incluir cualquier bloque de cdigo en cualquier zona de la pgina, se recomienda definir el cdigo JavaScript dentro de la cabecera del documento (dentro de la etiqueta <head>). Para que la pgina XHTML resultante sea vlida, es necesario aadir el atributo type a la etiqueta <script>. Los valores que se incluyen en el atributo type estn estandarizados y para el caso de JavaScript, el valor correcto es text/JavaScript. Este mtodo se emplea cuando se define un bloque pequeo de cdigo o cuando se quieren incluir
instrucciones especficas 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 modificacin en el bloque de cdigo, es necesario modificar todas las pginas que incluyen ese mismo bloque de cdigo 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. Adems del atributo type, este mtodo 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 pgina se pueden incluir tantas etiquetas <script> como sean necesarias. Los archivos de tipo
93
JavaScript son documentos normales de texto con la extensin .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 cdigo XHTML de la pgina, que se puede reutilizar el mismo cdigo JavaScript en todas las pginas del sitio web y que cualquier modificacin realizada en el archivo JavaScript se ve reflejada inmediatamente en todas las pginas XHTML que lo enlazan. 2.2.8.6.6. COMO INCLUIR JAVASCRIPT EN DOCUMENTOS XHTML INCLUIR JAVASCRIPT EN EL MISMO DOCUMENTO XHTML El cdigo JavaScript se encierra entre etiquetas <script> y se incluye en cualquier parte del documento. Aunque es correcto incluir cualquier bloque de cdigo en cualquier zona de la pgina, se recomienda definir el cdigo JavaScript dentro de la cabecera del documento (dentro de la etiqueta <head>) INCLUIR JAVASCRIPT EN LOS ELEMENTOS XHTML43 Este mtodo es el menos utilizado, ya que consiste en incluir trozos de JavaScript dentro del cdigo XHTML de la pgina por ejemplo: <p onclick="alert('Un mensaje de prueba')">Un prrafo de
texto.</p> El mayor inconveniente de este mtodo es que ensucia innecesariamente el cdigo XHTML de la pgina y complica el mantenimiento del cdigo JavaScript. En general, este mtodo slo se utiliza para definir algunos eventos y en algunos otros casos especiales, como se ver ms 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 44
INTRODUCCION A JAVASCRIP: Javier Eguluz Prez INTRODUCCION A JAVASCRIP: Javier Eguluz Prez
94
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 programacin se define como el conjunto de reglas que deben seguirse al escribir el cdigo fuente de los programas para considerarse como correctos para ese lenguaje de programacin. La sintaxis de JavaScript es muy similar a la de otros lenguajes de programacin como Java y C. Las normas bsicas que definen la sintaxis de JavaScript son las siguientes: No se tienen en cuenta los espacios en blanco y las nuevas lneas: como sucede con XHTML, el intrprete de JavaScript ignora cualquier espacio en blanco sobrante, por lo que el cdigo se puede ordenar de forma adecuada para entenderlo mejor (tabulando las lneas, aadiendo espacios, creando nuevas lneas, etc.) Se distinguen las maysculas y minsculas: al igual que sucede con la sintaxis de las etiquetas y elementos XHTML. Sin embargo, si en una pgina XHTML se utilizan indistintamente maysculas y minsculas, la pgina se visualiza correctamente, siendo el nico problema la no validacin de la pgina. En cambio, si en JavaScript se intercambian maysculas y minsculas 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 ejecucin del script. No es necesario terminar cada sentencia con el carcter de punto y coma (;): en la mayora de lenguajes de programacin, es obligatorio terminar cada sentencia con el carcter ;. Aunque JavaScript no obliga a hacerlo, es conveniente seguir la tradicin de terminar cada sentencia con el carcter del punto y coma (;).
95
Se pueden incluir comentarios: los comentarios se utilizan para aadir informacin en el cdigo fuente del programa. Aunque el contenido de los comentarios no se visualiza por pantalla, s se enva al navegador del usuario junto con el resto del script, por lo que es necesario extremar las precauciones comentarios. sobre la informacin incluida en los
2.2.8.6.8.
POSIBILIDADES Y LIMITACIONES45 Desde su aparicin, JavaScript siempre fue utilizado de forma masiva por la mayora de sitios de Internet. La aparicin de Flash disminuy su popularidad, ya que Flash permita realizar algunas acciones imposibles de llevar a cabo mediante JavaScript. Sin embargo, la aparicin de las aplicaciones AJAX programadas con JavaScript le ha devuelto una popularidad sin igual dentro de los lenguajes de programacin web. En cuanto a las limitaciones, JavaScript fue diseado de forma que se ejecutara en un entorno muy limitado que permitiera a los usuarios confiar en la ejecucin 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 pequeas ni demasiado grandes ni colocarse fuera de la vista del usuario (aunque los detalles concretos dependen de cada navegador). Adems, 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 ejecucin de un script dura demasiado tiempo (por ejemplo por un error de programacin) el navegador informa al usuario de que un script est consumiendo demasiados recursos y le da la posibilidad de detener su ejecucin. A pesar de todo,
45
INTRODUCCIN A JAVASCRIPT: Javier Eguluz Prez
96
existen alternativas para poder saltarse algunas de las limitaciones anteriores. La alternativa ms utilizada y conocida consiste en firmar digitalmente el script y solicitar al usuario el permiso para realizar esas acciones. 2.2.8.6.9. PROGRAMACIN ORIENTADA A OBJETOS (OOP) CON JAVASCRIPT El lenguaje JavaScript est normalmente vinculado a la idea de pequeos fragmentos de cdigo que sirven para enriquecer las pginas 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. Quizs una de las ms interesantes estriba en la posibilidad que tiene el programador de crear sus propios objetos, a imagen y semejanza de otros objetos definidos por el estndar, 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 pequeos bloques de cdigo dentro de las pginas web. Con ellos es posible controlar los eventos originados por la interaccin de los usuarios, comprobar los formularios y en general, llevar a cabo todo un sinfn de pequeas tareas rutinarias y simples. Ahora bien, a medida que las pginas se complican y ofrecen ms posibilidades a los usuarios, los scripts tambin crecen, en tamao y complejidad. En estos casos el cdigo resultante suele ser bastante confuso, ineficiente y poco reutilizable, debido principalmente a la falta de conocimientos serios acerca de este lenguaje de programacin, 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 orientacin a objetos, que si no se ajusta por completo a la metodologa ortodoxa, s permite al menos organizar el cdigo
97
dando lugar a scripts ms reducidos, eficientes y reutilizables. Creacin de objetos: el constructor, las propiedades y los mtodos El lenguaje JavaScript cuenta con varios objetos predefinidos. Por ejemplo: window, document, form, etc. Todos ellos tienen una serie de mtodos 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 ms que una funcin que se define de manera especial. El siguiente fragmento de cdigo 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 ao, el mes y el da 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++, estn 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 mtodos 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, ms que cualquier miembro particular de un conjunto de objetos que describe. Por ejemplo, la clase Empleado podra representar el conjunto de todos los empleados.
98
Una instancia, por otro lado, es la particularizacin de una clase (se usa instanciacin, por abuso de lenguaje); esto es, uno de sus miembros. Por ejemplo, Victoria podra 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 ms, no menos) Un lenguaje basado en prototipos, tal como JavaScript, no hace esta distincin, simplemente tiene objetos, que son
simultneamente 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 implcita, que se establece con su creacin, y se conoce como su prototipo. Un lenguaje basado en prototipos tiene la nocin 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 ejecucin. 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 dinmicamente 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 definicin de clase separada. En esta definicin puede especificar mtodos especiales, llamados constructores, para crear instancias de una clase. Un mtodo constructor puede especificar valores iniciales para las propiedades de la instancia y desarrollando procesamiento apropiado en tiempo de creacin. Utilice el operador new en asociacin con el mtodo constructor para crear instancias de las clases. JavaScript sigue un modelo similar, pero no tiene una definicin de clase por separado del constructor. En su lugar, define una funcin
99
constructora para crear objetos con un conjunto inicial particular de propiedades y valores. Cualquier funcin JavaScript puede ser utilizada como un constructor. Utilice el operador new con una funcin constructora para crear un nuevo objeto. SUBCLASES Y HERENCIA Un lenguaje basado en clases, crea una jerarqua de clases por medio de la definicin de clases. En una definicin 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 aadir 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 aade 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 funcin constructora. As que, puede crear exactamente el ejemplo Empleado-Administrador, pero utiliza una terminologa ligeramente diferente. Primero defina la funcin constructora de Empleado, especificando las propiedades del nombre y departamento. Luego, defina una funcin constructora Administrador, especificando la propiedad reporta. Finalmente, asigne un nuevo objeto Empleado como el prototipo para la funcin constructora Administrador. Luego, cuando cree un nuevo
Administrador, este hereda las propiedades de nombre y departamento del objeto Empleado. AADIENDO Y REMOVIENDO PROPIEDADES En los lenguajes basados en clases, tpicamente crea una clase en tiempo de compilacin y luego instancia la clase ya sea en tiempo de compilacin o en tiempo de ejecucin. No puede cambiar el nmero o tipo de las propiedades de una clase despus de definir
100
la clase. En JavaScript, sin embargo, en tiempo de ejecucin puede aadir o eliminar propiedades de cualquier objeto. Si aade una propiedad a un objeto que es utilizado como prototipo para un conjunto de objetos, los objetos para los cuales este es el prototipo tambin 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 distribucin de trabajo para el desarrollo de software. Un sprint tpico 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 estn 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 sucesin de ciclos cortos de trabajo denominados sprints, obteniendo de cada uno de ellos un producto funcional que va completndose en forma iterativa. Esta forma de concebir la gestin de proyectos es radicalmente diferente al modo secuencial en que se afrontan tradicionalmente los mismos, dividindolos 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 versin 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.
101
denominado propietario del producto (product owner), que participa activamente en el proceso de desarrollo, facilitando la comprensin por parte del equipo de los aspectos prioritarios y centrales del resultado esperado. Es quien representa al cliente, con una fuerte y continua interaccin con el equipo, facilita desde el inicio la clara percepcin de la visin del producto y de los aspectos que se consideran de valor sustancial en el mismo. Al mismo tiempo que provee retroalimentacin continua al equipo sobre estos aspectos, adquiere una comprensin de las posibilidades y dificultades a partir de la comunicacin con ellos. Con el fin de guiar al equipo en los principios de trabajo implcitos en un enfoque gil de gestin, se define otro rol relevante: el scrum master o facilitador, quien es responsable de orientar al equipo en la aplicacin de las prcticas adecuadas para lograrlos beneficios esperados de esta modalidad de gestin, al mismo tiempo que se encarga de remover impedimentos y reducir las fricciones que la dinmica de trabajo pueda producir. Trabajar de esta forma exige en etapas tempranas de un proyecto lograr una visin clara y enfocada del objetivo a corto plazo, pues se apunta a obtener en un lapso de tiempo reducido una versin demostrable del producto, aunque restringida a sus caractersticas ms importantes. Esto induce a concentrarse en los aspectos de mayor relevancia. Se espera de cada iteracin o sprint, un entregable denominado incremento que es considerado un producto potencialmente completo en su totalidad y listo para su utilizacin. 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 tambin exige al equipo un alto grado de interaccin para concretar el objetivo, favoreciendo que surjan tempranamente las dificultades o impedimentos que sern afrontados diariamente a travs de reuniones de seguimiento, breves y enfocadas, tradicionalmente realizadas de pie (daily stand-up meetings). Estas reuniones no slo apuntan a realizar un control del avance sino tambin a coordinar esfuerzos para superar obstculos,
102
compartir estrategias y tcnicas para afrontar situaciones y mejorar la cohesin del equipo de trabajo. Es as que cada sprint se desarrolla en tres fases: una reunin de planificacin, un perodo de trabajo a lo largo del cual se realizan las reuniones diarias de seguimiento, y una reunin de revisin del producto desarrollado en el sprint, denominado incremento, seguido de una reunin de evaluacin del proceso de trabajo con miras a mejorarlo en forma continua, denominada retrospectiva. Un proyecto completo entonces ser visto como una sucesin de sprints a travs 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 mxima 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 sinrgico. 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 caractersticas del producto, tambin 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 tambin 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 sern 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 colaboracin del product owner y finalmente contendr la estimacin del esfuerzo o tamao de cada tarea y la asignacin del responsable. Tercero, a travs del desarrollo de un sprint, en base a cmo se irn completando las tareas se construye lo que se denomina grfico de burndown, una herramienta que permite visualizar rpidamente la cantidad de trabajo remanente y cmo se va concluyendo a travs del tiempo, facilitando la deteccin temprana de dificultades con el fin de actuar sobre ellas
103
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 Planificacin del Sprint (sprint planning), o Seguimiento diario del Sprint (daily scrum), o Revisin 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
104
CAPITULO III ESTUDIO DE FRAMEWORKS PARA LA IMPLEMENTACION DE APLICACIONES WEB DEL LADO DEL CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML
105
3.1. DOJO TOOLKIT47

Dojo es un framework que contiene APIs y widgets (controles) para facilitar el desarrollo de aplicaciones Web que utilicen tecnologa AJAX. Contiene un sistema de empaquetado inteligente, los efectos de UI, drag and drop APIs, widget APIs, abstraccin de eventos, almacenamiento de APIs en el cliente, e interaccin de APIs con AJAX. Resuelve asuntos de usabilidad comunes como pueden ser la navegacin y deteccin 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 ejrcito de las bibliotecas JavaScript". Proporciona una gama ms 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 formacin de Dojo Foundation. A da de hoy se han realizado ocho grandes actualizaciones en las que han participado sesenta desarrolladores con ms de un milln de descargas. Es de destacar que esta biblioteca es de cdigo abierto y se puede descargar de forma gratuita en su pgina 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 TECNOLOGA DOJO TOOLKIT, Disponible en: [http://es.wikipedia.org/wiki/Dojo_toolkit]
106
cubierta por una gran comunidad, con multitud de desarrolladores e informacin 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 estratgicos.
3.1.2.
3.1.2.1.
CARACTERSTICAS
COMPLEMENTOS
Los complementos de Dojo son componentes pre empaquetados de cdigo JavaScript, HTML y CSS que pueden ser usados para enriquecer aplicaciones web. Mens, pestaas y tooltips. Tablas ordenables, grficos dinmicos y dibujado de vectores 2D. Efectos de animacin y la posibilidad de crear animaciones personalizables. Soporte para arrastrar y soltar. Formularios y rutinas de validacin para los parmetros. Calendario, selector de tiempo y reloj. Editor online de texto enriquecido. Ncleo de componentes (dijit) accesible desde versiones anteriores y lector de pantalla.
3.1.2.2. COMUNICACIN ASNCRONA Una caracterstica importante de las aplicaciones AJAX es la comunicacin asncrona se Dojo entre el navegador el y el Servidor. JavaScript abstraccin
Tradicionalmente, XMLHttpRequest.
realizaba provee
con de
comando capa de
una
(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 parmetros del formulario de una manera sencilla.
107
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 jerarquas de paquetes de espacios de nombre (io, event, etc.) bajo el paquete raz dojo. Despus de la inicializacin del paquete dojo, cualquier otro paquete puede ser cargado (va XMLHttpRequest o cualquier otro transporte similar) usando las utilidades ofrecidas en el arranque. Tambin 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 mltiples archivos. Cualquier paquete o archivo puede depender de otro. En este caso, cuando el paquete es cargado, cualquier dependencia ser tambin cargada. Dojo tambin 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 cdigo necesario para ser cargado y es inicializado de una sola vez, permitiendo as el cacheado (la mayora de los navegadores web no permiten el cacheado de archivos va 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 abstraccin llamada Dojo Storage. Dojo Storage permite a la aplicacin web almacenar datos en el lado cliente, persistencia y seguridad. Cuando se incluye en una pgina web, determina cual es el mejor mtodo para almacenar la informacin. Cuando la aplicacin 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 informacin. El desarrollador que use Dojo Storage no se tiene que preocupar de esto, ya que Dojo tiene una capa de abstraccin con mtodos put() y get().
108
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 slo lectura y acceso CSV. OpmlStore: almacenamiento de slo lectura y lectura
jerrquica desde archivos en formato OPML. YahooStore: almacenamiento de slo lectura que obtiene los resultados del servicio web del buscador de Yahoo Search!. DeliciousStore: almacenamiento de slo 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 aplicacin Adobe AIR llamada Dojo Toolbox usando Dojo, en la que se incluye un API y un sistema de construccin grfico. Generalmente, el sistema de construccin se ejecuta dentro de Rhino, pero esta aplicacin 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 jerarquas de herencia. La Base se recoge en un nico archivo llamado dojo.js. Todas las funcionalidades de Base son accesibles a travs de funciones o atributos dojo.*. DOJO CORE. Dojo Core se construye sobre Dojo Base y ofrece soluciones ms
109
avanzadas como son los efectos de animacin, funcionalidades "drag and drop" o el manejo de cookies. Cualquier recurso externo a dojo.js que se tiene que importar de manera explcita 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 grficos. Est construida directamente sobre Dojo Core y en ocasiones no requiere de cdigo JavaScript para ser utilizada. Los widgets son altamente portables y se pueden compartir fcilmente en cualquier Servidor o incluso funcionar localmente sin Servidor web mediante el protocolo file//. DOJOX. DojoX (Dojo Extensions) es una coleccin independiente de subproyectos en estado de incubacin que no encajan a la perfeccin en Dojo Core o Dijit. Cada subproyecto suele incluir un archivo readme con informacin 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 coleccin de utilidades que incluye una unidad de prueba y herramientas para crear versiones personalizadas de Dojo. Estas herramientas pueden disminuir el tamao del cdigo e incluir capas con distintos archivos JavaScript. Esta disminucin se consigue a travs de ShrinkSafe, un eficiente motor de compresin 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 tecnologas como AJAX, DHTML y DOM. Fue desarrollada por Sencha. Originalmente
48
EXTJS IN ACTION: Jesus Garcia.
110
construida como una extensin de la biblioteca YUI por Jack Slocum, en la actualidad puede usarse como extensin para las bibliotecas YUI, jQuery y Prototype. Desde la versin 1.1 puede ejecutarse como una aplicacin independiente. El ExtJS no slo proporciona widgets de interfaz de usuario sino que tambin contiene una serie de otras caractersticas. Estas se dividen en seis reas principales: core UI components comunicacin 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 caractersticas bsicas tales como comunicacin mediante Ajax, manipulacin DOM, y gestin de eventos. Todo lo dems es dependiente de este ncleo ncleo no depende de nada. pero el
3.2.2.
UI COMPONENTS49
Textfield._ Aade caractersticas al campo de entrada HTML existente como validaciones bsicas, un mtodo de validacin
49
EXTJS IN ACTION: Jesus Garcia.
111
personalizado, cambio de tamao automtico, y el filtrado de teclado a travs de expresiones regulares. Textarea._ Extiende el TextField y es un campo de entrada de varias lneas. NumberField._ Este control hace casi el total de las validaciones para los nmeros enteros y flotantes. ComboBox._ Es una combinacin de un campo de texto de entrada general y una casilla desplegable para darle una combinacin de campos de entrada flexible y altamente configurable. El ComboBox tiene la capacidad de ejecucin automtica de texto (conocido como de escritura anticipada) en el rea de introduccin de texto, y junto con un almacn 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 paginacin resultado estableciendo la propiedad pageSize. La Figura xxx ilustra la anatoma de una carga remota y ComboBox con paginacin.
Figura 21:Ejemplo de Renderizado de controles ExtJS
TimeField._ Es otro control que permite agregar fcilmente un selector de tiempo a un formulario.
112
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 pequeo widget que permite al usuario introducir un fecha a travs de un campo de entrada o seleccionarla de un DatePicker. CheckBox._ Control de seleccin que puede ser agrupado en un contenedor CheckboxGroup que proporciona un conjunto de mtodos de conveniencia, validaciones y la disposicin para organizar las casillas de verificacin en las columnas. RadioGroup._ Este control extiende la clase CheckboxGroup, con la nica diferencia que solo puede seleccionarse un radio a la vez. TabPanels._ Tambin llamados pestaas sirven para dividir la informacin por secciones o por categoras. ToolBars._ Este control acta como contenedor agrupando mltiples controles en la parte superior de un formulario. ExtJS Desktop ._Este control acta como un escritorio virtual y permite registrar mltiples iconos (lanzadores de aplicaciones), en su interior mostrndolos de forma similar a la del escritorio de Windows. Layouts._ y maquetacin._ Componente que permite organizar nuestros controles de diferentes formas segn el layout elegido. Sliders._ Control deslizante dotado de posibilidades como mltiples punteros deslizantes y configuracin a travs de CSS. Charts._ Desde la versin tres de la librera de Ext JS es la posibilidad crear fcilmente grficas de barras, lineares y de pastel a partir de un Store. ListBoxy TreeView._ Estos controles permiten la carga de
113
datos desde un Store, GridPanel._ Grid que puede actuar en modo de solo lectura o tambin 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 mtodos que son definidos y expuestos en el Servidor, lo que se conoce comnmente como un procedimiento remoto o RPC. Es
conveniente para los entornos de desarrollo en los que desea exponer los mtodos del Servidor al cliente y evitar el trabajo adicional que genera la gestin de mtodos en Ajax.
3.2.4.
DATA SERVICES
Esta seccin se encarga de las necesidades de datos, que incluyen ir a buscar, analizar y cargar la informacin 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 pequeo 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 seccin 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.
114
3.3. YUI (INTERFAZ DE USUARIO YAHOO)

YUI es una biblioteca JavaScript de cdigo abierto para la construccin de aplicaciones web ricas en interactividad, la misma que hace uso de tcnicas tales como Ajax, DHTML y DOM scripting. La pgina de Yahoo! fue la primera en usar YUI en el verano de 2005. YUI fue lanzado para el uso pblico 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 versin reconstruida desde cero con el objetivo de modernizar la biblioteca e incorporar las lecciones aprendidas de YUI 2. Entre las mejoras incorporadas estn un selector de CSS accionado por un motor para la recuperacin de elementos DOM, un mayor nfasis en la granularidad de mdulos, un archivo base ms pequeo que carga otros mdulos cuando sea necesario, y una variedad de modificaciones sintcticas destinados a hacer que la escritura de cdigo sea ms rpida y fcil. Esta biblioteca se divide en seis componentes que su vez se descompone en componentes individuales que pueden ser utilizados segn 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. Despus de eso, la mayora de los componentes tambin necesitan la coleccin DOM y la Utilidad de eventos. Cada componente se presenta en una versin miniaturizada, una versin estndar, y una versin de depuracin, esta ltima registra todos los tipos de informacin que permite el funcionamiento interno de los componentes a ser depurados.
3.3.1.
NCLEO50
El ncleo de YUI es un ligero conjunto de herramientas (31KB la versin 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 manipulacin del rbol DOM,
50
RESUMEN DE YAHOO UI LIBRARY, Disponible en: [http://es.wikipedia.org/wiki/Yahoo!_UI_Library]
115
incluyendo posicionamiento de elementos y gestin 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 botn Atrs y la gestin de Marcadores/Favoritos de los navegadores web. Connection Manager: Ayuda para manejar el objeto
XMLHttpRequest. Cookie: Permite gestionar las cookies. DataSource: Proporciona una interfaz comn para que otros componentes puedan interactuar con diferentes tipos de datos. Drag and Drop: Facilita la creacin de eventos y elementos que pueden ser arrastrados. Element: Proporciona una capa para los elementos que facilita el aadido de escuchadores, manipulacin del rbol DOM y atributos 'get' y 'set'. Get: La utilidad Get soporta la carga asncrona de datos y archivos de estilos CSS externos. ImageLoader: Permite aplazar la carga de imgenes que no son visibles durante la carga de la pgina, proporcionando un aumento del rendimiento. JSON: Proporciona mtodos para el tratamiento de datos JSON. Estos mtodos estn 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]
116
YUI Loader: Es un cargador del lado cliente que permite la carga de forma dinmica de cualquier componente y dependencia de la biblioteca al vuelo.
3.3.3.
CONTROLES / WIDGETS
AutoComplete: Proporciona la funcin de auto completado (lista de sugeridos) para los usuarios. Soporta varios formatos de datos, tanto del lado cliente como del lado Servidor (va XMLHttpRequest). Button: Permite la creacin de botones grficos que funcionan como un botn tradicional en HTML. Calendar: Un calendario grfico y de control dinmico. Charts: Permite la creacin de diferentes tipos de grficos (lineales, de barras, etc.). Color Picker: Proporciona una interfaz grfica para la seleccin de colores. Container: Proporciona una interfaz grfica como Tooltip, paneles, cuadros de dilogo, etc. DataTable: Una potente herramienta para mostrar tablas tabulares en una pgina web. Permite la ordenacin de columnas tanto en el lado cliente como en el Servidor, paginacin, scroll, seleccin de filas, redimensionado de columnas y edicin inline. ImageCropper: Proporciona una interfaz grfica para recortar una imagen desde el lado cliente. Layout Manager. Menu: Proporciona una API para la creacin de mens flotantes, barras de men y mens de contexto. Rich Text Editor: Es un sofisticado editor de texto rico modular del lado cliente y muy configurable. Slider: Proporciona un elemento genrico que permite al usuario elegir entre un rango de valores. TabView: Permite la navegacin entre pestaas, soportando la
117
carga dinmica de contenido va XMLHttpRequest. TreeView: Aade 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, tambin proporciona recursos CSS. El apoyo de YUI a CSS se remonta a versiones muy tempranas de YUI 2, ahora en su nueva versin 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 lnea de base comn ver y sentir. YUI CSS Fonts, lo que proporciona un conjunto coherente de tamaos de fuente en todos los navegadores. YUI Grids CSS, que le permite crear rpidamente diseos sofisticados que utilizan un mnimo CSS. Aunque se desarroll junto a la API de JavaScript YUI 3, las hojas de estilo de ninguna manera estn 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 extensin Firebug para el navegador Mozilla Firefox o la consola JavaScript del navegador Safari. Profiler: Para perfilar el cdigo JavaScript. ProfilerViewer: Usado con el anterior componente (Profiler)
52
YUI3 COOKBOOK: Evan Goer
118
proporciona un perfilado visual. YUI Test: Permite aadir unidades de testeo al cdigo JavaScript.
3.3.6.
HERRAMIENTAS DE CONTRUCCIN
YUI Compressor Es un compresor de cdigo JavaScript y CSS diseado para proporcionar un resultado 100% seguro.
119
CAPITULO IV IMPLEMENTACION DE FRAMEWORK MODELO VISTA PRESENTADOR PARA APLICACIONES WEB DEL LADO DEL CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML
120
4.1. DESCRIPCION DEL PROBLEMA

Actualmente existe un conjunto de Framework como EXTJS, YUI, DOJO TOOLKIT que estn basado en HTML, JavaScript y CSS que nos permiten la implementacin y desarrollo de aplicaciones web del lado del cliente, Estos Framework constan de un conjunto de libreras que facilitan el desarrollo de aplicaciones Web, permitiendo resolver asuntos de usabilidad comunes como pueden ser la navegacin y deteccin del navegador, soportar cambios de URL en la barra de URLs para luego regresar a ellas (bookmarking). Cuentan con un nmero considerable widgets o controles de usuario que nos permiten interactuar con el usuario de manera similar a las aplicaciones de escritorio, As como tambin de Frameworks necesarios para poder implementar el patrn modelo vista controlador. Actualmente estos Framework que si bien es cierto facilitan la implementacin de aplicaciones web del lado del cliente, a la hora de utilizarlos muestran deficiencias en algunos aspectos como son: Definicin de Interface de Usuario._ El problema principal en la definicin de interfaces de usuario es el uso del lenguaje JavaScript el cual no fue diseado para definir Interfaces de usuario sino ms bien para poder interactuar con las mismas. Actualizacin de datos en los Patrones de Diseo._ 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 implementacin de un patrn de diseo mucho ms simple como es el patrn Modelo Vista Presentador, as como tambin un motor generador de interfaz grfica de usuario en base a descriptores XML.
4.2. RESUMEN DEL PROYECTO

Este proyecto se encarga de la implementacin de un Framework Modelo Vista Presentador como controlador supervisado basado en las libreras del Framework ExtJS la misma que fue elegida por estar entre los Framework ms utilizados, de mayor simplicidad en su uso y por disponer de un nmero considerable de controles de usuario.
121
Entre las caractersticas principales que tendr este Framework: Definicin de interfaz de usuario mediante documentos XML (Extensible Markup Language). Sincronizacin de la vista y el presentador a travs de descriptores en el Documento XML que define la interfaz de usuario. Sincronizacin del modelo y la vista en funcin a descriptores definidos en un documento XML.
4.3. BENEFICIOS
Mejorar la reutilizacin de cdigo e interfaces. Mejorar la mantenibilidad de los proyectos. Reducir el tiempo de desarrollo de aplicacin web del lado del cliente. Poseer un Framework que nos permita la implementacin del patrn modelo vista presentador. Delegar el diseo de interfaces de usuario a especialistas en el rea sin necesidad de que estos tengan conocimiento de lenguajes de programacin.
4.4. DESCRIPCIN DE LA METODOLOGA DE TRABAJO

4.4.1. INTRODUCCIN
Este documento describe la implementacin de la metodologa de trabajo Scrum en el desarrollo de la tesis para obtener el Ttulo Profesional de Ingeniero Informtico y de Sistemas de los Bachilleres Jorge Francisco Castro Alvarez y Luis Rafael Callapia Cosio para la gestin de la implementacin del proyecto RAFMVP.
Incluye junto con la descripcin de este ciclo de vida iterativo e incremental para el proyecto, los artefactos o documentos con los que se gestionan las tareas de adquisicin y suministro: requisitos, monitorizacin y seguimiento del avance, as como las
responsabilidades y compromisos de los participantes en el proyecto.

122
4.4.1.1.
PROPSITO DE ESTE DOCUMENTO
Facilitar la informacin de referencia necesaria a las personas implicadas en la implementacin y calificacin del Framework RAFMVP. 4.4.1.2. ALCANCE Personas y procedimientos implicados en la implementacin y calificacin del Framework RAFMVP.
4.4.2.
4.4.2.1.
DESCRIPCIN GENERAL DE LA METODOLOGA

FUNDAMENTACIN
Las principales razones del uso de un ciclo de desarrollo iterativo e incremental de tipo Scrum para la ejecucin de este proyecto son: Sistema modular. Las caractersticas del sistema [Nombre del sistema] permiten desarrollar una base funcional mnima 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 mdulos terminados, de forma que puede disponer de una funcionalidad bsica en un tiempo mnimo y a partir de ah un incremento y mejora continua del sistema. Previsible inestabilidad de requisitos. Es posible que el sistema incorpore ms funcionalidades de las inicialmente identificadas. Es posible que durante la ejecucin del proyecto se altere el orden en el que se desean recibir los mdulos o historias de usuario terminadas. Para el cliente resulta difcil precisar cul ser la dimensin completa del sistema, y su crecimiento puede continuarse en el tiempo suspenderse o detenerse.
123
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 metodologa Scrum tenga xito son: Autonoma del equipo Respeto en el equipo Responsabilidad y auto-disciplina Foco en la tarea Informacin transparencia y visibilidad.
4.4.3.
PERSONAS Y ROLES DEL PROYECTO. Tabla N 6

Persona Luis Rafael Callapia Cosio Jorge Francisco Castro Alvarez Jorge Francisco Castro Alvarez Luis Rafael Callapia Cosio
Fuente: Elaboracin propia
Contacto rafasiglo21@hotmail.com jorge77721@gmail.com jorge77721@gmail.com rafasiglo21@hotmail.com
Rol Scrum Master Dueo de producto Equipo Equipo
4.4.4.
ARTEFACTOS
Documentos Pila de producto o Product Backlog Pila de sprint o Sprint Backlog Sprint Incremento Grficas para registro y seguimiento del avance. Grfica de producto o Burn Up Grfica de avance o Burn Down. Comunicacin y reporting directo. Reunin de inicio de sprint Reunin tcnica diaria Reunin de cierre de sprint y entrega del incremento
124
4.4.2.3. PILA DE PRODUCTO Es el equivalente a los requisitos del sistema o del usuario en esta metodologa. Se trata de una lista que contiene elementos denominados historias de usuario, las cuales son descripciones genricas 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 dueo 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 1 Nombre Cmo probarlo Importancia 10 Estimacin 13
Crear los Deben existir componentes bsicos componentes Modelo, adecuados para el Vista y Presentador modelo MVP. Desarrollar las clases Al modificar el valor de para el componente una variable enlazable en el Presentador, este Presentador cambio debe reflejarse en el Modelo o la Vista, segn con quien sea enlazado esta variable.
Desarrollar las clases Al modificar el valor de para el componente una variable mediante la Vista, esta debe ser Vista reflejada en el Modelo y en el Presentador. Desarrollar las clases El Modelo debe ser para el componente capaz de enlazarse al Presentador mediante Modelo descriptores en un documento XML y debe ser capaz de invocar servicios del lado del Servidor (RPC
125
o REST) 5 Procesador de XML Definir una vista en que renderiza vistas XML y verla en HTML y en HTML y JavaScript JavaScript en el navegador. Mecanismo para invocar eventos y mtodos desde los documentos XML Definir eventos y mtodos en el Presentador y enlazarlos en las definiciones XML de las vistas y que estas funcionen. Embeber (anidar) vistas ya creadas con XML dentro de otras y que se rendericen sin problema en el navegador. 7 5
Mecanismo de reutilizacin de componentes existentes
Mecanismo de Al modificar el valor de Binding entre una propiedad en el propiedades y vistas. Presentador, esta se debe de modificarse en la Vista y viceversa. Mecanismo de Binding entre mtodos y eventos de las vistas. Al invocar los eventos de la vista, estos deben invocar a mtodos definidos dentro del Presentador. Se deben de obtener datos desde servicios REST desde el lado del Servidor.
21
21
10 Mecanismos de invocacin de servicios del lado del cliente.
34
11 Crear mecanismos de El plugin debe estar asistencia a disponible para algn desarrolladores IDE de desarrollo web. (plugins)
21
4.4.2.4. PILA DEL SPRINT Es el documento de registro de los requisitos detallados o tareas que va a desarrollar el equipo tcnico en la iteracin (actual o que est preparndose para comenzar).
126
Los responsables de este trabajo son el dueo de producto, que absuelve dudas respecto de las historias a ser desarrolladas, el equipo de desarrolladores, que se divide las tareas, colocan estimaciones ms exactas y otras, y el Scrum master que dirige la reunin. 4.4.2.5. SPRINT Cada una de las iteraciones del ciclo de vida iterativo Scrum. La duracin de cada sprint en la mayora de casos es fija para todas, pero esto no es una regla fija. Se puede acordar la duracin de estos segn las tareas que se estn 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 definicin 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.
127
4.4.2.7. Grfica de avance (Burn Down) Grfico que muestra el estado de avance del trabajo del sprint en curso. El dueo del producto no tiene responsabilidades especficas en este artefacto, salvo el de estar informado de este. El Scrum master mantiene actualizado este grfico con los datos obtenidos de las reuniones diarias con el equipo de desarrollo. 4.4.2.8. REUNIN DE INICIO DE SPRINT Reunin para determinar las funcionalidades o historias de usuario que se van a incluir en el prximo incremento. En esta reunin participan: el dueo de producto, el scrum master y el equipo de desarrollo. 4.4.2.9. REUNIN TCNICA DIARIA Puesta en comn diaria del equipo con presencia del Coordinador del proyecto o Scrum Manager de duracin mxima de 10 minutos. Las reuniones diarias durante este proyecto se realizaron por la maana antes del inicio de cada jornada, donde se intercambiaron los avances del da anterior y el avance previsto para ese da. 4.4.2.10. REUNIN DE CIERRE DE SPRINT Y ENTREGA DEL
INCREMENTO. Reunin para probar y entregar el incremento al gestor del producto. En esta reunin participan el dueo de producto para realizar las pruebas necesarias, el equipo de producto que realiza la
demostracin y el scrum master que coordina y cumple la funcin de facilitador. En algunos sprints la reunin de retroalimentacin se realiz al da siguiente de la entrega y hubo un descanso el resto de la semana. En los ltimos sprints las reuniones de entrega y de retroalimentacin se realizaron el mismo da, debido a la proximidad de la fecha final prevista para la entrega final. Estos ltimos sprints fueron muy cortos y sin periodos de descanso.
128
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. Grfico Burn Down.
4.4.2.11. SPRINT 1 Tabla N8

Objetivo Componentes MVP terminados
Fecha de Inicio 03-09-2012
Fecha de Trmino 25-09-2012
Figura 23: Tiempo Estimado para la entrega del Sprint 1
129
Figura 24: Definicin de Tareas del Sprint 1
Figura 25: Grafico Burndown que refleja el avance del Sprint 1 en funcin del tiempo
130

Objetivo Renderizador de HTML listo
131
4.4.2.13. SPRINT 3 TablaN10

Objetivo Binding de mtodos y propiedades listos
132
133

Objetivo Fecha de Inicio Fecha de Trmino 26-11-2012
Integracin con servicios del lado 13-11-2012 del Servidor terminados

134
135

Objetivo Fecha de Inicio Fecha de Trmino 07-12-2012
Plugins de desarrollo terminados 27-11-2012

136
137
Figura 37: Grafico Burndown que refleja el avance del Sprint en funcin del tiempo
138
CAPITULO V DISCUSIN RESULTADOS
139
CONCLUSIONES
1.
Los Framework basados en Javascript y HTML son un resultado de la evolucin de capacidades implementadas en JavaScript teniendo como base la orientacin a documentos lo cual genera inconvenientes a la hora de implementar aplicaciones web del lado del cliente.
2.
Los Framework para la implementacin de aplicaciones web del lado del cliente basadas en JavaScript y HTML superan las limitaciones de usabilidad e interaccin de las aplicaciones web tradicionales debido a que estas libreras se encarga de gestionar las solicitudes al servidor de manera asncrona.
3.
La aparicin 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 eleccin del Framework en el cual se basara 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 mtodos de los diferentes componentes en base a descriptores definidos en documentos XML.
140
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 metodologas 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 diseo para as poder evitar problemas de escalabilidad, mantenibilidad y reutilizacin de cdigo.
3.
Se propone como futuras investigaciones, El desarrollo de Controles de Usuarios basados en JavaScript y HTML con mayor orientacin al desarrollo de aplicaciones Web.
4.
Se propone como futuras investigaciones, El desarrollo de Frameworks modelo vista controlador para las libreras como Dojo ToolKit y Yahoo UI que permitan en desarrollo de aplicaciones Web del lado del cliente con una menor orientacin a documentos,
141
BIBLIOGRAFA
LIBROS
GOER, EVAN. Yui 3 Cookbook. Editorial OReilly Media, Inc. Edicin 2012 OSMANI, ADDY. Developing Backbone.Js Applications. Editorial ISBN edicin 2012 GRONER, LOIANE. Ext Js 4 First Look. Editorial Packt Publishing Copyright 2011
PALACIO, JUAN. Flexibilidad con Scrum Principios de Diseo e Implantacin de Campos de Scrum. Editorial Safecreative Edicin Octubre 2008 PALACIO, JUAN Y RUATA, CLAUDIA. Scrum Manager: Proyectos Formacin. Editorial Safecreative Edicin 1.3.2 Octubre 2010 GARCIA, JESUS. Ext Js In Action. Editorial Manning Publications Edicin 2011
RAMON, JORGE Ext.Js.3.0.Cookbook. Editorial Packt Publishing Edicin 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 Edicin 2008 Scrum Manager Proyectos Apuntes De Formacin. Editorial Safecreative 2009 DEEMER PETE, BENEFIELD GABRIELLE, LARMAN CRAIG & VODDE BAS. Informacin Bsica De Scrum (The Scrum Primer). Versin 1.1 2009 KNIBERG, HENRIK. Scrum y XP Desde Las Trincheras Como Hacemos Scrum. Editorial C4Media Inc Edicin 2007
142
ORCHARD LESLIE MICHAEL, PEHLIVANIAN ARA, KOON SCOTT & JONES HARLEY. Professional Javascript Frameworks Prototype, Yui, Ext Js, Dojo And Mootools. Editorial Wiley Publishing, Inc. Edicin 2009 BLANKENSHIP JERREL, BUSSA MATTHEW & MILLETT SCOTT. Pro Agile .Net Development With Scrum. Editorial Apress Edicin 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 Edicin 2nd Edition, 2002 MORITZ, FLORIAN. Rich Internet Applications (Ria):A Convergence Of User Interface Paradigms Of Web And Desktop Exemplified. Edicin 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 Beginners Guide. Editorial McGraw Hill, 2010 GAMMA ERICH, HELM RICHARD, JOHNSON RALPH & VLISSIDES JOHN. Patrones De Diseo (Elementos De Software Orientado A Objetos Reutilizables). STEFANOV, STOYAN. Javascript Orientado A Objetos. EGULUZ PREZ, JAVIER. Introduccion A Javascrip. BLANKENSHIP JERREL, BUSSA MATTHEW & MILLETT SCOTT. Pro Agile .Net Development With Scrum.
143
TESIS
ADRIN YAZYI, SERGIO. Una Experiencia Prctica de Scrum a Travs del Aprendizaje Basado en Proyectos Mediado por Tic en un Equipo Distribuido. Salamanca (Espaa). Universidad de Salamanca. Junio 2011 OCHOA TAPIA, GRETTY MAIBELY Y TEJADA AUCCACUSI, JORGE CARLOS. Estudio de las Tecnologas Ria y Data Push de Servicios Multimedia en Tiempo Real. Cusco (Per). Universidad Nacional de San Antonio Abad del Cusco. Agosto 2010
PGINAS WEB
Wikipedia.org, Comparativa de navegadores web [en lnea]. Fundacin 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 lnea]. 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-octubre2012-7634.html Mate.asfusion.com, Ejemplo de Ciclo de Vida de Mate [en lnea]. 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 lnea]. 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 lnea]. 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 lnea]. 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 lnea]. Trabajo hecho por Loiane Groner, [actualizado 17 Jul 2012; accesado 10 Oct 2012] Disponible en: http://www.slideshare.net/loianeg/extjs-4mvc-architecture-mind-map-13669488
144
Mclibre.org, Historia de la Web: los navegadores [en lnea]. Esta pgina forma parte del curso "Pginas 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 lnea]. Fundacin Wikimedia Inc. [actualizado 17 dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Navegador_web Wikipedia.org, Navegador web [en lnea]. Fundacin Wikimedia Inc. [actualizado 17 dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Navegador_web Wikipedia.org, Mozilla Firefox [en lnea]. Fundacin Wikimedia Inc. [actualizado 29 Dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Mozilla_Firefox Wikipedia.org, Java Servlet [en lnea]. Fundacin Wikimedia Inc. [actualizado 28 Dic 2012; accesado 10 Oct 2012] Disponible en: http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers Microsoft.com, Gua bsica de ASP.NET [en lnea]. 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 lnea]. 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 lnea]. Fundacin Wikimedia Inc. [actualizado 21 Dic 2012; accesado 10 Oct 2012] Disponible en: http://en.wikipedia.org/wiki/WYSIWYG Wikipedia.org, PHP [en lnea]. Fundacin Wikimedia Inc. [actualizado 30 Dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/PHP Wikipedia.org, Applet Java [en lnea]. Fundacin Wikimedia Inc. [actualizado 09 Nov 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Applet_Java
145
Wikipedia.org, Applet [en lnea]. Fundacin 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 lnea]. Fundacin Wikimedia Inc. [actualizado 24 Dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Abstract_Window_Toolkit Wikipedia.org, Swing [en lnea]. Fundacin Wikimedia Inc. [actualizado 12 Jul 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Swing_(biblioteca_grfica) Microsoft.com, Common Language Runtime (CLR) [en lnea]. 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 lnea]. International Business Machines [actualizado 07 Ago 2009; accesado 10 Oct 2012] Disponible en: http://www.ibm.com/developerworks/library/xhtml5/?ca=dgr-lnxw01NewHTML Wikipedia.org, HTML5 [en lnea]. Fundacin Wikimedia Inc. [actualizado 15 Dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/HTML5 Wikipedia.org, Patrn de diseo [en lnea]. Fundacin 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 lnea]. Fundacin Wikimedia Inc. [actualizado 24 Dic 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Modelo_Vista_Controlador TheArtofTheLeftFoot.blogspot.com, El patrn Modelo-Vista-Presentador (MVP) [en lnea]. 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 lnea]. Fundacin Wikimedia Inc. [actualizado 31 Oct 2012; accesado 10 Oct 2012] Disponible en: http://es.wikipedia.org/wiki/Dojo_toolkit
146
Wikipedia.org, Yahoo! UI Library [en lnea]. Fundacin 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 lnea]. Fundacin 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
147

TesisFinal 30-12-12

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TesisFinal 30-12-12

Uploaded by

Copyright:

Available Formats

Contenido

1.3.1. 1.3.2. 1.3.3. 1.3.4. 1.3.5. 1.3.6.

2.1.1. 2.1.2. 2.1.3. 2.1.4. 2.1.5. 2.1.6. 2.1.7. 2.2.

2.2.1. 2.2.2. 2.2.3. 2.2.4. 2.2.5. 2.2.6. 2.2.7.

3.1.1. 3.1.2. 3.1.3. 3.2.

3.2.1. 3.2.2. 3.2.3. 3.2.4. 3.2.5. 3.2.6. 3.3.

3.3.1. 3.3.2. 3.3.3. 3.3.4. 3.3.5. 3.3.6.

4.4.1. 4.4.2. 4.4.3. 4.4.4. 4.4.5.

CONCLUSIONES ......................................................................................................................... 139 RECOMENDACIONES ................................................................................................................. 141 BIBLIOGRAFA .. 142

A todas las personas que han colaborado en el desarrollo de esta Tesis.

A Marleny. Por confiar y creer siempre en m.

Jorge Francisco Castro Alvarez

Luis Rafael Callapia Cosio

Slo un exceso es recomendable en el mundo: el exceso de gratitud. Jean de la Bruyre

CAPITULO I PLANTEAMIENTOS GENERALES

1.1. DESCRIPCION DEL PROBLEMA

1.2. PLANTEAMIENTO DEL PROBLEMA

Vista Presentador en clientes web basados en tecnologas HTML y JavaScript.

Programming (XP). Se eligieron estos modelos de trabajo.

BENEFICIOS DEL PROYECTO

CAPITULO II MARCO TERICO

objeto, vase: http://es.wikipedia.org/wiki/Singleton.

Fig. 1. Flujo de Cairngorm Fuente: http://internetdeveloping.blogspot.com/2009/04/empezando-con-cairngormdesarrollando.html

Fig.2.Flujo de Mate Fuente: http://mate.asfusion.com/archives/category/examples

Fig.3.Flujo de SWIZ Fuente: http://swizframework.jira.com/wiki/display/SWIZ/Home

Fig.4.Flujo de Backbone MVC Fuente: http://www.webvigo.com/blog/backbone-js-estructura-mvc-en-cliente/

Fig.5.Flujo de SPROUTCORE MVC Fuente: http://blog.sproutcore.com/tag/statecharts/

capa ViewModel (conjunto de direcciones URL especfica).

Fig.6.Flujo de EXTJS MVC Fuente: http://www.slideshare.net/loianeg/extjs-4-mvc-architecture-mind-map-13669488

2.2. MARCO CONCEPTUAL

LA WORL WIDE WEB (WWW)3

METODOS HTTP Tabla N1

cliente hacia el Servidor. OPTIONS Pide informacin sobre las caractersticas de

comunicaciones con SSL.

Link Orig-URL Referer

Fuente: MARTIN P. CLARK. DATA NETWORKS

ENCABEZADOS DE RESPUESTA Tablas N4

Tipo de codificacin para el cuerpo de la respuesta

Tipo de idioma en el cuerpo de la respuesta

asociada con el documento Caractersticas del Servidor que envi la respuesta

Fuente: MARTIN P. CLARK. DATA NETWORKS

Fuente: MARTIN P. CLARK. DATA NETWORKS

Fig. 11. El Navegador Web Internet Explorer 8

NAVEGADORES WEB ,Disponible en: [http://es.wikipedia.org/wiki/Navegador_web]

HISTORIA DE LA WEB: NAVEGADORES, disponible en: [http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadores.html]

Fig. 12. Cuota de Navegadores Web. Fuente: http://es.wikipedia.org/wiki/Mozilla_Firefox

TECNOLOGIAS DEL LADO DEL SERVIDOR

DEFINICIN DE SERVLETCONTAINERS, Disponible en: [http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers]

DEFINICIN DE ASP.NET ,Disponible en: [http://support.microsoft.com/?scid=kb;es;305140]

DEFINICIN DE PHP , disponible en: [http://es.wikipedia.org/wiki/PHP]

TECNOLOGIAS DEL LADO DEL CLIENTE22

EL GRAN LIBRO DE HTML5. CSS3 Y JAVASCRIPT :Juan Diego Gauchat.

radicalmente. JavaScript era claramente el lenguaje que permita a los

DEFINICIN DE APPLET JAVA, disponible en [http://es.wikipedia.org/wiki/Applet_Java] DEFINICIN DE APPLET, disponible en [ http://es.wikipedia.org/wiki/Applet]

DEFINICIN DE AWT, Disponible en:[http://es.wikipedia.org/wiki/Abstract_Window_Toolkit] DEFINICIN DE SWING, Disponible en:[ http://es.wikipedia.org/wiki/Swing_(biblioteca_grfica])

INTERACCION AJAX DE EJEMPLO

Script de lado del servidor

Flex 4 SDK (Gratuito)

Flash Builder 4 (Comercial)

MXML y FXG (Basados en XML)

Flash Player (Web)

SHANNON HORN, Microsoft Silverlight 3: A Beginners Guide, McGraw Hill, 2010.

Audio y video en formatos MP3 y Windows Media Video (WMV).

NUEVOS ELEMENTOS HTML5,Disponible en:[ http://www.ibm.com/developerworks/library/x-html5/?ca=dgrlnxw01NewHTML]