TesisFinal 30-12-12

1

Contenido CAPITULO I .................................................................................................................................. 10

PLANTEAMIENTOS GENERALES ................................................................................................... 10

1.1. DESCRIPCION DEL PROBLEMA ..................................................................................... 11

1.2. PLANTEAMIENTO DEL PROBLEMA .............................................................................. 11

1.3. OBJETIVOS ................................................................................................................... 11

1.3.1. OBJETIVO PRINCIPAL ........................................................................................... 11

1.3.2. OBJETIVOS ESPECÍFICOS ...................................................................................... 12

1.3.3. JUSTIFICACION ..................................................................................................... 12

1.3.4. MÉTODOLOGIA DE INVESTIGACIÓN .................................................................... 13

1.3.5. LIMITACIONES ..................................................................................................... 14

1.3.6. BENEFICIOS DEL PROYECTO ................................................................................ 14

CAPITULO II ................................................................................................................................. 15

REVISION BIBLIOGRAFICA .............................................................. ¡Error! Marcador no definido.

2.1. ANTECEDENTES ........................................................................................................... 16

2.1.1. CAIRNGORM ........................................................................................................ 16

2.1.2. MATE ................................................................................................................... 18

2.1.3. SWIZ..................................................................................................................... 19

2.1.4. BACKBONE ........................................................................................................... 20

2.1.5. SPROUTCORE MVC .............................................................................................. 21

2.1.6. SAMMY ................................................................................................................ 22

2.1.7. MVC EXTJS ........................................................................................................... 23

2.2. MARCO CONCEPTUAL ................................................................................................. 24

2.2.1. INTERNET ............................................................................................................. 24

2.2.2. LA WORL WIDE WEB (WWW).............................................................................. 25

2.2.3. TECNOLOGIAS DEL LADO DEL SERVIDOR ............................................................ 53

2.2.4. TECNOLOGIAS DEL LADO DEL CLIENTE ................................................................ 58

2.2.5. FRAMEWORK ....................................................................................................... 76

2.2.6. PATRON DE DISEÑO ............................................................................................ 76

2.2.7. SCRUM ............................................................................................................... 101

CAPITULO III .............................................................................................................................. 105

ESTUDIO DE FRAMEWORKS PARA LA IMPLEMENTACION DE APLICACIONES WEB DEL LADO DEL

CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML ........................................................................ 105

2

3.1. DOJO TOOLKIT ........................................................................................................... 106

3.1.1. ORIGEN Y DESARROLLO ..................................................................................... 106

3.1.2. CARACTERÍSTICAS .............................................................................................. 107

3.1.3. ARQUITECTURA ................................................................................................. 109

3.2. EXTJS .......................................................................................................................... 110

3.2.1. CORE .................................................................................................................. 111

3.2.2. UI COMPONENTS ............................................................................................... 111

3.2.3. WEB REMOTING ................................................................................................ 114

3.2.4. DATA SERVICES .................................................................................................. 114

3.2.5. DRAG AND DROP ............................................................................................... 114

3.2.6. GENERAL UTILITIES ............................................................................................ 114

3.3. YUI (INTERFAZ DE USUARIO YAHOO) ........................................................................ 115

3.3.1. NÚCLEO ............................................................................................................. 115

3.3.2. UTILIDADES ........................................................................................................ 116

3.3.3. CONTROLES / WIDGETS ..................................................................................... 117

3.3.4. CSS HERRAMIENTAS .......................................................................................... 118

3.3.5. HERRAMIENTAS DE DESARROLLO ..................................................................... 118

3.3.6. HERRAMIENTAS DE CONTRUCCIÓN .................................................................. 119

CAPITULO IV .............................................................................................................................. 120

IMPLEMENTACION DE FRAMEWORK MODELO VISTA PRESENTADOR PARA APLICACIONES WEB

DEL LADO DEL CLIENTE BASADOS EN JAVASCRIPT, CSS, HTML ................................................ 120

4.1. DESCRIPCION DEL PROBLEMA ................................................................................... 121

4.2. RESUMEN DEL PROYECTO ......................................................................................... 121

4.3. BENEFICIOS ................................................................................................................ 122

4.4. DESCRIPCIÓN DE LA METODOLOGÍA DE TRABAJO .................................................... 122

4.4.1. INTRODUCCIÓN ................................................................................................. 122

4.4.2. DESCRIPCIÓN GENERAL DE LA METODOLOGÍA ................................................. 123

4.4.3. PERSONAS Y ROLES DEL PROYECTO. ................................................................. 124

4.4.4. ARTEFACTOS ...................................................................................................... 124

4.4.5. RESUMEN DE SPRINTS ....................................................................................... 129

CONCLUSIONES ......................................................................................................................... 139

RECOMENDACIONES ................................................................................................................. 141

BIBLIOGRAFÍA ..…………………………………………………………………………………………………………………… 142

3

PRESENTACIÓN

SEÑOR DECANO DE LA FACULTAD DE CIENCIAS QUÍMICAS, FÍSICAS Y

MATEMÁTICAS DE LA UNIVERSIDAD NACIONAL SAN ANTONIO ABAD

DEL CUSCO.

SEÑORES MIEMBROS DEL JURADO:

De acuerdo al Reglamento de Grados y Títulos vigentes para optar el

Título Profesional de Ingeniero Informático y de Sistemas ponemos a vuestra

disposición la Tesis colectiva, intitulada “FRAMEWORK PARA LA

IMPLEMENTACIÓN DEL PATRÓN MODELO VISTA PRESENTADOR EN

CLIENTES WEB (HTML-JAVASCRIPT)” que abarca el estudio de frameworks

para la implementación de clientes web basados en JavaScript, CSS y HTML.

Así como el desarrollo de un framework alternativo que mejore el desarrollo,

escalabilidad y mantenibilidad de dichos clientes.

Esperando que los señores dictaminantes y miembros del jurado,

dispensen las deficiencias encontradas y valoren el contenido desarrollado que

trata de dar un aporte tecnológico a la sociedad en general.

Los Tesistas.

4

AGRADECIMIENTOS

Agradecer de manera especial a nuestro Asesor, Lic. José Mauro Pillco

Quispe por el tiempo y la dedicación prestados para el desarrollo de esta

Tesis.

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

5

DEDICATORIAS

A mi madre

Por brindarme una carrera, creer en mí y con su vida convencerme que la

fuerza de voluntad es suficiente para lograr lo que uno desee.

A Marleny.

Por confiar y creer siempre en mí.

A la memoria de mi padre

A mis amigos y amigas

Quienes participaron, aún sin saberlo, en lograr este objetivo.

Jorge Francisco Castro Alvarez

6

A mis padres

Por su apoyo incondicional a pesar que no siempre supe corresponderles

tanto cariño y paciencia, que tuvieron en todos estos años. Por brindarme

una carrera, creer en mí y con sus vidas convencerme que la fuerza de

voluntad es suficiente para lograr lo que uno desee. Y sobre todo por su

amor.

A mis hermanos

Por confiar y creer siempre en mí, gracias por ser los mejores hermanos los

quiero mucho.

A mis amigos y amigas

Que están ahí lejos o cerca de uno, pero que siempre estarán en mi

corazón.

Luis Rafael Callapiña Cosio

Sólo un exceso es recomendable en el mundo: el exceso de gratitud.

Jean de la Bruyère

7

RESUMEN

En la actualidad las aplicaciones web del lado del cliente necesitan un

comportamiento similar a la de las aplicaciones de escritorio tradicionales,

que permitan combinar el alcance de la Internet con una interfaz de usuario

enriquecida, con el fin de mejorar la productividad, este tipo de aplicaciones

son conocidas con el nombre de Rich Internet Application (RIA).

Hoy en día esas experiencias de usuario enriquecidas son mayormente

implementadas en tecnologías como Flash, Silverlight, JavaFX, las mismas

que vienen siendo remplazadas progresivamente por HTML5 (HTML,

JavaScript y CSS3).

El avance de las RIAs y el uso de tecnologías como Ajax, REST, Web

Services, JSON-RPC, XML-RPC, AMF, entre otros han hecho posible crear

aplicaciones web del lado del cliente con mayor independencia de la

aplicación web del lado Servidor haciendo de esta forma la actualización

modificación y migración de tecnología en el cliente mucho más flexible e

independiente de la implementación del Servidor. Generando con esto el

desarrollo de diferentes Frameworks implementados en JavaScript para la

comunicación entre el cliente y el Servidor así como para el manejo, control

y actualización del DOM (Modelo de Objetos de Documento).

Hoy en día se cuenta con un número considerable de frameworks que

permiten la implementación de aplicaciones web del lado del cliente, siendo

una cantidad considerable de estos orientados a documentos y otros pocos

a aplicaciones web que consumen datos.

Entre los framework más completos, maduros, que gozan de una

popularidad considerable y permiten la implementación de aplicaciones web

del lado del cliente que consumen datos tenemos: EXTJS, YUI (interfaz de

usuario Yahoo) y DojoToolkit.

Esta tesis se enfoca en el desarrollo de un Framework que permita

implementar el patrón modelo vista presentador (MVP), haciendo uso de

inyección de dependencia y de archivos XML para la definición de las

interfaces gráficas. Ofrece información preliminar acerca de la Web, una

8

visión general de tecnologías del lado del cliente, e identifica las diferentes

soluciones existentes para la implementación patrones de diseño como

modelo vista controlador (MVC) en aplicación web del lado del cliente

basadas en HTML, JavaScript y CSS.

9

ABSTRACT

Currently Web applications require client side behavior similar to that of

traditional desktop applications, that combine the scope of the Internet with a

rich user interface in order to enhance productivity, these applications are

known by the name of Rich Internet Application (RIA).

Today those rich user experiences are mostly implemented in technologies

such as Flash, Silverlight, JavaFX, the same that are being progressively

replaced by HTML5 (HTML, JavaScript and CSS3).

The advance of RIAs and the use of technologies such as Ajax, REST, Web

Services, JSON-RPC, XML-RPC, AMF, etc.. They can create web clients

miss more independently of the server-side application thus making

modification and updating of technology migration on the client much more

flexible and independent of the server implementation. Generating this

development with different JavaScript Frameworks implemented for

communication between client and server as well as for management, control

and update the DOM (Document Object Model).

Today there is a considerable number of client-side frameworks that allow

the implementation of web applications on the client side, with a considerable

amount of these document-oriented applications and a few other web

oriented data processing.

Among the most comprehensive framework, mature, enjoying considerable

popularity and allow the implementation of web applications on the client side

oriented data processing are: ExtJS, YUI (Yahoo User Interface) and Dojo

Toolkit.

This thesis focuses on the development of a framework that allows to

implement the Model View Presenter pattern (MVP), using dependency

injection and XML files for defining GUIs. Provides preliminary information on

the Web, an overview of client-side technologies, and identifies the various

existing solutions for implementing design patterns such as Model View

Controller (MVC) Web Application client side based on HTML, JavaScript

and CSS.

10

CAPITULO I

PLANTEAMIENTOS

GENERALES

11

1.1. DESCRIPCION DEL PROBLEMA

Actualmente existe un número considerable de framework para la

implementación de patrones de programación en el desarrollo de

aplicaciones web. Sin embargo la mayoría de estos fueron

implementados en tecnologías que se ejecutan del lado del Servidor

generando con esto una dependencia innecesaria entre las aplicaciones

del lado del cliente y la del Servidor.

El desarrollo de las tecnologías como XML, JSON, HTML, JavaScript y

CSS3 ha permitido la aparición de diferentes Framework que facilitan el

manejo del DOM (Modelo de Objetos de Documento), la comunicación

entre el cliente y el Servidor así como también la implementación de

patrones de diseño como modelo vista controlador, modelo vista

presentador, etc.

A pesar de existir múltiples Framework para la implementación de

patrones de programación basados en HTML, JavaScript y CSS3, estos

carecen de claridad y eficiencia a la hora de utilizarlos y en especial en

la definición de las interfaces de usuario ya que las definen mediante

código JavaScript, generando problemas sustancialmente importantes

que afectan el tráfico, la mantenibilidad, la escalabilidad del sistema y

tiempo de aprendizaje de los desarrolladores.

1.2. PLANTEAMIENTO DEL PROBLEMA

¿Cómo resolver el problema de legibilidad, mantenibilidad, escalabilidad

y reutilización de código en las aplicaciones web del lado del cliente

basadas en HTML, JavaScript y CSS?

¿Resuelven los framework existentes los problemas de legibilidad,

mantenibilidad, escalabilidad y reutilización de código?

1.3. OBJETIVOS

1.3.1. OBJETIVO PRINCIPAL

Implementar un Framework para la implementación del patrón Modelo

12

Vista Presentador en clientes web basados en tecnologías HTML y

JavaScript.

1.3.2. OBJETIVOS ESPECÍFICOS

Definir y implementar las clases y mecanismos necesarios para

registrar el contrato que debe de existir entre los diferentes

componentes del patrón modelo vista presentador (Vista-

Presentador, Presentador-Modelo).

Implementar una clase que ha de implementar los mecanismos

necesarios para instanciar la interfaz de usuario en un

documento HTML, notificar de sus cambios al Presentador así

como actualizarse a sí misma, en función a las notificaciones

de la clase presentador.

Implementar una clase ancestro para las clases que

representen los presentadores de las aplicaciones la misma

que ha de implementar los mecanismos necesarios para

notificar y actualizar la vista así como modificarse así mismo en

función a las notificaciones que le presenten tanto el modelo

como la vista.

Implementar una clase ancestro para las clases que

representen el modelo de la aplicación, misma que ha de

implementar los mecanismos necesarios para notificar de sus

cambios al presentador y modificarse así mismo en función a

las notificaciones provenientes de las clases que representen el

presentador.

1.3.3. JUSTIFICACION

En la actualidad no contamos con muchos framework basados en

HTML, JavaScript y CSS, orientados a la implementación de patrones

de diseño en aplicaciones web del lado del cliente, aplicaciones que

han sido siempre difíciles de escribir, difícil de organizar y difícil de

mantener. Teniendo una tendencia de crecimiento rápido y sin control

a medida que agrega más funcionalidad y desarrolladores a un

proyecto.

13

Los Frameworks existentes como EXTJS, YUI (interfaz de usuario

Yahoo) y Dojo Toolkit permiten crear aplicaciones web del lado del

cliente con características similares a las de una aplicación de

escritorio a través del acceso al DOM y facilitando la comunicación e

intercambio de datos con el Servidor, pero utilicemos la librería que

utilicemos lo común es tener un montón de código JavaScript que

después minimizamos en un archivo (o varios) para servir en nuestro

sitio web. Esto a la larga se convierte en un infierno de selectores y

callbacks que tenemos que mantener sincronizados con el código

HTML para que sigan funcionando como se espera.

A pesar de que estos frameworks nos permiten implementar el patrón

de diseño modelo vista control aún siguen generando problemas en el

desarrollo, escalabilidad y mantenimiento de las aplicaciones

especialmente en la definición de las interfaces de usuario ya estas

son definidas en el leguaje JavaScript el cual no fue creado para la

definición de interfaces de usuario sino más bien para dar

funcionalidad a las mismas.

Otras de las limitaciones que presentan estos framework son las

inherentes a la implementación de los mismos, como sucede en

EXTJS el mismo que nos obliga a crear un controlador par cada

control de usuario utilizado.

Otra de sus limitaciones que tienen estos frameworks es la inherente

diferencia existente entre el patrón Modelo vista controlador y el

patrón modelo vista presentador ya que el primero obliga a

implementar un controlador por cada vista para poder ejecutar las

acciones solicitadas a través de las interacciones con el usuario.

Mientras que en el segundo la vista es la encargada de responder al

usuario.

1.3.4. MÉTODOLOGIA DE INVESTIGACIÓN

La metodología del trabajo de investigación es “Descriptiva y

Aplicativa”. Descriptiva porque describirá las características del

proyecto. Aplicativa porque permitirá resolver el problema, alcanzar

los objetivos y evaluar los resultados. La metodología tecnológica que

14

se usara será el marco de trabajo denominado SCRUM que se apoya

sobre la metodología de Programación Extrema o extreme

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

1.3.5. LIMITACIONES

Este proyecto, tiene por objetivo crear un Framework para la

implementación del patrón modelo vista presentador en aplicaciones

clientes basados en tecnología HTML, JavaScript y CSS. En este

entender el proyecto no se encargara del desarrollo de librerías para

el manejo del Modelo de Objetos del Documento (DOM), así como

tampoco de la implementación de controles de usuario para la

renderizacion de las vistas motivo por el cual se usaran librerías

implementadas por terceros.

1.3.6. BENEFICIOS DEL PROYECTO

Al implementar el Framework Modelo Vista Presentador podrá

resolverse la mayoría de los problemas existentes en la

implementación de clientes HTML-JavaScript.

En este trabajo se identifican los beneficios de las RIAs y sus ventajas

sobre las aplicaciones web tradicionales.

En este trabajo se identifican las ventajas y desventajas de los

diferentes framework existentes.

15

CAPITULO II

MARCO TEÓRICO

16

2.1. ANTECEDENTES

El primer intento de mejorar la usabilidad de las aplicaciones web,

acercándolas más a sus contrapartes de escritorio, fue realizado por Sun

Microsystems con la introducción de los Applets Java. En un principio la

única tecnología que nos permitía desarrollar clientes web, a pesar de

sus ventajas, en dicha época los ordenadores carecían del poder de

computo necesario para poder ejecutar ligeramente este tipo de

aplicaciones, así como la falta de velocidades aceptables para la

conexión conllevaron a una mala aceptación de esta tecnología,

impidiendo que se logren desarrollar frameworks dedicados a la

implementación de patrones de diseño.

Otra tecnología que intento llevar la experiencia de las interfaces de

escritorio a la web es Adobe Flash. La misma que gozo de gran

aceptación en su momento, permitiendo el desarrollo de frameworks

especializados en la implementación de diferentes patrones de diseño,

entre los que podemos mencionar:

2.1.1. CAIRNGORM

Es el más antiguo y el más conocido de los framework hechos para

Flex Builder. En realidad, es una micro-arquitectura, es decir, una

colección de patrones de diseño que han demostrado que funcionan

bien con otros, Se basa en el patrón MVC y ha diseñado

específicamente para facilitar la sincronización de estados y de datos

entre el cliente y el Servidor, mientras se mantiene la programación de

la capa de vista separada de la aplicación de datos.

La construcción de un proyecto en Cairngorm implica dividir la

aplicación en varios paquetes y que se extiende a las clases

Cairngorm, entre las secciones principales y clases de este tipo de

proyectos tenemos:

ModelLocator._ Es un singleton1 que actúa como un

repositorio de datos-representa el estado del programa. La

naturaleza de la clase singleton garantiza que todos los

1 SINGLETON: está diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único

objeto, véase: http://es.wikipedia.org/wiki/Singleton.

http://es.wikipedia.org/wiki/Singleton

17

componentes del programa tienen acceso a los mismos datos.

ServiceLocator._ es otro singleton que actúa con una

ubicación centralizada para el almacenamiento de servicios

tales como HTTP Services. Una vez más, porque esta clase es

un producto único, todos los componentes del programa

tendrán acceso a los mismos servicios.

Lógica empresarial._ se encapsula en clases de comandos

que implementan el patrón de comando. Estas clases

representan la lógica que responde a eventos de usuario.

Los eventos._ Estos manejados por el front Controller

(Controlador frontal) clase, que ejecuta los comandos

apropiado para ese evento. Cada evento de usuario que el

programa debe responder tiene que estar registrada en esta

clase junto con su clase de comando correspondiente.

Clases de delegado._ se utilizan como indicadores para el

acceso y responder a servicios remotos.

Fig. 1. Flujo de Cairngorm

Fuente: http://internetdeveloping.blogspot.com/2009/04/empezando-con-cairngorm-

desarrollando.html

18

2.1.2. MATE

Fue creado para poder implementar el patrón Modelo Vista

Presentador y sincronizar los datos del cliente con los del Servidor en

aplicaciones Adobe Flex, basado en eventos y manejadores de

eventos los mismos que hacen uso de etiquetas básicas MXML para

poder enlazar las vistas con el presentador.

Mate también implementa la idea de inyección de dependencia, a

veces se denominada el principio de Hollywood, o "no nos llame,

nosotros lo llamaremos". Los objetos se construyen de tal manera que

los datos que estos requieren se le es proporcionado o se les inyecta

en la clase. En otras palabras, las clases no llaman para obtener los

datos ("no nos llame"), sino que se pasan los datos que necesitan ("te

llamaremos") a través de inyección de dependencia para así poder

sincronizar los cambios del modelo en el presentador.

Fig.2.Flujo de Mate

Fuente: http://mate.asfusion.com/archives/category/examples

19

2.1.3. SWIZ

Swiz es un framework de inversión de dependencia (IoC) framework

que proporciona metodologías para simplificar la gestión de eventos y

llamadas asincrónicas a métodos remotos. El foco principal del

framework Swiz es proporcionar un verdadero paradigma MVC en una

manera simple y efectiva. A diferencia de Cairngorm y PureMVC,

específicamente huye de la imposición de patrones de Java y no

impone ninguna estructura de carpetas predefinida.

Para crear un proyecto Swiz tenemos que indicar al framework acerca

de los componentes de la aplicación. En su esencia, Swiz es una

fábrica centralizada. Los componentes se cargan en la fábrica a

través de una clase BeanLoader. Cuando se inicia la aplicación, la

fábrica se encarga de la creación de instancias de sus componentes.

Swiz también proporciona gestión de la dependencia a través de

metatag (información adicional de la cual hace uso el framework para

poder definir la dependencia entre objetos) personalizado llamado

Autowire. Esta etiqueta es un método de definición de las

dependencias entre clases Swiz.

Fig.3.Flujo de SWIZ

Fuente: http://swizframework.jira.com/wiki/display/SWIZ/Home

20

Posteriormente la evolución y mejoras de tecnologías como HTML,

JavaScript y CSS. Permitieron crear clientes aplicaciones ricas en

internet, lo que conllevo al desarrollo de múltiples tipos de frameworks

para el manejo del DOM, sincronización de datos con el Servidor e

implementación de diferentes patrones de diseño entre los que podemos

mencionar:

2.1.4. BACKBONE

Backbone fue creado para poder implementar en clientes web

JavaScript el Patrón Modelo Vista Controlador permitiéndonos

configurar/separar nuestra aplicación dependiendo de lo que

necesitamos realizar. Así Backbone nos presenta las tres capas de la

siguiente forma:

Capa Modelo._ Backbone nos entrega dos clases (aceptemos

llamar clase a los objetos JavaScript que intentan tener un

comportamiento similar a una clase POO) que realizan

acciones de almacén de datos y comunicación con el Servidor.

Backbone.Model y Backbone.Collection, en donde cada una

tiene sus funciones y métodos específicos.

Capa Vista._ Aquí Backbone provee una sola clase llamada

Backbone.View, que cuenta con métodos y funciones que

permiten administrar los eventos realizados por el usuario al

interactuar con los elementos de la página.

Capa Controlador._ Backbone cambia el nombre de ésta capa

por otro concepto, pero que básicamente realizan la misma

función: Backbone.Router, su función es manejar los enlaces,

URL y funcionar como una central de acciones.

21

Fig.4.Flujo de Backbone MVC

Fuente: http://www.webvigo.com/blog/backbone-js-estructura-mvc-en-cliente/

2.1.5. SPROUTCORE MVC

SproutCore es un framework de código abierto, permite implementar

el Patrón de Diseño "Modelo, Vista, Controlador", en clientes web

(HTML- JavaScript). Este Framework extiende la arquitectura MVC

tradicional mediante la adición de más de tres capas: Interfaz de

Servidor, Display y Responders.

Models._ Esta capa se encarga de contener los datos de

aplicación y gran parte de la lógica de negocio, tales como

contactos, fotos o correos electrónicos.

Views._ La función de esta capa es de manejar la pantalla y

responder a eventos de usuario, pero en general tienen poco o

ningún conocimiento específico de dominio

Controllers._ Esta capa está encargada de cerrar la brecha

entre las dos capas anteriores, es decir esta se encarga de

sincronizar los cambios en la vista con los cambios en el

modelo.

Server Interface._ Esta capa se encarga de sincronizar datos

entre el Servidor web y la capa del modelo, utilizando

opcionalmente en el cliente almacenamiento local para admitir

22

el modo fuera de línea.

Display._ Es la capa que en realidad renderiza la interfaz de

usuario. Incluye el navegador web y cualquier biblioteca de

bajo nivel de DOM (como jQuery o Prototype).

Responders._ Es la capa que controla el estado general de las

aplicaciones. Aquí es donde se suele poner el código de nivel

superior que configura los modelos, vistas y controladores

basados en el estado de carga u otros factores.

Fig.5.Flujo de SPROUTCORE MVC

Fuente: http://blog.sproutcore.com/tag/statecharts/

2.1.6. SAMMY

Sammy es un framework pequeño y poco conocido, idóneo para

pequeños proyectos, tiene una estructura basada en plugins y

también nos permite implementar el patrón de diseño "Modelo, Vista,

Controlador”, basada en respuesta a URL mediante función JS las

mismas que responde con contenidos HTML que posteriormente

actualizara las secciones correspondientes de la página.

DataModel._ Capa encargada del manejar las entidades y la

comunicación con el Servidor.

ViewModel._ Capa encargada de monitorear los cambios y el

comportamiento y la estructura de los elementos HTML.

Controlador._ Encargada vincular la capa DataModel con la

23

capa ViewModel (conjunto de direcciones URL específica).

2.1.7. MVC EXTJS

ExtJS es un conjunto de frameworks JavaScript que permite

desarrollar potentes aplicaciones del lado del cliente y está orientado

a objetos. Entre los distintos frameworks que contiene esta MVC

EXTJS que nos permite implementar parcialmente el patrón de

diseño Modelo Vista Controlador ya que el concepto de vistas que

maneja está basada en controles de usuario individuales mas no en

una vista completa que estaría representada por un conjunto de

controles visuales. Este framework nos obliga a extender tres clases

que son:

Modelo._ Esta clase nos permite definir y abstraer las

propiedades de una entidad, y se usan para llenar una

colección de datos para luego poder desplegar la información

en un widget como un Grid, View, Combo box, o algún otro

control que permita la visualización de colecciones de datos.

Controlador._ Esta clase nos permite agregar la interacción y

funcionalidad a nuestra aplicación mediante diferentes

funciones que han de enlazarse con los diferentes eventos de

la vista.

Vistas._ Esta clase es la encargada de extender el

componentes o widget, por ejemplo un Grid, un formulario y

todo aquello que se renderiza en la pantalla.

Store._ Este vendría a representar la capa de datos el cual se

encarga de almacenar los modelos para luego ser usados en

un Grid.

24

Fig.6.Flujo de EXTJS MVC

Fuente: http://www.slideshare.net/loianeg/extjs-4-mvc-architecture-mind-map-13669488

2.2. MARCO CONCEPTUAL

2.2.1. INTERNET2

Es un conjunto descentralizado de redes de comunicación

interconectadas, que utilizan la familia de protocolos TCP (Control de

Transmisión) /IP (Protocolo de Internet), garantizando que las redes

físicas heterogéneas que la componen funcionen como una red lógica

única, de alcance mundial. Sus orígenes se remontan a 1969, cuando

se estableció la primera conexión de computadoras, conocida como

ARPANET, entre tres universidades en California y una en Utah,

EE.UU.

Uno de los servicios que más éxito ha tenido en Internet ha sido la

World Wide Web (WWW, o "la Web"), Al contrario de lo que se piensa

comúnmente, Internet no es sinónimo de World Wide Web (WWW, o

"la Web"). Esta es parte de Internet, siendo uno de los muchos

servicios ofertados en la red Internet. La Web es un sistema de

información mucho más reciente, desarrollado inicialmente por Tim

2OCHOA TAPIA GRETTY MAIBELY,TEJADA AUCCACUSI JORGE CARLOS, Estudio De Las Tecnologías Ria Y Data Push De

Servicios Multimedia En Tiempo Real, Universidad Nacional de San Antonio Abad Del Cusco,2010:Pag23

25

Berners Lee en 1989.

La WWW es un conjunto de protocolos que permite, de forma sencilla,

la consulta remota de archivos de hipertexto. Ésta fue un desarrollo

posterior (1990) y utiliza Internet como medio de transmisión.

2.2.2. LA WORL WIDE WEB (WWW)3

La World Wide Web (WWW) emergió en los inicios de la década de

los 90s y se ha convertido rápidamente en el recurso más poderoso

para compartir información. Ha revolucionado los negocios, haciendo

posibles cosas que eran antes inconcebibles, como compras

electrónicas, banca electrónica, televisión en línea, apuestas en línea,

búsquedas en línea, video llamadas, correo electrónico, etc.

Fig. 7. La World Wide Web (WWW): una combinación de DNS, HTTP, HTML y un

navegador web

Fuente: Martin P. Clark. Data Networks, IP and the Internet: Protocols, Design and

Operation. John Wiley& Sons, Ltd., 2003

Cuatro tecnologías surgieron a inicios de los 90s para dar origen a la

World Wide Web. Estas son:

3 MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :

473

26

2.2.2.1. SISTEMA DE NOMBRES DE DOMINIO (DNS)4

La primera piedra angular para la World Wide Web (WWW) fue

establecida a inicios de los 80s, mediante el desarrollo y

especificación del Sistema de nombres de dominios (DNS).

Antes del sistema de nombres de dominios, ya era común en el

sistema operativo UNIX la creación de enlaces de nombres. Estos

enlaces eran registrados bajo un archivo de configuración donde se

relacionaba el nombre de un computador con su ubicación en la red.

Debido a que UNIX era el sistema operativo dominante entre la

comunidad ARPANET, la cual originó la Internet, fue natural extender

la idea de los enlaces de nombres para permitir que cualquier

Servidor UNIX en la ARPANET pueda ser localizado por todos los

demás Servidores.

Inicialmente todas los direcciones de cada host en la ARPANET eran

administradas de manera centralizada, pero a medida que el tamaño

de la red crecía y el número de equipos conectados a la red se

empezaba a multiplicar, este modelo se convirtió poco práctico,

surgiendo así el sistema de nombres de dominio (DNS), el cual era un

servicio de directorio descentralizado.

El sistema de nombres de domino (DNS) es usado básicamente para

mapear un nombre (hostname) de Servidor en la red con una

dirección IP, para localizar dicho Servidor y establecer comunicación

con este. Así es posible resolver la dirección web www.servidor.com a

una dirección IP (por ejm.: 37.168.153.232) del Servidor relacionado.

Utilizando la dirección IP, el Servidor puede ser contactado usando

cualquiera de los protocolos IP.


474

27

Fig. 8. Estructura de los espacios de nombres de dominios


Operation. John Wiley & Sons, Ltd., 2003

Existen 3 componentes básicos del sistema de nombres de dominio:

El espacio de nombres de dominio.- Define un esquema de

nombres jerárquico para todos los hosts y subredes en un dominio

determinado.

Los Servidores de nombres.- Son programas de Servidor que

almacenan información sobre la estructura de dominios. Un Servidor

de nombres es la autoridad para una parte dada de un espacio de

nombres, el cual puede ser subdividido en zonas. El Servidor de

nombres almacena copias para las zonas para las cuales es la

autoridad.

Los programas de resolución.- Son programas que se ejecutan en

las computadoras del usuario. Extraen, usan y almacenan en cache

información procedente de los Servidores de nombres en respuesta a

pedidos DNS del cliente (denominados consultas). Un programa de

resolución funciona típicamente en un sistema operativo cliente. Un

navegador web usualmente integra esta funcionalidad de resolución.

28

Fig. 9. El Sistema de Nombre de Dominios (DNS) provee de un servicio de búsqueda



2.2.2.2. PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO (HTTP)5

Es un protocolo que permite que documentos sean creados a partir de

múltiples archivos de texto e imágenes, donde cada uno de estos

archivos puede ser almacenado en un computador distinto. Un

hiperenlace es una clase de “puntero” usado para marcar la posición

en un documento donde un texto, imagen u otro deben de apuntar a

la ubicación donde el archivo se encuentra almacenado.

Frecuentemente el hiperenlace aparece en texto como una dirección

de nombre de dominio, precedido por http://www. HTTP es el

protocolo que recupera el archivo señalado por el hiperenlace. La

versión actual del protocolo es la versión 1.2 (HTTP/1.2). El protocolo

de transferencia de hipertexto permite:

Transferencia de datos basada en punteros (por tanto la

recuperación de datos, capacidades de búsqueda o anotación

de documentos científicos con referencias bibliográficas a otros

documentos o reportes).

Hiperenlazar datos mediante enlaces a archivos. El protocolo

HTTP es usado entre un cliente HTTP (también llamado el

5MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :

465

29

agente de usuario - UA) y el Servidor de origen HTTP. El

hiperenlace existe para conectar un puntero residente en el

cliente con el archivo de datos real alojado en el Servidor de

origen. El archivo hiperenlazado es recuperado utilizando una

secuencia de pedidos y respuestas http.

Fig. 10. HTTP: Cadenas de solicitud y respuesta



2.2.2.2.1. AGENTE DE USUARIO, SERVIDOR DE ORIGEN E

INTERMEDIARIOS HTTP6

Las solicitudes HTTP (HTTP requests) son generadas por el cliente

(agente de usuario) y la cadena de petición es pasada al Servidor

de origen. La respuesta HTTP (HTTP response) es devuelta por

medio de la cadena de respuesta. Tanto las solicitudes como las

respuestas son transportadas normalmente a través del puerto

TCP 80.

Los intermediarios HTTP pueden ser proxys o caches. Dichos

dispositivos no están siempre presentes, pero son usados a veces

para incrementar la seguridad de acceso a determinado Servidor

HTTP (si se usa un proxy) o para mejorar la velocidad de respuesta

de una petición HTTP (si se usa un cache).

Un proxy HTTP se encuentra generalmente cerca del Servidor de

origen (por ej. Un firewall que asegura un Servidor web). El proxy

discrimina las solicitudes HTTP dirigidas hacia el Servidor de

origen. Las solicitudes no permitidas son resueltas con un error por

parte del Servidor proxy.


466

30

Un Servidor de cache se encuentra generalmente cerca, y en

beneficio del agente de usuario. El Servidor de cache almacena

todas las respuestas recibidas en la cadena de respuesta,

permitiendo que las solicitudes subsecuentes de los mismos

recursos sean resueltas por este sin tener que repetir la petición al

Servidor de origen.

URIs, URLs y URNs7

El URI de solicitud (Universal Resource Identifier / Identificador de

Recurso Universal) es una combinación de un URL (Universal

Resource Locutor / Localizador de Recurso Universal: que localiza

un recurso de red) y un URN (Universal Resource Name / Nombre

de Recurso Universal: que localiza un archivo en particular). Un

URI HTTP tiene el siguiente formato estándar:

http://host [:puerto] / ruta_abs [?consulta]

Donde host es el nombre de dominio del Servidor HTTP, puerto es

el número de puerto TCP a ser usado para la transferencia del

protocolo HTTP, ruta_abs es la ruta absoluta hacia el archivo de

destino y consulta es la información relacionada con la solicitud. Si

el puerto no se específica, el puerto por defecto (80) es usado. Un

ejemplo de URI podría ser:

http://WWW.Servidor.com:80/ventas/index.html

2.2.2.2.2. SOLICITUDES Y RESPUESTAS HTTP8

SOLICITUD HTTP

Las solicitudes HTTP (generados por el cliente HTTP o agente de

usuario) incluyen la siguiente información:

Un método de solicitud (por ejm. Un comando como GET,

POST, PUT, DELETE, etc.);

Un identificador de recurso universal (URI) (Universal

Resource Identifier) (también llamado identificador de

documento universal) un URI es equivalente a la

7MARTIN P. CLARK. DATA NETWORKS, IP and the Internet: Protocols, Design and Operation. John Wiley & Sons, Ltd, 2003 :

472 8HANS BERGSTEN. JAVA SERVER PAGES™, 2nd Edition, O'Reilly, 2002 : 20

http://www.servidor.com/ventas/index.html

31

combinación del localizador universal de recurso (URL)

(Universal Resource Locator) y del nombre universal de

recurso (URN) (Universal Resource Name). Este es el

localizador de archivo o “puntero” el cual indica donde el

protocolo HTTP puede localizar el archivo solicitado.

La versión del protocolo HTTP.

Información acerca del cliente que realiza la solicitud; y

Información adicional que forma parte de la solicitud (si se

requiere).

Los primeros tres elementos listados arriba forman juntos la línea

de solicitud HTTP. Una línea de solicitud HTTP podría ser:

GET http://www.servidor.com/ventas/ordenes.html HTTP/1.1

De entre los tres parámetros el más importante es el método.

HTTP/1.1 incorpora ocho métodos, aunque sólo obliga a

implementar GET y HEAD, siendo todos los demás opcionales. En

cualquier caso, los Servidores que implementen alguno de los

métodos adicionales, deben atenerse a la especificación de los

mismos. Existe también la posibilidad de implementar métodos

extendidos, a los que la especificación no pone ningún límite.

METODOS HTTP

Tabla Nº1

Método Significado

GET Devuelve el recurso identificado en la URL pedida.

HEAD Funciona como el GET, pero sin que el Servidor

devuelva el cuerpo del mensaje. Es decir, sólo se

devuelve la información de encabezado.

POST Indica al Servidor que se prepare para recibir

información del cliente. Suele usarse para enviar

información desde formularios.

PUT Envía el recurso identificado en la URL desde el

32

cliente hacia el Servidor.

OPTIONS Pide información sobre las características de

comunicación proporcionadas por el Servidor. Le

permite al cliente negociar los parámetros de

comunicación.

TRACE Inicia un ciclo de mensajes de petición. Se usa para

depuración y permite al cliente ver lo que el Servidor

recibe en el otro lado.

DELETE Solicita al Servidor que borre el recurso identificado

con el URL.

CONNECT Este método se reserva para uso con proxys.

Permitirá que un proxy pueda dinámicamente

convertirse en un túnel. Por ejemplo para

comunicaciones con SSL.

Fuente: MARTIN P. CLARK. DATA NETWORKS

El método GET es el método por defecto para seguir enlaces y

enviar datos a través de Internet. Después de pulsar sobre un

enlace, el navegador enviará el método GET. Si pulsamos sobre el

botón de envío (Submit) de un formulario y dentro de la etiqueta

<FORM> su propiedad METHOD es igual a GET.

En HTTP/1.0 sólo se especificaban tres métodos, GET, POST y

HEAD. Estos son, con mucha diferencia, los tres más extendidos y

utilizados

Después del método completo de petición, se suele enviar los

encabezados de solicitud HTTP.

ENCABEZADOS DE SOLICITUD HTTP

Tablas Nº 2

Nombre Descripción

Accept Tipo de contenido aceptado por el navegador (por

ejemplo, texto/html).

Accept-Charset Juego de caracteres que el navegador espera

33

Accept-Encoding Codificación de datos que el navegador acepta

Accept-Language Idioma que el navegador espera (de forma

predeterminada, inglés)

Authorization Identificación del navegador en el Servidor

Content-Encoding Tipo de codificación para el cuerpo de la solicitud

Content-Language Tipo de idioma en el cuerpo de la solicitud

Content-Length Extensión del cuerpo de la solicitud

Content-Type Tipo de contenido del cuerpo de la solicitud (por

ejemplo, texto/html). Consulte Tipos de MIME

Date Fecha en que comienza la transferencia de datos

Forwarded Utilizado por equipos intermediarios entre el navegador y

el Servidor

From Permite especificar la dirección de correo electrónico del

cliente

Link Vínculo entre dos direcciones URL

Orig-URL Dirección URL donde se originó la solicitud

Referer Dirección URL desde la cual se realizó la solicitud

User-Agent Cadena con información sobre el cliente, por ejemplo, el

nombre y la versión del navegador y el sistema operativo


El encabezado de petición Accept es el más usado, indica al

Servidor que tipo de respuesta puede tratar el navegador.

El encabezado de petición Accept tiene la siguiente sintaxis

general:

Accept: tipo-informacion; calidad

El tipo de datos o información se describe mediante los tipos MIME

(Multipart Internet Mail Extension) estos son una forma abierta y

extensible de representar el contenido de los datos. Como su

nombre indica fueron en un primer momento utilizados para

http://es.kioskea.net/systemes/mime.php3

34

extender las características del correo electrónico, hoy su uso se

ha generalizado, también puede llamárseles IMT (Internet Media

Types).

Los MIME se componen de un tipo y un subtipo, como ejemplo, un

archivo que es un documento de texto y que ha sido escrito en

HTML, tendrá como tipo MIME:

text/html

El registro de los tipos MIME los controla la IANA (Internet Asigned

Numbers Authority) y en su sitio Web se puede obtener la lista

completa y actualizada de los tipos registrados. Es importante el

registro de tipos MIME, esto asegura que dos tipos de contenido

distintos no acaban con el mismo nombre. El prefijo especial “x-

“queda reservado para tipos experimentales (desplegados sin que

haya terminado el proceso de registro) o tipos de uso interno de

organizaciones, por ejemplo:

image/x-fwf

El protocolo HTTP usa tipos MIME en sus encabezados, por

ejemplo para:

Informar al cliente el tipo de datos que está recibiendo del Servidor.

Esto se hace con el encabezado Content-Type. Por ejemplo, un

navegador típico puede manejar los datos de tres maneras distintas

según el tipo MIME indicado en Content-Type :

Visualizar el documento, por ejemplo con tipos text/html .

Llamar a una aplicación externa, por ejemplo con tipos

application/pdf.

O preguntarle al usuario que hacer ante un tipo que no se entiende,

por ejemplo

image/x-fwf .

Permitir la negociación de contenido. El cliente, en su petición

incluye los tipos MIME que acepta. Por ejemplo, un navegador

puede soportar documentos de tipo application/zip , lo indicará con

el encabezado HTTP:

Allow: application/zip

35

Encapsular una o más entidades dentro del cuerpo de mensaje,

mediante los tipos MIME multipart. Quizá el ejemplo más conocido

sea el tipo:

multipart/form-data

El tipo multipart/form-data ha sido definido para encapsular los

datos de un formulario en su envío hacia el Servidor mediante el

método POST.

En la siguiente tabla aparecen los tipos MIME más comunes:

Tabla Nº3

Tipo MIME Descripción

Application Indica al Servidor que aplicación ejecutar basándose en

la extensión del fichero.

Audio Especifica el tipo de audio que puede tratar el

navegador. Suele ser basic, x-aiff y x-wav.

Image Especifica el tipo de imagen que puede tratar el

navegador. Suele ser gif y jpeg.

Text Especifica el tipo de texto que puede ser manejado por el

navegador. Comúnmente los tipos de texto son: html,

plain, richtext y x-setext.

Video Especifica el tipo de video que puede ser tratado por el

navegador. Suele ser: mpeg y QuickTime.


Mediante el factor de calidad que aparece junto al tipo de contenido

que se espera recibir, podremos acortar los tiempos de descarga,

ya que si no indicamos una calidad de 100% no se enviarán los

datos completos de la URL, sino una versión más reducida. Para

indicar que podemos aceptar audio con una calidad del 50% el

encabezado Accept deberá contener lo siguiente:

Accept: audio/*; q=0.5

El asterisco del ejemplo indica que podemos recibir cualquier

fichero de audio, pero podremos indicar una extensión para limitar

36

el tipo de ficheros de audio. Si no queremos limitar el tipo de datos

que se quiere recibir escribiremos: */*. El formato para indicar la

calidad del recurso es: q=factor. Cuando factor es igual a 1

estamos indicando el 100% de la calidad.

El método GET y el encabezado Accept son los encabezados de

petición HTTP más comunes. Y dentro de los tipos MIME, los más

comunes son los de texto (text), audio (audio) e imágenes (image).

Los textos estándar dentro de Internet son html y plain, y para las

imágenes son válidos los formatos jpeg y gif.

RESPUESTA HTTP

El Servidor HTTP (Servidor de origen) responde a una petición http

con una respuesta http que incluye:

Una Línea de Estado de respuesta (a cual está comprendida

por la versión del protocolo HTTP y un código de éxito o de

error).

Los campos del encabezado de respuesta, que son un

conjunto de líneas opcionales que permiten aportar

información adicional sobre la respuesta y/o el Servidor.

Cada una de estas líneas está compuesta por un nombre

que califica el tipo de encabezado, seguido por dos puntos

(:) y por el valor del encabezado.

Un archivo de datos formateado en uno de los formatos

MIME estándares conteniendo información proporcionada

por el Servidor en el cuerpo de la respuesta a la petición.

Otra información de respuesta.

ENCABEZADOS DE RESPUESTA

Tablas Nº4

Nombre Descripción

Content-

Encoding Tipo de codificación para el cuerpo de la respuesta

37

Content-

Language Tipo de idioma en el cuerpo de la respuesta

Content-Length Extensión del cuerpo de la respuesta

Content-Type Tipo de contenido del cuerpo de la respuesta (por

ejemplo, texto/html).

Date Fecha en que comienza la transferencia de datos

Expires Fecha límite de uso de los datos

Forwarded Utilizado por equipos intermediarios entre el navegador y

el Servidor

Location Redireccionamiento a una nueva dirección URL

asociada con el documento

Server Características del Servidor que envió la respuesta


LOS CÓDIGOS DE RESPUESTA

Son los códigos que se ven cuando el navegador no puede mostrar

la página solicitada. El código de respuesta está formado por tres

dígitos: el primero indica el estado y los dos siguientes explican la

naturaleza exacta del error.

Tabla Nº5

Código Resultado Descripción

200 OK La petición se ha servido sin problemas

202 Accepted

La petición ha sido aceptada pero todavía

se está procesando.

301 Moved

El documento se ha trasladado a una

nueva localización.

302 Found

El documento está en el Servidor pero en

una localización diferente.

400 BadRequest La sintaxis de la petición es incorrecta.

38

401 Unauthorized

(AUTH_TYPE)

El Servidor tiene restricciones sobre este

documento.

403 Forbidden.

La petición se ha prohibido, debido a

derechos de accesos o por otras razones.

404 NotFound La petición no se ha podido encontrar.

500 Internal Error

El Servidor ha fallado inesperadamente al

intentar servir la petición

502 Serviceisoverloaded

El Servidor no puede procesar más

peticiones ahora.


2.2.2.2.3. HIPERTEXT MARKUP LANGUAGE (HTML-LENGUAJE DE

MARCAS DE HIPERTEXTO)

Es un lenguaje usado para formatear “documentos” para su

visualización el cual incluye comandos para recuperar texto,

imágenes y otros recursos en la World Wide Web.

HTML es una aplicación de SGML (Standard Generalized Markup

Language) el cual es un sistema para la organización y etiquetado

de documentos, este sirve para especificar las reglas de etiquetado

de documentos y no impone ningún conjunto de etiquetas en

especial.

El propósito principal del HTML era las referencias cruzadas entre

investigaciones científicas con hiperenlaces que daban acceso

directo a los documentos referidos.

En noviembre de 1995 se aprobó el estándar HTML 2.0 para la

creación de páginas web. Se creó con objetivos divulgativos,

orientado a la actividad académica, en el que el contenido de las

páginas era más importante que el diseño.

Pero esta versión del HTML carecía de muchas herramientas que

permitieran controlar el diseño de las páginas y añadir contenido

multimedia, por lo que Netscape (cuyos navegadores eran los más

utilizados por aquellos años) comenzó a incluir nuevas etiquetas

que no existían en el estándar.

39

El comité encargado de establecer los estándares dentro de

Internet, comenzó a trabajar en el borrador de una nueva versión

de HTML, el borrador de HTML 3.0.

Pero este borrador resultó demasiado extenso, al intentar incluir

numerosos nuevos atributos para etiquetas ya existentes, y la

creación de otras muchas etiquetas nuevas. Por ello, no fue bien

aceptado por el mercado y varias compañías se unieron para

formar un nuevo comité encargado de establecer los estándares

del HTML. Este comité pasó a llamarse W3C.

En enero de 1997 se aprobó el estándar HTML 3.2. Este nuevo

estándar incluía las mejoras proporcionadas por los navegadores

Internet Explorer y Netscape Navigator, que ya habían realizado

extensiones sobre el estándar HTML 2.0.

En diciembre de 1997 se aprobó el estándar HTML 4.0, creado

para estandarizar los marcos (frames), las hojas de estilo y los

scripts.

En septiembre de 2001 se aprobó el estándar HTML 4.01.

Una etiqueta HTML consiste en un signo menor "<", un nombre de

una directiva (orden o comando para el navegador), seguido de los

parámetros o atributos y un signo mayor ">". Para cualquier

etiqueta que indica un el inicio de un elemento hay otra de cierre

que indica que esa directiva ya no debe actuar sobre el texto que

sigue (en algunas ocasiones no es necesario poner, o no existe, la

etiqueta de cierre correspondiente).

<directiva parámetro="xxxx"> ...</directiva>

HTML no es sensible a mayúsculas y minúsculas. Para HTML es

equivalente <HTML> y <html>, con algunas excepciones. Aunque

es recomendable es escribir los nombres de las etiquetas en

minúsculas ya que las nuevas generaciones del HTML están

basadas en SGML que requiere de documentos bien formados:

Nombres de etiquetas y atributos en minúsculas.

Etiquetas de cierre para elementos no vacíos.

40

Los valores de los atributos deben estar incluidos entre

comillas dobles.

Por otro lado, otro subconjunto de SGML es el lenguaje XML, pero,

es al igual que su padre un metalenguaje, del cual se pueden

derivar muchos otros, XML es utilizado generalmente para diseñar

y construir documentos, administrar y transferir información. Y es

de esta posibilidad de donde nació un híbrido que se esperara

fuera un nuevo estándar de internet.

De la unión de estos dos lenguajes, HTML y XML es de donde

nació un nuevo estándar, del cual el W3C lanzó la recomendación

en el año 2000, en un intento por regresar al HTML así motivo e

idea principal que era la representación semántica de la

información. El W3C buscó revertir lo que las empresas habían

estado haciendo al tratar de convertir al HTML visual.

Sin embargo el resultado nunca dejó de cuajar ni ser el estándar

esperado, y para el año 2002 el grupo de trabajo en el W3C

dedicado al desarrollo y búsqueda de mejoras en el XHTML dejó

de funcionar teniendo en puerta la recomendación de XHTML 2.0.

El desarrollo continuó, sin embargo este se volvió irrelevante.

También en 2007 se reintento abrir el grupo encargado de XHTML

2.0 sin embargo volvió cerrar a tan solo 2 años después de su

creación.

ESTRUCTURA DE UN DOCUMENTO HTML

Todas las páginas web tienen la siguiente estructura:

<html>

<head>

<title>Primerapágina</title>

</head>

<body>

</body>

</html>

En la primera línea encontramos la etiqueta <html>. Esta le indica

al cliente que comienza un documento HTML.

41

Luego viene <head>, la cabecera, donde se pone información

sobre el documento, que no se ve en la pantalla del navegador.

Aquí puede ir el título <title> del documento, es lo que veremos

como título de la ventana en los navegadores que lo permitan y

como se conocerá nuestra página en algunos buscadores y en la

lista de favoritos de los usuarios (es importante pensar bien el título

del documento).

Tras la cabecera viene <body>, el cuerpo, que es donde se coloca

la información que queremos mostrar en la pantalla principal del

navegador.

2.2.2.3. LOS NAVEGADORES WEB

Cuando un documento HTML es visto usando un software de

navegación web (como Internet Explorer, Mozilla Firefox o Safari)

asume el formato de estilo gráfico que se le intentó dar para su

visualización posterior por parte del usuario (en vez del formato de

etiquetas del documento de texto/html original).

La funcionalidad básica de un navegador web es permitir la

visualización de documentos de texto, posiblemente con recursos

multimedia incrustados. Los documentos pueden estar ubicados en la

computadora en donde está el usuario, pero también pueden estar en

cualquier otro dispositivo que esté conectado a la computadora del

usuario o a través de Internet, y que tenga los recursos necesarios

para la transmisión de los documentos (un software Servidor web).

Tales documentos, comúnmente denominados páginas web, poseen

hipervínculos que enlazan una porción de texto o una imagen a otro

documento, normalmente relacionado con el texto o la imagen.

42

Fig. 11. El Navegador Web Internet Explorer 8

El seguimiento de enlaces de una página a otra, ubicada en cualquier

computadora conectada a la Internet, se llama navegación; que es de

donde se origina el nombre de navegador.

2.2.2.2.4. HISTORIA

EL PRIMER NAVEGADOR9

Desarrollado en el CERN a finales de 1990 y principios de 1991 por

Tim Berners-Lee, era bastante sofisticado y gráfico, pero sólo

funcionaba en estaciones NeXT.

MOSAIC10

Creado por el Centro Nacional de Aplicaciones de

Supercomputación (Universidad de Illinois, EE.UU.) fue el primer

navegador que popularizó el uso de la web. Cuando se publicó la

primera versión, en 1993, el acceso a Internet todavía estaba

limitado a Universidades y organismos gubernamentales. Cuando

en 1994, el acceso a Internet se abrió a particulares, el jefe del

proyecto y otros miembros del equipo se salieron de la Universidad

para crear Netscape. A partir de ese momento, aunque se

publicaron nuevas versiones en 1995 y 1997, Mosaic dejó de ser

importante. En 1997 el desarrollo de Mosaic se dio por terminado.

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

10HISTORIA DE LA WEB: NAVEGADORES, disponible en:

[http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadores.html]

43

NETSCAPE

Apareció en 1994 y hasta 1997 fue el navegador más popular, por

varios motivos:

Aunque en algún momento intentó ser un programa

comercial, siempre existieron versiones gratuitas con toda la

funcionalidad

Se publicaban versiones nuevas continuamente que eran

capaces de representar elementos cada vez más complejos

Antes de 1994 las empresas de comunicación no podían

ofrecer acceso a Internet, pero en su lugar ofrecían acceso a

comunidades cerradas a los clientes (la más grande era

entonces AOL, America On Line). A partir de 1994, las leyes

permitieron el acceso de particulares, pero las empresas

seguían sin cambiar el chip: por ejemplo hasta 1996

Microsoft no incluyó en Windows un navegador web, aunque

sí ofrecía acceso a una red privada llamada Microsoft

Network. Netscape aprovechó para situarse como la puerta

de entrada al nuevo mundo de la web.

A partir de 1996, en que Windows incluyó un navegador (Internet

Explorer) en Windows 95 OSR2, la cuota de mercado de Netscape

empezó a caer inexorablemente. En 1998, Netscape se rindió y

antes de abandonar el mercado fundó la fundación sin ánimo de

lucro Mozilla, para crear un navegador de software libre. En 1999

Netscape fue comprada por AOL (reconvertida ya en proveedor de

Internet), que a su vez se fusionó con Time Warner en 2000.

Aunque se siguieron publicando versiones de Netscape hasta

2008, desde el año 2000 Netscape es irrelevante.

Desde 2008, el desarrollo de Netscape se dio por terminado.

INTERNET EXPLORER

Microsoft presentó Internet Explorer en agosto de 1995, basándose

en una versión de Mosaic. Internet Explorer 1 no estaba incluido en

Windows 95, pero ante el éxito de Netscape y la creciente

popularidad de la web, Microsoft pisó el acelerador:

44

Se publicaron versiones prácticamente cada año: IE 2

(noviembre de 1995), IE 3 (agosto de 1996), IE 4

(septiembre de 1997), IE 5 (marzo de 1999), IE 5.5 (julio de

2000) e IE 6 (agosto de 2001).

IE se incluyó en Windows a partir de Windows 95 OSR1

(febrero de 1996), lo que dio lugar a demandas por abuso de

posición dominante en Estados Unidos y Europa.

Cada versión incluía nuevas características avanzadas,

superando a Netscape en muchos aspectos.

A partir del año 2000, Internet Explorer dominó absolutamente el

mercado y Microsoft pisó el freno:

Las versiones se espaciaron: Internet Explorer 6 SP1

(septiembre de 2002), Internet Explorer 6 SP2 (agosto de

2004).

Las nuevas versiones no incluían prácticamente nuevas

características.

En 2003, Microsoft llegó a anunciar que sólo habría nuevas

versiones de Internet Explorer cuando hubiera nuevas

versiones de Windows.

A partir de 2005, ante la aparición de Firefox, Microsoft volvió a

pisar el acelerador, aunque su uso global ha ido bajando desde

entonces:

Se fueron publicando nuevas versiones a un ritmo cada vez

más rápido: IE 7 (octubre de 2006), IE 8 (marzo de 2009) e

IE 9 (marzo de 2011).

Las nuevas versiones volvieron a incluir características

avanzadas y, sobre todo, respeto a las recomendaciones del

W3C.

Tanto IE 7 como IE 8 estuvieron disponibles para Windows

XP, probablemente debido al fracaso de Windows Vista

como sustituto de Windows XP. Durante el primer año de IE

7, para instalarlo era necesario validar Windows, pero desde

entonces esa limitación no se ha vuelto a utilizar.

45

A partir de 2011, confirmado el éxito de Windows 7 como sustituto

de Windows XP, Microsoft volvió a vincular el navegador con el

sistema operativo e Internet Explorer 9 ya no se publicó para

Windows XP. Para Windows XP, Microsoft promueve el uso de IE 8

e incluso creó en marzo de 2011 la web

http://WWW.ie6countdown.com/ para promover la desaparición de

IE6.

El 26 de octubre del 2012 Microsoft ha publicado Internet Explorer

10, incluyéndolo en Windows Server 2012 y Windows 8.

Actualmente (noviembre 2012) el 13 de noviembre salió una

versión preliminar para Windows 7 SP1 pero no se sabe cuándo se

publicará la versión final.

OPERA

Es un navegador que comenzó en 1994 como proyecto de

investigación de Telenor, una compañía telefónica Noruega, pero

que desde 1995 desarrolla la compañía Opera Software. La

primera versión, Opera 2.1, se publicó en diciembre de 1996 y

desde entonces ha ido publicando versiones tanto para PCs como

para dispositivos móviles.

Su principal característica ha sido siempre el cumplimiento de las

recomendaciones del W3C (no en vano Håkon Wium Lie, uno de

los padres de las hojas de estilo, pertenece a esta compañía).

Hasta el año 2000 se trataba de un navegador de pago (con

versión de prueba temporal), pero desde entonces es gratuito.

Nunca ha tenido una gran cuota de mercado, salvo en dispositivos

móviles, donde siempre ha sido bastante utilizado (aunque la

competencia de Safari y Android están reduciendo esa

importancia).

MOZILLA

Mozilla era el apodo del navegador Netscape dentro de la misma

empresa Netscape. En enero de 1998 Netscape anunció que

46

liberaba el código fuente de su navegador y el proyecto de

continuar el desarrollo de ese código recibió el nombre de Mozilla.

Tras unos comienzos titubeantes en los que hubo que desechar

gran parte del código, a partir de 1999 se empezaron a publicar

numerosas versiones (el lema era "release early, release often", es

decir "publica pronto, publica a menudo") de la suite Mozilla, que

incluía tanto el navegador como el cliente de correo electrónico, un

programa de chat o un editor. Desde el primer momento, el objetivo

era implementar fielmente las recomendaciones del W3C. En junio

de 2002 se publicó por fin Mozilla 1.0.

Durante esos años, la financiación del proyecto provenía de AOL,

que utilizaba Mozilla como base para las versiones de Netscape

que siguieron publicándose durante unos años. Pero en mayo de

2003 AOL alcanzó un acuerdo con Microsoft para poner fin a las

demandas por abuso de posición dominante. Microsoft pagó a AOL

750 millones de dólares y, a cambio, AOL pasó a utilizar Internet

Explorer en vez de Netscape. AOL anunció entonces que dejaría

de financiar el desarrollo de Mozilla.

Para poder continuar el desarrollo de Mozilla, se creó en 2004 la

Mozilla Foundation, fundación sin ánimo de lucro, que recibe la

mayor parte de sus ingresos de Google.

De 2002 a 2004 todavía se siguieron publicando numerosas

versiones de Mozilla, pero se decidió separar (seguramente por

influencia de Google, entre otros factores) los componentes de

Mozilla y publicarlos como programas separados (el navegador

Firefox, el cliente de correo electrónico Firebird, etc.). Mozilla 1.7, la

última versión de Mozilla, se publicó en junio de 2004 y Firefox 1.0,

la primera versión de Firefox, se publicó en noviembre de 2004.

Posteriormente un grupo de programadores crearon SeaMonkey,

un programa que incluye navegador, cliente de correo, cliente de

chat, etc., como hacía Mozilla. SeaMonkey está basada en Firefox

y Thunderbird y el proyecto, aunque no forma parte de la

Fundación Mozilla, se aloja en sus Servidores.

Desde 2005, el desarrollo de Mozilla se dio por terminado.

47

FIREFOX

Firefox es el navegador creado por la Fundación Mozilla y es

continuación del navegador Mozilla, que a su vez es continuación

del navegador Netscape. Firefox 1.0 se publicó en noviembre de

2004 y su objetivo es permitir que la web sea pública, abierta y

accesible.

Además de cumplir las recomendaciones del W3C (no solamente

respecto al HTML y a CSS, sino también SVG o MathML), Firefox

pone el énfasis en la usabilidad (pestañas, interface, etc.),

facilitando además la personalización y ampliación a través de

extensiones.

Es el navegador que ha conseguido acabar con la dominación

absoluta de Internet Explorer y permitir que resurja la innovación en

la web. A partir de 2005, Firefox se convirtió en el navegador

alternativo a Internet Explorer y su uso creció hasta casi el 25% a

principios de 2009. Sin embargo la aparición de Google Chrome

por esas fechas detuvo su crecimiento y actualmente (noviembre

de 2011) se ha reducido a un 21%.

Entre 2005 y 2011 Firefox publicó nuevas versiones más o menos

una vez al año. A partir de Firefox 5 (junio de 2011), Firefox tomó

un modelo de desarrollo similar a Chrome y se publican nuevas

versiones cada 6 semanas, para hacer llegar rápidamente a los

usuarios las nuevas funcionalidades.

Este modelo de desarrollo rápido crea conflictos en los entornos

empresariales, en los que se utiliza una misma versión de los

programas durante mucho tiempo. La solución ofrecida ha sido

crear una versión ESR (Extended Support Release), que se

publicará cada siete versiones de Firefox (7x6 = 42 semanas). La

primera versión ESR fue Firefox 10 y las siguientes serán Firefox

17, Firefox 24, etc. El tiempo dirá si este plazo, inferior a un año, es

adecuado para los entornos empresariales.

Este modelo de desarrollo rápido también crea conflictos para los

creadores de extensiones, ya que los cambios internos de cada

versión pueden hacer que cualquier extensión deje de funcionar.

48

Este problema se agravaba en las primeras versiones porque

Firefox suponía que las extensiones eran incompatibles si no se

habían actualizado, pero a partir de Firefox 10, Firefox supone que

las extensiones son compatibles salvo que se indique lo contrario

en la web de extensiones.

El desarrollo de Firefox está financiado principalmente por Google,

a través de donaciones a la Fundación Mozilla. A cambio, la página

de inicio inicial de Firefox es la página web de Google. Cuando

Google comenzó a publicar en 2008 su propio navegador (Chrome)

surgieron dudas sobre la continuidad de esas donaciones, pero en

agosto de 2008 el acuerdo se renovó hasta noviembre de 2011 y

en diciembre de 2011 se renovó hasta noviembre de 2014.

SAFARI

Hasta 2003 el sistema operativo Mac de Apple no disponía de su

propio navegador web, sino que incluía Netscape o Internet

Explorer, pero en junio de 2003 Apple publicó Safari 1.0 para Mac

OS X. Safari utiliza el motor de renderizado WebKit, desarrollado

por Apple a partir del motor de renderizado KHTML del proyecto de

software libre KDE.

Desde 2003 Apple publica nuevas versiones de Safari cada año

(en los últimos años en el mes de junio). Aunque existen versiones

de Safari para Windows, su uso es irrelevante.

CHROME

Chrome es un navegador creado en 2008 por Google a partir de

WebKit, el motor de renderizado del navegador Safari. Tiene un

ritmo de desarrollo muy rápido, aunque no se publica a intervalos

regulares, como Firefox. La versión 1.0 se publicó en diciembre de

2008, actualmente (Noviembre de 2012) 6 de noviembre de 2012

ya va por la versión 23. Ha destacado siempre por su interfaz

minimalista y por la velocidad de ejecución del código JavaScript, lo

que obligó a Firefox y a Internet Explorer a mejorar estos aspectos.

49

Chrome ha vuelto a poner sobre la mesa el eterno debate entre la

superioridad de las aplicaciones locales y remotas. Gracias a

Chrome algunos ven técnicamente posible que el navegador se

convierta en la única aplicación del ordenador, con todos los datos

en Internet y las aplicaciones ejecutándose en HTML5 y JavaScript.

Otros recuerdan que más o menos esa fue ya la promesa de Java

hace 15 años, que no se cumplió. En cualquier caso, los próximos

años prometen ser apasionantes.

2.2.2.2.5. LA GUERRA DE LOS NAVEGADORES11

En 1994, la primera versión del navegador Netscape salió al

mercado, escrita por los inventores del navegador Mosaic. En

1996, se introdujo Netscape 2 con nuevas características: frames y

JavaScript.

Con Netscape 3 JavaScript 1.1 se volvió un estándar,

estandarizado por la ECMA (European Computer Manufacturers

Association) como ECMAScript.

En 1997 se estableció DHTML (Dynamic HTML) con la salida de

Netscape 4. Este incluía más etiquetas HTML y partes del estándar

de la W3C (World Wide Web Consortium) CSS 1 (Cascading Style

Sheets). En combinación con CSS 2 y JavaScript 1.2 se podía

modificar la posición, estilo y visibilidad de una página.

En 1997 apareció el concepto de layer (capa) introducido por el

navegador Microsoft Internet Explorer 4 que incluía muchas

características no estándar para competir con su rival Netscape

Navigator.

Los años posteriores las tecnologías citadas anteriormente se

convirtieron más avanzadas. Microsoft Internet Explorer fue incluido

directamente como parte del sistema operativo “Microsoft

Windows”, convirtiéndose de esta manera en el navegador más

utilizado.

11

FLORIAN MORITZ, Rich Internet Applications (RIA):A Convergence of User Interface Paradigms of Web and Desktop

Exemplified, 2008

50

Cada navegador, Netscape e Internet Explorer, utilizaban

tecnologías diferentes, las cuales no estaban estandarizadas e

implementaban incorrectamente los estándares establecidos. Esta

falta de estandarización hacía la programación para los

desarrolladores web difícil. El año 2000 con la salida de Opera 4

nace el primer navegador que cumple los estándares de la W3C.

En el año 2001 se libera Internet Explorer 6, pero su soporte CSS

era inferior comparado al Motor Gecko. El motor Gecko es un

motor de disposición para el manejo de HTML y CSS, el cual fue

publicado el 2002. Basado en este motor apareció un proyecto

Open Source denominado Mozilla. Más tarde el grupo Mozilla

produjo el navegador Mozilla Firefox con mucho éxito.

Otro navegador importante es Safari, desarrollado por Apple Inc.;

también el reciente Google Chrome lanzado el 2008 desarrollado

por Google. Cabe destacar que ambos navegadores utilizan el

motor de renderizado Webkit.

Microsoft detuvo el desarrollo de su navegador por años, hasta el

2006, año en el que libera Internet Explorer 7, esta versión

implementa mejoras en funcionalidad, estabilidad y compatibilidad

entre aplicaciones que usan CSS. El 2009 lanza Internet Explorer

8.

El 2009 también fue lanzada La versión 3.5 de Mozilla Firefox

(antes numerada como la versión 3.1). Es compatible con la

etiqueta <video> cómo define la especificación HTML 5; en el cual

incluye compatibilidad nativa con los códecs libres OggTheora y

OggVorbis. Esta versión incluye características que no pudieron ser

desarrolladas a tiempo para Firefox 3.

2.2.2.2.6. FUNCIONAMIENTO

La gran mayoría de los navegadores cuentan con un campo de

dirección donde el usuario escribe las direcciones web, que

vendrían a ser las Líneas de Petición en formato HTTP, al

presionar la tecla “Enter” activan el hiperenlace (que activa el

agente de usuario o navegador). La primera acción tomada por el

51

navegador es la resolución DNS del nombre de dominio a su

dirección IP equivalente. Una vez que la dirección ha sido resuelta

el navegador establece una conexión TCP a esta dirección y el

protocolo HTTP es usado para localizar y recuperar el archivo

HTML solicitado. Una vez recibido el navegador web muestra cada

uno de los elementos del documento HTML. A medida que el

usuario interactúa con los hiperenlaces del documento, un nuevo

proceso comienza nuevamente que involucra al DNS, TCP/IP y

HTTP12

La mayoría de los navegadores soportan otros protocolos

como FTP, Gopher y HTTPS (una versión cifrada de HTTP basada

en Secure Socket Layer o Capa de Conexión Segura (SSL)).

A pesar de que la función principal del navegador es descargar

documentos HTML y mostrarlos en pantalla, en la actualidad, no

solamente descargan este tipo de documentos sino que muestran

con el documento sus imágenes, sonidos e incluso

vídeos streaming en diferentes formatos y protocolos. Además,

permiten almacenar la información en el disco o

crear marcadores (bookmarks) de las páginas más visitadas.

Los primeros navegadores web sólo soportaban una versión muy

simple de HTML. El rápido desarrollo de los navegadores web

propietarios condujo al desarrollo de dialectos no estándares de

HTML y a problemas de interoperabilidad en la web. Los más

modernos (como Amaya, Mozilla, Netscape, Opera y versiones

recientes de Internet Explorer) soportan los estándares HTML

y XHTML (comenzando con HTML 4.01, los cuales deberían

visualizarse de la misma manera en todos ellos)13

Actualmente el navegador más utilizado en el mundo es Google

Chrome, seguido en esta clasificación por Internet Explorer y

Mozilla Firefox según los datos de Statcounter.

12

MARTIN P. CLARK. DATA NETWORKs, IP and the Internet: Protocols, Design and Operation. John Wiley& Sons, Ltd., 2003 :

479 13

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

52

Fig. 12. Cuota de Navegadores Web.

Fuente: http://es.wikipedia.org/wiki/Mozilla_Firefox

2.2.2.4. APLICACIONES WEB

Se denomina aplicaciones web a aquellas aplicaciones que los

usuarios pueden utilizar accediendo a un Servidor web a través de

Internet o de una intranet mediante un navegador. En otras palabras,

son aplicaciones que se codifican en distintos lenguajes (Java, C#,

PHP, ColdFusion, etc.) y más tarde son compiladas o interpretadas

por el Servidor de aplicaciones que genera una salida HTML la cual

es mostrada por el navegador.

http://es.wikipedia.org/wiki/Servidor_web

http://es.wikipedia.org/wiki/Internet

http://es.wikipedia.org/wiki/Intranet

http://es.wikipedia.org/wiki/Navegador_web

53

Fig. 13. Ejemplo de una aplicación web multicapa



2.2.3. TECNOLOGIAS DEL LADO DEL SERVIDOR

Las empresas no se habían dado cuenta aún sobre el qué hacer con

este nuevo “canal”. De hecho, al comienzo de la World Wide Web, las

páginas web corporativas frecuentemente mostraban solo información

de contacto y alguna documentación. Sin embargo, no paso mucho

tiempo para que los usuarios web desearan una experiencia mucho

más dinámica, en la cual el contenido de las páginas cambia de

acuerdo al tiempo, a las preferencias del usuario y miles de otros

atributos. El paso inmediatamente posterior en la evolución de las

aplicaciones web fue la inclusión de un método para elaborar páginas

dinámicas que permitieran que lo mostrado tuviese carácter dinámico

(es decir, generado a partir de los datos de la solicitud).

54

2.2.2.5. COMMON GATEWAY INTERFACE(CGI)14

Brindaba los mecanismos necesarios para generar contenido

dinámico ejecutando procesos (ejecutables) en los Servidores web

que generaban contenido HTML, el cual era devuelto al usuario;

funcionaba de la siguiente manera:

El navegador del usuario envía una solicitud como si fuera para

una página HTML.

El Servidor web reconoce que el recurso solicitado corresponde

a un programa externo.

El Servidor web ejecuta el programa externo, pasándole a este

la solicitud HTTP recibida del navegador del usuario.

El programa externo realiza el procesamiento y envía los

resultados (HTML) al Servidor.

El Servidor web envía la salida del programa externo hacia el

navegador como una respuesta HTTP.

CGI gozó de una popularidad enorme en los inicios de la Web

como medio de generación de contenido dinámico. Sin

embargo a medida que la Web crecía en popularidad, el tráfico

hacia los sitios web también crecía. Debido a muchas

deficiencias CGI no era suficiente para soportar esa carga.

Afortunadamente con el paso de los años surgieron muchas

alternativas de solución a CGI, que resolvían sus limitaciones.

En la actualidad aunque existen muchas variaciones posibles,

una aplicación web está normalmente estructurada como una

aplicación de tres-capas. En su forma más común, el

navegador web ofrece la primera capa; un motor capaz de usar

alguna tecnología web dinámica (ejemplo: PHP, Java Servlets

o ASP, ASP.NET, ColdFusion, Perl, Python o Ruby) constituye

la capa de intermedia. Por último, una base de datos constituye

la tercera y última capa.

14

JAYSON FALKNER, KEVIN JONEs, Servlets and Java Server Pages™: The J2EE™ Technology Web Tier. Addison Wesley,

2003

http://es.wikipedia.org/wiki/PHP

http://es.wikipedia.org/wiki/Active_Server_Pages

http://es.wikipedia.org/wiki/ASP.NET

http://es.wikipedia.org/wiki/ColdFusion

http://es.wikipedia.org/wiki/Ruby_on_Rails

55

El navegador web manda peticiones a la capa de intermedia

que ofrece servicios valiéndose de consultas y actualizaciones

a la base de datos y a su vez proporciona una interfaz de

usuario.

2.2.2.6. SERVLET CONTAINERS, SERVLETS Y JSP 1.

2.2.2.2.7. SERVLETS CONTAINERS15

Es un Servidor web especializado que soporta la ejecución de

Servlets, combina la funcionalidad básica de un Servidor web con

un ambiente de ejecución Java y se encarga de gestionar el ciclo

de vida de cada Servlet que tiene registrado. Provee de un

ambiente de ejecución para todos los Servlets en el Servidor.

2.2.2.2.8. JAVA SERVLETS16 .

En el mundo Java, los Servlets fueron diseñados para resolver los

problemas de CGI y crear ambientes robustos del lado del Servidor

para los desarrolladores Web, basados en la plataforma Java. De

manera similar a CGI, los Servlets permiten que una solicitud sea

procesada por un programa y que este produzca una respuesta

dinámica. Adicionalmente definen un ciclo de vida eficiente que

maneja de manera óptima las solicitudes. Los Servlets sirven de

base para otras tecnologías Java como JSP (Java Server Pages).

Los Servlets no son aplicaciones, y tienen que ser cargados en

memoria por un ServletContainer. El ServletContainer funciona

como un Servidor web, recibiendo las solicitudes HTTP de los

navegadores web y enviándolas luego a los Servlets para generar

una respuesta, que generalmente es un documento HTML.

2.2.2.2.9. JSP.

Para ayudar a facilitar la creación de contenido dinámico, Sun

introdujo JSP (Java Server Pages). Una página JSP en realidad

cuando es procesada por un ServletContainer es convertida en un

15

DEFINICIÓN DE SERVLETCONTAINERS, Disponible en: [http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers] 16

JAYSON FALKNER, KEVIN JONES, Servlets and Java Server Pages™: The J2EE™ Technology Web Tier. Addison Wesley,

2003

56

Servlet que luego es ejecutado por este. Pero a diferencia de los

Servlets una página JSP puede contener código HTML a manera

de una página web tradicional y también elementos especiales JSP

que permiten insertar contenido dinámico en la página.

2.2.2.7. ASP NET17

Es un componente central de Microsoft .NET Framework18 y

proporciona la infraestructura para aplicaciones Web .NET

dinámicas desarrolladas fácilmente. ASP.NET no sólo sucede a

Microsoft Active Server Pages (ASP), es una plataforma de

desarrollo Web unificada que proporciona los servicios necesarios

a los desarrolladores para generar aplicaciones Web

empresariales. ASP.NET proporciona grandes mejoras con

respecto a ASP tradicional e incluye muchas características

nuevas.

ASP.NET está construido sobre el Common Language Runtime19,

permitiendo a los programadores escribir código ASP.NET usando

cualquier lenguaje admitido por el .NET Framework. ASP.NET

proporciona la habilidad de crear y utilizar controles UI

reutilizables que pueden encapsular una funcionalidad común y,

por tanto, reducir la cantidad de código que el desarrollador tiene

que escribir, la habilidad de los desarrolladores para estructurar

de forma clara las páginas en un estilo ordenado, y la habilidad de

las herramientas de desarrollo de proporcionar un potente soporte

de diseño WYSIWYG20 para las páginas.

17

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

NET FRAMEWORK :es el modelo de programación de código administrado de Microsoft para la creación de aplicaciones en

clientes de Windows, Servidores y dispositivos móviles o incrustados. Los desarrolladores pueden usar .NET para crear muchos

tipos de aplicaciones: aplicaciones web, de Servidor, de cliente inteligente, de consola, de bases de

datos.[http://msdn.microsoft.com/es-pe/netframework/default.aspx] 19

COMMON LANGUAGE RUNTIME :es un entorno en tiempo de ejecución que ejecuta el código y proporciona servicios que

facilitan el proceso de desarrollo [http://msdn.microsoft.com/es-pe/library/8bs2ecf4.aspx] 20

WYSIWYG. (What You See Is What You Get). Término utilizado para describir un sistema en el cual el contenido mostrado

durante la edición es muy similar al resultado final. [http://en.wikipedia.org/wiki/WYSIWYG]

http://msdn.microsoft.com/es-pe/netframework/default.aspx

57

2.2.2.8. PHP21

Es un lenguaje interpretado de propósito general ampliamente usado

y que está diseñado especialmente para desarrollo web y puede ser

incrustado dentro de código HTML. Generalmente se ejecuta en un

Servidor web, tomando el código en PHP como su entrada y creando

páginas web como salida.

El gran parecido que posee PHP con los lenguajes más comunes de

programación estructurada, como C y Perl, permiten a la mayoría de

los programadores crear aplicaciones web con una curva de

aprendizaje muy corta.

Cuando el cliente hace una petición al Servidor para que le envíe una

página web, el Servidor ejecuta el intérprete de PHP. Este procesa el

script solicitado que generará el contenido de manera dinámica (por

ejemplo obteniendo información de una base de datos). El resultado

es enviado por el intérprete al Servidor, quien a su vez se lo envía al

cliente.

2.2.2.9. COLDFUSION

Adobe Coldfusion es un Servidor de aplicaciones y un lenguaje de

programación usado para desarrollar aplicaciones de Internet,

generalmente sitios web generados dinámicamente. En este aspecto,

es un producto similar a ASP.NET, JSP o PHP.

Las partes dinámicas de una página ColdFusion son generadas

insertando elementos de marcado similares a HTML o XML en una

página web, estos elementos son conocidos como ColdFusion Markup

Language (CFML), el cual es el lenguaje con el que se desarrollan

aplicaciones web en ColdFusion.

CFML incluye una gran cantidad de etiquetas que se asemejan a

elementos encontrados en otros lenguajes de programación, así como

etiquetas para realizar tareas de acceso a base de datos, archivos,

correo, generación de PDF, etc.

21DEFINICIÓN DE PHP , disponible en: [http://es.wikipedia.org/wiki/PHP]

58

Coldfusion es una aplicación web Java, que se puede desplegar sobre

un contenedor de Servlets o un Servidor de Aplicaciones Java JEE,

también posee un Servidor JEE incorporado denominado JRun.

2.2.4. TECNOLOGIAS DEL LADO DEL CLIENTE22

Todo comenzó con una simple versión de HTML propuesta para crear

la estructura básica de páginas web, organizar su contenido y

compartir información. El lenguaje y la web misma nacieron

principalmente con la intención de comunicar información por medio

de texto.

El limitado objetivo de HTML motivó a varias compañías a desarrollar

nuevos lenguajes y programas para agregar características a la web

nunca antes implementadas. Estos desarrollos iniciales crecieron

hasta convertirse en populares y poderosos accesorios. Simples

juegos y bromas animadas pronto se transformaron en sofisticadas

aplicaciones, ofreciendo nuevas experiencias que cambiaron el

concepto de la web para siempre.

De las opciones propuestas, Java y Flash fueron las más exitosas;

ambas fueron masivamente adoptadas y ampliamente consideradas

como el futuro de Internet. Sin embargo, tan pronto como el número

de usuarios se incrementó e Internet pasó de ser una forma de

conectar amantes de los ordenadores a un campo estratégico para los

negocios y la interacción social, limitaciones presentes en estas dos

tecnologías probaron ser una sentencia de muerte.

El mayor inconveniente de Java y Flash puede describirse como una

falta de integración. Ambos fueron concebidos desde el principio

como complementos (plugins), algo que se inserta dentro de una

estructura pero que comparte con la misma solo espacio en la

pantalla. No existía comunicación e integración alguna entre

aplicaciones y documentos.

La falta de integración resultó ser crítica y preparó el camino para la

evolución de un lenguaje que comparte espacio en el documento con

HTML y no está afectado por las limitaciones de los plugins. 22

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

59

JavaScript, un lenguaje interpretado incluido en navegadores,

claramente era la manera de mejorar la experiencia de los usuarios y

proveer funcionalidad para la web. Sin embargo, después de algunos

años de intentos fallidos para promoverlo y algunos malos usos, el

mercado nunca lo adoptó plenamente y pronto su popularidad declinó.

Los detractores tenían buenas razones para oponerse a su adopción.

En ese momento, JavaScript no era capaz de remplazar la

funcionalidad de Flash o Java. A pesar de ser evidente que ambos

limitaban el alcance de las aplicaciones y aislaban el contenido web,

populares funciones como la reproducción de video se estaban

convirtiendo en una parte esencial de la web y solo eran

efectivamente ofrecidas a través de estas tecnologías.

A pesar del suceso inicial, el uso de Java comenzó a declinar. La

naturaleza compleja del lenguaje, su evolución lenta y la falta de

integración disminuyeron su importancia hasta el punto en el que hoy

día no es más usado en aplicaciones web de importancia. Sin Java, el

mercado volcó su atención a Flash. Pero el hecho de que Flash

comparte las mismas características básicas que su competidor en la

web lo hace también susceptible de correr el mismo destino.

Mientras esta competencia silenciosa se llevaba a cabo, el software

para acceder a la web continuaba evolucionando. Junto con nuevas

funciones y técnicas rápidas de acceso a la red, los navegadores

también mejoraron gradualmente sus intérpretes JavaScript. Más

potencia trajo más oportunidades y este lenguaje estaba listo para

aprovecharlas.

En cierto punto durante este proceso, se hizo evidente para algunos

desarrolladores que ni Java o Flash podrían proveer las herramientas

que ellos necesitaban para crear las aplicaciones demandadas por un

número creciente de usuarios. Estos desarrolladores, impulsados por

las mejoras otorgadas por los navegadores, comenzaron a aplicar

JavaScript en sus aplicaciones de un modo nunca visto. La innovación

y los increíbles resultados obtenidos llamaron la atención de más

programadores. Pronto lo que fue llamado la "Web 2.0" nació y la

percepción de JavaScript en la comunidad de programadores cambió

60

radicalmente.

JavaScript era claramente el lenguaje que permitía a los

desarrolladores innovar y hacer cosas que nadie había podido hacer

antes en la web. En los últimos años, programadores y diseñadores

web alrededor del mundo surgieron con los más increíbles trucos para

superar las limitaciones de esta tecnología y sus iniciales deficiencias

en portabilidad. Gracias a estas nuevas implementaciones,

JavaScript, HTML y CSS se convirtieron pronto en la más perfecta

combinación que pronto seria llamada HTM5, quien terminaría por

desplazar progresivamente a las soluciones basadas en plugins

existentes hasta ese momento como Applet Java, Adobe Flex y

Microsoft Silverlight.

2.2.4.1. APPLET JAVA23

En Java, un Applet24 es un programa que puede incrustarse en un

documento HTML, es decir en una página web. Cuando un navegador

carga una página web que contiene un Applet, este se descarga en el

navegador web y comienza a ejecutarse. Esto permite crear

programas que cualquier usuario puede ejecutar con tan solo cargar

la página web en su navegador.

El navegador que carga y ejecuta el Applet se conoce en términos

genéricos como el "contenedor" de los Applets. El kit de desarrollo de

software para Java Standard Edition 7 (1.7.1 --Versión más actual,

puesta en marcha el 18 de octubre de 2011) incluye un contenedor de

Applets, llamado appletviewer, para probar los Applets antes de

incrustarlos en una página web.

Los Applet java pueden hacer uso de diferentes tecnologías creadas

para el renderizado de interfaz gráfica como AWT, Swing y JavaFX.

Así como también las diferentes implementaciones de formatos de

socialización de datos para comunicación con el Servidor, como

Json, Json-RPC, Xml-Rpc, etc.

23

DEFINICIÓN DE APPLET JAVA, disponible en [http://es.wikipedia.org/wiki/Applet_Java] 24

DEFINICIÓN DE APPLET, disponible en [ http://es.wikipedia.org/wiki/Applet]

61

2.2.4.1.1. AWT25

La Abstract Window Toolkit (AWT, en español Kit de Herramientas

de Ventana Abstracta) es un kit de herramientas de gráficos,

interfaz de usuario, y sistema de ventanas independiente de la

plataforma original de Java. AWT es ahora parte de las Java

Foundation Classes (JFC) - la API estándar para suministrar una

interfaz gráfica de usuario (GUI) para un programa Java.

Cuando Sun Microsystems liberó Java en 1995, AWT suministró

solo un nivel de abstracción muy fino sobre la interfaz de usuario

nativa subyacente. Por ejemplo, crear una caja de verificación AWT

causaría que AWT directamente llame a la subrutina nativa

subyacente que cree una caja de verificación. Sin embargo, una

caja de verificación en Microsoft Windows no es exactamente lo

mismo que una caja de verificación en Mac OS o en los distintos

tipos de UNIX.

Algunos desarrolladores de aplicaciones prefieren este modelo

porque suministra un alto grado de fidelidad al kit de herramientas

nativo subyacente y mejor integración con las aplicaciones nativas.

En otras palabras, un programa GUI escrito usando AWT parece

como una aplicación nativa Microsoft Windows cuando se ejecuta

en Windows, pero el mismo programa parece una aplicación nativa

Apple Macintosh cuando se ejecuta en un Mac, etc. Sin embargo,

algunos desarrolladores de aplicaciones desprecian este modelo

porque prefieren que sus aplicaciones se vean exactamente igual

en todas las plataformas.

2.2.4.1.2. SWING26

Las Internet Foundation Classes (IFC) eran una biblioteca gráfica

para el lenguaje de programación Java desarrollada originalmente

por Netscape y que se publicó en 1996.

25

DEFINICIÓN DE AWT, Disponible en:[http://es.wikipedia.org/wiki/Abstract_Window_Toolkit] 26

DEFINICIÓN DE SWING, Disponible en:[ http://es.wikipedia.org/wiki/Swing_(biblioteca_gráfica])

62

Desde sus inicios el entorno Java ya contaba con una biblioteca de

componentes gráficos conocida como AWT. Esta biblioteca estaba

concebida como una API estandarizada que permitía utilizar los

componentes nativos de cada sistema operativo. Entonces una

aplicación Java corriendo en Microsoft Windows usaría el botón

estándar de Windows y una aplicación corriendo en UNIX usaría el

botón estándar de Motif. En la práctica esta tecnología no funcionó:

Al depender fuertemente de los componentes nativos del sistema

operativo el programador AWT estaba confinado al máximo

denominador común entre ellos. Es decir que sólo se disponen en

AWT de las funcionalidades comunes en todos los sistemas

operativos.

El comportamiento de los controles varía mucho de sistema a

sistema y se vuelve muy difícil construir aplicaciones portables. Fue

por esto que el eslogan de Java "Escríbalo una vez, ejecútelo en

todos lados" fue parodiado como "Escríbalo una vez, pruébelo en

todos lados".

En cambio, los componentes de IFC eran mostrados y controlados

directamente por código Java independiente de la plataforma. De

dichos componentes se dice con frecuencia que son componentes

ligeros, dado que no requieren reservar recursos nativos del

sistema de ventanas del sistema operativo. Además al estar

enteramente desarrollado en Java aumenta su portabilidad

asegurando un comportamiento idéntico en diferentes plataformas.

En 1997, Sun Microsystems y Netscape Communications

Corporation anunciaron su intención de combinar IFC con otras

tecnologías de las Java Foundation Classes. Además de los

componentes ligeros suministrados originalmente por la IFC, Swing

introdujo un mecanismo que permitía que el aspecto de cada

componente de una aplicación pudiese cambiar sin introducir

cambios sustanciales en el código de la aplicación. La introducción

de soporte ensamblable para el aspecto permitió a Swing emular la

apariencia de los componentes nativos manteniendo las ventajas

de la independencia de la plataforma. También contiene un

63

conjunto de herramientas que nos permiten crear una interfaz

atractiva para los usuarios.

2.2.4.1.3. JAVAFX

En 2005, Sun Microsystems adquirió la compañía SeeBeyond, en

la que un ingeniero de software de nombre de Chris Oliver creó un

lenguaje rico en gráficos de secuencias de comandos conocido

como F3 (Form Follows Function). F3 lenguaje que más tarde fue

presentado por Sun Microsystems como JavaFX en la conferencia

JavaOne 2007.

Posteriormente Oracle Corporation anunció la adquisición de Sun

Microsystems, con lo que Oracle se convirtió en el nuevo

administrador de JavaFX, la misma que volvió a crear esta

tecnología desde cero, basada en el lenguaje java eliminando de

esta manera el lenguaje de script JavaFX.

Con estos cambios JavaFX se convertiría en la próxima generación

de herramientas para el desarrollador y construcción de

aplicaciones multiplataforma con interfaces gráfica enriquecidas de

usuario (GUI),

Proporciona a través de gráficos acelerados por hardware y diseño

de interfaces de programación que permiten a los desarrolladores

combinar gráficos, animaciones, y los controles de interfaz de

usuario.

JavaFX 2.0 API puede ser utilizado por los diferentes lenguajes

que ejecutan en la máquina virtual Java (Visage, Jython, Groovy,

JRuby, y Scala).

2.2.4.2. AJAX27

AJAX es acrónimo de Asynchronous JavaScript and XML. El elemento

clave es su naturaleza asíncrona. En pocas palabras, AJAX es una

técnica para realizar llamadas asíncronas en segundo plano mediante

JavaScript y solicitar datos adicionales cuando sean necesarios,

27

BOGDAN BRINZAREA-IAMANDI, Cristian Darie, Audra Hendrix, AJAX and PHP Building Modern Web Applications, 2nd

Edition, Packt Publishing, 2009.

64

actualizando porciones de la página web sin provocar refrescos de

página.

AJAX permite la comunicación entre el cliente y el Servidor mientras

el usuario está utilizando la página web. Es necesario enfatizar que

AJAX es una técnica del lado del cliente, trabaja con cualquier

tecnología del lado del Servidor.

Junto con JavaScript, se necesita cierta familiaridad con otras

tecnologías como HTML, DOM y CSS. Estas tecnologías son

implementadas por todos los navegadores web de hoy en día, no se

requiere que el cliente instale componentes extras para visualizar un

sitio web AJAX.

JavaScript, el ingrediente esencial de AJAX, permite

implementar la funcionalidad del lado del cliente. En las

funciones JavaScript utilizamos el DOM (Document Object

Model) que nos permite manipular partes de la página HTML.

El objeto XMLHttpRequest, que permite realizar llamadas

asíncronas al Servidor en segundo plano mediante JavaScript.

A excepción de aplicaciones simples, se requiere de una

tecnología del lado del Servidor que recepcionen las solicitudes

del lado del cliente JavaScript.

El código del cliente JavaScript y el código del lado del Servidor

requieren de una manera de pasar datos y recibirlos respectivamente.

El objeto XMLHttpRequest permite enviar valores utilizando

solicitudes HTTP mediante métodos GET y POST. Por lo cual es muy

fácil interpretar estos datos con cualquier script del lado del Servidor.

El script del lado del Servidor envía una respuesta HTTP, está

respuesta estará en un formato que pueda ser interpretado por el

cliente JavaScript, el formato puede ser texto simple, pero en la

práctica, se requerirá de un formato de datos que pueda ser usado

para pasar datos estructurados. Los 2 formatos de datos más

populares utilizados en aplicaciones AJAX son XML y JSON

(JavaScript Object Notation).

65

INTERACCION AJAX DE EJEMPLO

Evento

XMLHttpRequest

function callback(){

//actualizar interfaz

}

Script de lado del

servidor

Aplicación Web AJAX

Cliente Servidor

1

2

3

45

Figura 14: Interacción en una aplicación AJAX.

Fuente: Nathaniel T. Schutta, Ryan Asleson, Pro AJAX and Java Frameworks, Apress,

2006.

1. Un evento JavaScript del lado del cliente dispara un evento

AJAX. Este puede ser disparado por cualquier otro elemento,

desde un evento hasta una acción específica del usuario. Con

un código como el siguiente:

<input type = “text” id=”email” name=”email” onblur=”validateEmail();”>

2. Una instancia del objeto XmlHttpRequest es creada. Usando el

método open, la llamada se configura. El URL con el método

HTTP correspondiente, típicamente GET o POST. La solicitud

es generada llamando al método send. De la siguiente manera:

var xmlHttp;

function validarEmail()

{

var email = document.getElementById("email");

var URL = "validar?email=" + escape(email.value);

if (window.ActiveXObject)

{

xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");

}

else if (window.XMLHttpRequest)

{

xmlHttp = new XMLHttpRequest();

}

xmlHttp.open("GET", URL);

xmlHttp.onreadystatechange = callback;

66

xmlHttp.send(null);

}

3. Se realiza una solicitud HTTP al Servidor. A cualquier script del

lado del Servidor.

4. El Servidor realiza cualquier tarea, generalmente de acceso a

datos. La respuesta es devuelta al navegador. El Content-Type

se establece a “text/xml” (El objeto XMLHttpRequest solo

puede procesar resultados del tipo “text/html”).

5. Cuando el Servidor devuelve la respuesta, el objeto

XMLHttpRequest invoca a una función de callback, que recibe

los datos devueltos y actualiza la interfaz del cliente.

Funtioncallback{

//actualizar interfaz

}

Como podemos ver, esto difiere del paradigma tradicional de

solicitud/respuesta. Típicamente estas llamadas se centralizan en una

librería que será utilizada por la aplicación web, o se utilizara una de

las tantas disponibles en la actualidad. En general estos frameworks

se encargan de las funcionalidades básicas e interacciones con el

navegador, otras agregan componentes JavaScript para la interfaz de

usuario.

2.2.4.3. ADOBEFLEX28

En su versión más reciente (Flex 4), es una plataforma de desarrollo y

despliegue de aplicaciones que se ejecutan sobre el Adobe Flash

Player para la Web y sobre Adobe AIR para el escritorio. A pesar de

que el Adobe Flash Player tiene ya varios años de existencia, la

mayoría de elementos desarrollados para este eran animaciones y

elementos visuales creados en su mayoría por diseñadores.

La plataforma de Adobe Flex permite a los desarrolladores ser

productivos construyendo aplicaciones para el Adobe Flash Player,

utilizando habilidades aprendidas en cualquier otro lenguaje de

programación. Desde su segunda versión (Adobe Flex 2) brinda un

28

FLASH BUILDER 4 AND FLEX 4 BIBLE ,David Gassne. Wiley Publishing, 2010.

67

ámbito de trabajo similar a herramientas existentes como Visual

Studio, Delphi, y JBuilder. El desarrollador escribe código (El lenguaje

utilizado es ActionScript 3) lo compila localmente y luego sube la

aplicación compilada al Servidor web para que puede ser utilizada por

el usuario.

2.2.2.4 Adobe Flash Player es un software de tiempo de ejecución

basado en navegadores y multiplataforma que ofrece una

visualización sin compromiso de aplicaciones expresivas, contenido y

vídeos en diferentes pantallas y exploradores. Flash Player 10.1 está

optimizado para un alto rendimiento en pantallas de dispositivos

móviles y está diseñado para aprovechar las funciones nativas del

dispositivo, permitiendo experiencias de usuario más profundas y

envolventes.

El resultado de compilar una aplicación Flex es un archivo SWF, que

al ser desplegado en un Servidor web, luego es descargado como

respuesta a una solicitud de un navegador web. El navegador

inicializa el Adobe Flash Player que ejecuta la aplicación del archivo

SWF.

Una de las principales ventajas del Adobe Flash Player es su gran

nivel de penetración en la Web. Cada nueva versión de este ha

alcanzado una tasa rápida de crecimiento de instalación con respecto

a versiones previas.

A junio del 2010, la tasa de penetración de las versiones 7, 8 y 9

fueron del 99%, y la versión 10 del Flash Player ya tiene una tasa de

penetración del 97.5% en navegadores a nivel mundial.

2.2.4.4.1. LENGUAJES

Las aplicaciones creadas con Adobe Flex tienen el mismo formato

que las animaciones producidas con las herramientas habituales

para crear contenido para el Adobe Flash Player (como Adobe

Flash CS5), pero el proceso para crear estas aplicaciones es muy

distinto.

Los lenguajes utilizados en la plataforma son:

68

ActionScript 3. La versión más reciente del lenguaje que

evolucionó a lo largo del ciclo de vida del Adobe Flash

Player hasta convertirse en un lenguaje de programación

completo, orientado a objetos.

MXML. Un lenguaje basado en XML que se utiliza para

definir una aplicación Flex y sus componentes. Muchos de

los elementos en MXML tienen sus clases equivalentes en

ActionScript 3 y forman parte de la librería de clases Flex.

FXG. Un lenguaje basado en XML que permite representar

objetos gráficos como marcado XML. Este lenguaje es

soportado por herramientas de Adobe como Illustrator,

Photoshop y Fireworks para permitir exportar objetos

gráficos hacia Adobe Flex.

Cuando una aplicación es compilada, el código MXML es

interpretado y se genera su correspondiente código en ActionScript

3, lo cual hace que sea más fácil definir partes de la aplicación en

MXML, que escribirlas completamente en ActionScript 3.

Se puede utilizar MXML y ActionScript de manera intercambiable

en muchas situaciones. MXML se usa comúnmente para definir la

disposición de los elementos visuales de la aplicación.

Por ejemplo para mostrar un elemento Label en pantalla:

<s:Label id=”miLabel” text=”Texto del Label” fontSize=”18”

fontWeight=”bold”/>

2.2.4.4.2. FLEX 4 SDK

O Flex 4 Standard Development Kit, es una librería de clases

implementada en ActionScript 3 que comprende la mayoría de

componentes visuales, animación, servicios de datos y otros que

forman parte del framework:

Controles de manejo de formularios.

Controles de menús.

Componentes de audio y video.

Contenedores de disposición de elementos visuales.

Componentes de datos.

69

Formateadores y validadores.

Manejo de cursor.

Manejo de estado.

Efectos.

Animación.

Manejo de historial.

Componentes de arrastrar y soltar.

Administración de estilos.

También incluye compiladores necesarios para construir

aplicaciones Flex. La descarga de los componentes mencionados

previamente y los compiladores es gratuita, los siguientes

componentes requieren de una licencia, la cual forma parte del IDE

llamado Adobe Flash Builder.

Componentes de visualización de datos y otros controles

visuales avanzados.

Herramientas de optimización de aplicaciones.

2.2.4.4.3. ADOBE FLASH BUILDER

Conocido previamente como Flex Builder, es un plugin basado en

Eclipse para el desarrollo de aplicaciones Flex. Eclipse es un IDE

(Integrated Development Environment) ampliamente utilizado, en

especial por desarrolladores Java. Aunque se pueden desarrollar

aplicaciones Flex sin necesidad de este IDE, Flash Builder facilita

enormemente tanto el diseño, depuración y despliegue de estas.

70

Herramientas de Desarrollo

Flex 4 SDK

(Gratuito)

Flash Builder 4

(Comercial)

Lenguajes

MXML y FXG

(Basados en XML)ActionScript 3

Entornos de ejecución

Flash Player

(Web)

AIR

(Escritorio)

ADOBE FLEX 4

Figura 15: Componentes de Adobe Flex 4

Fuente: David Gassner, Flash Builder 4 and Flex 4 Bible, Wiley Publishing, 2010.

2.2.4.4. MICROSOFT SILVERLIGHT29

Es una tecnología desarrollada por Microsoft para el desarrollo de

RIAs. Es una plataforma que está compuesta por un subconjunto de

la funcionalidad incluida en Windows Presentation Foundation (WPF)

y el .NET Framework. Al igual que el Adobe Flash Player, es un plugin

de navegador que permite la ejecución de contenido enriquecido en la

web.

Una aplicación RIA Silverlight, se ejecuta en el cliente, sobre el plugin

de Silverlight, el cual es ejecutado por el navegador, este ejecuta en el

cliente una versión específica del Common Language Runtime (CLR).

Un gran beneficio, ya que contiene una versión recortada de la Base

Class Library (BCL) de .NET, en total el plugin de Silverlight tiene un

tamaño de 5 MB.

29

SHANNON HORN, Microsoft Silverlight 3: A Beginner’s Guide, McGraw Hill, 2010.

71

2.2.4.4.4. FUNDAMENTOS

WINDOWS PRESENTATION FOUNDATION (WPF)

Es una versión rediseñada y mejorada de las tecnologías

.NET utilizadas para crear aplicaciones Windows, trabajar

con gráficos, crear animaciones e incrustar medios. Las

tecnologías Windows Forms (para ventanas y formularios

Windows) y GDI+ (para manipulación de gráficos) seguirán

siendo soportadas por Microsoft y pueden ser aún utilizadas,

pero carecen de muchas de las bondades disponibles en

WPF.

EXTENSIBLE APPLICATION MARKUP LANGUAGE

(XAML)

Es un lenguaje basado en XML creado para su utilización en

WPF. Su propósito principal es la definición de interfaces

gráficas y elementos visuales. Un archivo XAML es utilizado

para definir componentes visuales y su ubicación en la

aplicación. Un intérprete lee el archivo XAML y genera el

código administrado correspondiente para ser que estos

puedan ser instanciados.

SILVERLIGHT RUNTIME

Es el plugin propiamente dicho que se ejecuta en los

navegadores. Aparte de ser un subconjunto de WPF

también extiende y utiliza muchas de las funcionalidades de

ASP.NET AJAX. Al ser diseñada para el desarrollo de

aplicaciones RIA el plugin de Silverlight es multiplataforma y

funciona en distintos navegadores web.

En la actualidad, (Mayo 2012) el producto se encuentra en

su versión 5.1 Desde sus inicios las distintas versiones

fueron evolucionando de la siguiente manera:

La versión 1.0 fue lanzada en el 2007, e incluía las

siguientes funcionalidades:

- Gráficos y animación.

72

- Audio y video en formatos MP3 y Windows Media Video

(WMV).

- Imágenes en formato JPG y PNG.

- Utilización del Document Object Model (DOM) usando

JavaScript.

Silverlight 2 fue lanzado en septiembre del 2008, agregaba

las siguientes funcionalidades:

- Soporte de código administrado, en C#, Visual Basic,

IronPython e IronRuby.

- Controles de interfaz de usuario

- Acceso a datos mejorado.

Silverlight 3, lanzado en marzo del 2009, añadía las

siguientes funcionalidades:

- Soporte para validación de datos en los controles

visuales.

- Soporte nativo de hojas de estilo.

- Soporte de librerías de recursos externos.

- Soporte de modo desconectado.

- Se incluyeron muchos más controles visuales.

- Se mejoró el sistema de animaciones, agregando más

efectos visuales.

- Aceleración de gráficos por GPU.

2.2.4.4.5. HERRAMIENTAS

MICROSOFT VISUAL STUDIO 2010

A diferencia de versiones previas ofrece soporte completo

para desarrollar aplicaciones RIA Silverlight, incluyendo

todas las herramientas necesarias para el diseño de

contenido visual, la edición de código XAML, la depuración y

despliegue de aplicaciones Silverlight. Debido a que la 4ta

versión del producto (Silverlight 4) fue lanzada

posteriormente a Visual Studio 2010, Silverlight 4 se lanzó

también con Silverlight 4 Tools for Visual Studio 2010, la

73

cual actualiza Visual Studio para desarrollar aplicaciones

RIA Silverlight utilizando esta última versión.

MICROSOFT EXPRESSION STUDIO 4

Es un conjunto de herramientas graficas dirigidas a

diseñadores para la creación de contenido gráfico, audio y

video y el desarrollo de aplicaciones de escritorio y de

aplicaciones RIA basadas en Silverlight, está compuesto de

las siguientes aplicaciones:”

a) MICROSOFT EXPRESSION BLEND. Para la creación

de interfaces gráficas basadas en XAML, así como la

creación de animaciones y contenido interactivo.

b) MICROSOFT EXPRESSION DESIGN. Herramienta de

diseño gráfico.

c) MICROSOFT EXPRESSION MEDIA. Herramienta de

administración de medios de audio y video, edición,

conversión de formatos y su despliegue en aplicaciones

WPF.

2.2.4.5. HTML5

HTML5 (Hyper Text Markup Language, versión 5) es la quinta revisión

importante del lenguaje básico de la World Wide Web, HTML. HTML5

especifica dos variantes de sintaxis para HTML: un «clásico» HTML

(text/html), la variante conocida como HTML5 y una variante XHTML

conocida como sintaxis XHTML5 que deberá ser servida como XML

(XHTML) (application/xhtml+xml). Esta es la primera vez que HTML y

XHTML se han desarrollado en paralelo. HTML5 más que una

tecnología viene hacer un conjunto de especificación para el conjunto

de tecnologías HTML, JavaScript Y CSS. HTML5 propone estándares

para cada aspecto de la web y también un propósito claro para cada

una de las tecnologías involucradas. A partir de ahora, HTML provee

los elementos estructurales, CSS se encuentra concentrado en cómo

volver esa estructura utilizable y atractiva a la vista, y JavaScript tiene

todo el poder necesario para proveer dinamismo y construir

aplicaciones web completamente funcionales.

74

2.2.4.5.1. NUEVOS ELEMENTOS30

Estructura:

- section: Una parte o capítulo de un libro, sección de un

capítulo, o esencialmente cualquier cosa que tenga su

propio encabezado en HTML 4.

- header: El encabezado de la página; no es lo mismo que el

tag HEAD.

- footer: El pie de página, donde van las letras chicas,

copyright, emails, etc.

- nav: Una colección de links a otras páginas.

- article: Una entrada independiente en un blog, revista,

compendio o lo que sea.

Bloques semánticos:

- aside: Representa una nota, un consejo, un sidebar o lo que

sea que esté afuera del bloque narrativo.

- figure: Representa una imagen a nivel de bloque, junto con

su título.

- dialog: Un elemento diálogo representa una conversación

entre diferentes personas. El elemento „dt‟ señala al que

habla y „dd‟ señala el discurso.

Inlines semánticos:

- m (mark): Indica que el texto está “marcado” de alguna

manera pero no necesariamente enfatizado. Por ejemplo,

una página resaltada en un libro, o en google cache cuando

resalta los términos buscados. time: Bastante lógico,

representa una fecha. meter: Representa un valor numérico

en un rango especificado.

- progress: Representa el estado de un proceso en

ejecución, como las conocidas barras de progreso en las

ventanas de programas.

30

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

lnxw01NewHTML]

75

Multimedia embebida:

- audio y video: Como sus nombres dicen, son para embeber

audio y video. La sintaxis es prácticamente la del viejo y

querido tag IMG.

Interactivos:

- details: Representa información adicional que podría no

mostrarse por defecto.

- datagrid: Sirve como control de “grillas”. Para árboles,

listados y tablas que pueden ser actualizados con scripts.

- menu y command: Menu existe desde la versión 2 de

HTML. Fue deprecado en la versión 4 pero retorna con

nuevo significado, conteniendo comandos que se van a

ejecutar al ser activados.

2.2.4.5.2. NUEVAS APIs JAVASSCRIPT31:

API para hacer Drag & Drop. Mediante eventos.

API para trabajar Off-Line. Permite descargar todos los

contenidos necesarios y trabajar en local.

API de Geoposicionamiento para dispositivos que lo

soporten.

API Storage. Facilidad de almacenamiento persistente en

local, con bases de datos (basadas en SQLite) o con

almacenamiento de objetos por aplicación o por dominio

Web (Local Storage y Global Storage). Se dispone de una

Base de datos con la posibilidad de hacer consultas SQL.

WebSockets. API de comunicación bidireccional entre

páginas. Similar a los Sockets de C.

WebWorkers. Hilos de ejecución en paralelo.

ESTÁNDAR FUTURO. SystemInformation API. Acceso al

hardware a bajo nivel: red, ficheros, CPU, memoria, puertos

31

DEFINICIÓN HTML5, Disponible en:[ http://es.wikipedia.org/wiki/HTML5]

76

USB, cámaras, micrófonos, etc. muy interesante pero con

numerosas salvedades de seguridad.

2.2.5. FREMEWORK

La palabra inglesa "framework" define, en términos generales, un

conjunto estandarizado de conceptos, prácticas y criterios para

enfocar un tipo de problemática particular que sirve como referencia,

para enfrentar y resolver nuevos problemas de índole similar.

En el desarrollo de software, un framework o infraestructura digital, es

una estructura conceptual y tecnológica de soporte definido,

normalmente con artefactos o módulos de software concretos, con

base a la cual otro proyecto de software puede ser más fácilmente

organizado y desarrollado. Típicamente, puede incluir soporte de

programas, bibliotecas, y un lenguaje interpretado, entre otras

herramientas, para así ayudar a desarrollar y unir los diferentes

componentes de un proyecto.

Representa una arquitectura de software que modela las relaciones

generales de las entidades del dominio, y provee una estructura y una

especial metodología de trabajo, la cual extiende o utiliza las

aplicaciones del dominio.

2.2.6. PATRON DE DISEÑO32

Según Christopher Alexander, “cada patrón describe un problema que

ocurre una y otra vez en nuestro entorno, así como la solución a ese

problema, de tal modo que se pueda aplicar esta solución un millón de

veces, sin hacer lo mismo dos veces” .

Aunque Alexander se refería a patrones en ciudades y edificios, lo

que dice también es válido para patrones de diseño orientados a

objetos. Nuestras soluciones se expresan en términos de objetos e

interfaces, en vez de paredes y puertas, pero en la esencia de ambos

tipos de patrones se encuentra una solución a un problema dentro de

32

PATRONES DE DISEÑO (Elementos de software orientado a objetos reutilizables),Erich Gamma, Richard Helm, Ralph

Johnson, John Vlissides

77

un contexto.

En general, un patrón tiene cuatro elementos esenciales:

El nombre del patrón permite describir, en una o dos palabras,

un problema de diseño junto con sus soluciones y

consecuencias. Al dar nombre a un patrón inmediatamente

estamos incrementado nuestro vocabulario de diseño, lo que

nos permite diseñar con mayor abstracción. Tener un

vocabulario de patrones nos permite hablar de ellos con otros

colegas, mencionarlos en nuestra documentación y tenerlos

nosotros mismos en cuenta. De esta manera, resulta más fácil

pensar en nuestros diseños y transmitirlos a otros, junto con

sus ventajas e inconvenientes. Encontrar buenos nombres ha

sido una de las partes más difíciles al desarrollar nuestro

catálogo.

El problema describe cuándo aplicar el patrón. Explica el

problema y su contexto. Puede describir problemas concretos

de diseño (por ejemplo, cómo representar algoritmos como

objetos), así como las estructuras de clases u objetos que son

sintomáticas de un diseño inflexible. A veces el problema

incluye una serie de condiciones que deben darse para que

tenga sentido aplicar el patrón.

La solución describe los elementos que constituyen el diseño,

sus relaciones, responsabilidades y colaboraciones. La

solución no describe un diseño o una implementación en

concreto, sino que un patrón es más bien como una plantilla

que puede aplicarse en muchas situaciones diferentes. El

patrón proporciona una descripción abstracta de un problema

de diseño y cómo lo resuelve una disposición general de

elementos (en nuestro caso, clases y objetos).

Las consecuencias son los resultados así como las ventajas e

inconvenientes de aplicar el patrón. Aunque cuando se

describen decisiones de diseño muchas veces no se reflejan

sus consecuencias, éstas son fundamentales para evaluar las

78

alternativas de diseño y comprender los costes y beneficios de

aplicar el patrón. Las consecuencias en el software suelen

referirse al equilibrio entre espacio y tiempo. También pueden

tratar cuestiones de lenguaje e implementación. Por otro lado,

puesto que la reutilización suele ser uno de los factores de los

diseños orientados a objetos, las consecuencias de un patrón

incluyen su impacto sobre la flexibilidad, extensibilidad y

portabilidad de un sistema. Incluir estas consecuencias de un

modo explícito nos ayudará a comprenderlas y evaluarlas.

2.2.6.1. OBJETIVOS33

Proporcionar catálogos de elementos reusables en el diseño de

sistemas software.

Evitar la reiteración en la búsqueda de soluciones a problemas

ya conocidos y solucionados anteriormente.

Formalizar un vocabulario común entre diseñadores.

Estandarizar el modo en que se realiza el diseño.

Facilitar el aprendizaje de las nuevas generaciones de

diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

Imponer ciertas alternativas de diseño frente a otras.

Eliminar la creatividad inherente al proceso de diseño.

No es obligatorio utilizar los patrones, solo es aconsejable en el

caso de tener el mismo problema o similar que soluciona el

patrón, siempre teniendo en cuenta que en un caso particular

puede no ser aplicable. "Abusar o forzar el uso de los patrones

puede ser un error".

33

OBJETIVOS DE PATRONES DE DISEÑO, Disponible en:[http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o]

79

2.2.6.2. CATEGORÍAS DE PATRONES34

Según la escala o nivel de abstracción:

Patrones de arquitectura: Aquellos que expresan un

esquema organizativo estructural fundamental para sistemas

de software.

Patrones de diseño: Aquellos que expresan esquemas para

definir estructuras de diseño (o sus relaciones) con las que

construir sistemas de software.

Dialectos: Patrones de bajo nivel específicos para un lenguaje

de programación o entorno concreto.

2.2.6.3. RELACIÓN DE PRINCIPALES PATRONES GOF (GANG OF

FOUR)35

2.2.6.3.1. Patrones creacionales:

1. Object Pool (no pertenece a los patrones especificados

por GoF): se obtienen objetos nuevos a través de la

clonación. Utilizado cuando el costo de crear una clase es

mayor que el de clonarla. Especialmente con objetos muy

complejos. Se especifica un tipo de objeto a crear y se utiliza

una interfaz del prototipo para crear un nuevo objeto por

clonación. El proceso de clonación se inicia instanciando un

tipo de objeto de la clase que queremos clonar.

2. Abstract Factory (fábrica abstracta): permite trabajar con

objetos de distintas familias de manera que las familias no

se mezclen entre sí y haciendo transparente el tipo de

familia concreta que se esté usando.

3. Builder (constructor virtual): abstrae el proceso de

creación de un objeto complejo, centralizando dicho proceso

en un único punto.

4. Factory Method (método de fabricación): centraliza en

una clase constructora la creación de objetos de un subtipo

34

CATEGORÍA DE PATRONES, Disponible en:[http://es.wikipedia.org/wiki/Patrones_de_dise%C3%B1o] 35

RELACIÓN DE PRINCIPALES PATRONES DE DISEÑO, Disponible

en:[http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o]

80

de un tipo determinado, ocultando al usuario la casuística,

es decir, la diversidad de casos particulares que se pueden

prever, para elegir el subtipo que crear.

5. Prototype (prototipo): crea nuevos objetos clonándolos de

una instancia ya existente.

6. Singleton (instancia única): garantiza la existencia de una

única instancia para una clase y la creación de un

mecanismo de acceso global a dicha instancia.

2.2.6.3.2. Patrones estructurales:

1. Adapter (Adaptador): Adapta una interfaz para que pueda

ser utilizada por una clase que de otro modo no podría

utilizarla.

2. Bridge (Puente): Desacopla una abstracción de su

implementación.

3. Composite (Objeto compuesto): Permite tratar objetos

compuestos como si de uno simple se tratase.

4. Decorator (Envoltorio): Añade funcionalidad a una clase

dinámicamente.

5. Facade (Fachada): Provee de una interfaz unificada simple

para acceder a una interfaz o grupo de interfaces de un

subsistema.

6. Flyweight (Peso ligero): Reduce la redundancia cuando

gran cantidad de objetos poseen idéntica información.

7. Proxy: Mantiene un representante de un objeto.

8. Módulo: Agrupa varios elementos relacionados, como

clases, singletons, y métodos, utilizados globalmente, en

una entidad única.

2.2.6.3.3. Patrones de comportamiento

1. Chain of Responsibility (Cadena de responsabilidad):

Permite establecer la línea que deben llevar los mensajes

para que los objetos realicen la tarea indicada.

81

2. Command (Orden): Encapsula una operación en un objeto,

permitiendo ejecutar dicha operación sin necesidad de

conocer el contenido de la misma.

3. Interpreter (Intérprete): Dado un lenguaje, define una

gramática para dicho lenguaje, así como las herramientas

necesarias para interpretarlo.

4. Iterator (Iterador): Permite realizar recorridos sobre objetos

compuestos independientemente de la implementación de

estos.

5. Mediator (Mediador): Define un objeto que coordine la

comunicación entre objetos de distintas clases, pero que

funcionan como un conjunto.

6. Memento (Recuerdo): Permite volver a estados anteriores

del sistema.

7. Observer (Observador): Define una dependencia de uno-a-

muchos entre objetos, de forma que cuando un objeto

cambie de estado se notifique y actualicen automáticamente

todos los objetos que dependen de él.

8. State (Estado): Permite que un objeto modifique su

comportamiento cada vez que cambie su estado interno.

9. Strategy (Estrategia): Permite disponer de varios métodos

para resolver un problema y elegir cuál utilizar en tiempo de

ejecución.

10. Template Method (Método plantilla): Define en una

operación el esqueleto de un algoritmo, delegando en las

subclases algunos de sus pasos, esto permite que las

subclases redefinan ciertos pasos de un algoritmo sin

cambiar su estructura.

11. Visitor (Visitante): Permite definir nuevas operaciones

sobre una jerarquía de clases sin modificar las clases sobre

las que opera.

82

2.2.6.4. MODELO VISTA CONTROLADOR (MVC)36

Es un patrón o modelo de abstracción de desarrollo de software que

separa los datos de una aplicación, la interfaz de usuario, y la lógica

de negocio en tres componentes distintos. El patrón de llamada y

retorno MVC (según CMU), se ve frecuentemente en aplicaciones

web, donde la vista es la página HTML y el código que provee de

datos dinámicos a la página. El modelo es el Sistema de Gestión de

Base de Datos y la Lógica de negocio, y el controlador es el

responsable de recibir los eventos de entrada desde la vista.

Modelo: Esta es la representación específica de la información

con la cual el sistema opera. En resumen, el modelo se limita a

lo relativo de la vista y su controlador facilitando las

presentaciones visuales complejas. El sistema también puede

operar con más datos no relativos a la presentación, haciendo

uso integrado de otras lógicas de negocio y de datos afines con

el sistema modelado.

Vista: Este presenta el modelo en un formato adecuado para

interactuar, usualmente la interfaz de usuario.

Controlador: Este responde a eventos, usualmente acciones

del usuario, e invoca peticiones al modelo y, probablemente, a

la vista.

Muchos de los sistemas informáticos utilizan un Sistema de Gestión

de Base de Datos para gestionar los datos: en líneas generales del

MVC corresponde al modelo. La unión entre capa de presentación y

capa de negocio conocido en el patrón de la Programación por capas

representaría la integración entre Vista y su correspondiente

Controlador de eventos y acceso a datos, MVC no pretende

discriminar entre capa de negocio y capa de presentación pero si

pretende separar la capa visual gráfica de su correspondiente

programación y acceso a datos, algo que mejora el desarrollo y

mantenimiento de la Vista y el Controlador en paralelo, ya que ambos

cumplen ciclos de vida muy distintos entre sí.

36

DEFINICIÓN DE PATRÓN MODELO VISTA CONTROLADOR, Disponible

en:[http://es.wikipedia.org/wiki/Modelo_Vista_Controlador]

http://es.wikipedia.org/wiki/Modelo_Vista_Controlador

83

Aunque se pueden encontrar diferentes implementaciones de MVC, el

flujo que sigue el control generalmente es el siguiente:

El usuario interactúa con la interfaz de usuario de alguna forma

(por ejemplo, el usuario pulsa un botón, enlace, etc.)

El controlador recibe (por parte de los objetos de la interfaz-

vista) la notificación de la acción solicitada por el usuario. El

controlador gestiona el evento que llega, frecuentemente a

través de un gestor de eventos (handler) o callback.

El controlador accede al modelo, actualizándolo, posiblemente

modificándolo de forma adecuada a la acción solicitada por el

usuario (por ejemplo, el controlador actualiza el carro de la

compra del usuario). Los controladores complejos están a

menudo estructurados usando un patrón de comando que

encapsula las acciones y simplifica su extensión.

El controlador delega a los objetos de la vista la tarea de

desplegar la interfaz de usuario. La vista obtiene sus datos del

modelo para generar la interfaz apropiada para el usuario

donde se reflejan los cambios en el modelo (por ejemplo,

produce un listado del contenido del carro de la compra). El

modelo no debe tener conocimiento directo sobre la vista. Sin

embargo, se podría utilizar el patrón Observador para proveer

cierta indirección entre el modelo y la vista, permitiendo al

modelo notificar a los interesados de cualquier cambio. Un

objeto vista puede registrarse con el modelo y esperar a los

cambios, pero aun así el modelo en sí mismo sigue sin saber

nada de la vista. Este uso del patrón Observador no es posible

en las aplicaciones Web puesto que las clases de la vista están

desconectadas del modelo y del controlador. En general el

controlador no pasa objetos de dominio (el modelo) a la vista

aunque puede dar la orden a la vista para que se actualice.

Nota: En algunas implementaciones la vista no tiene acceso

directo al modelo, dejando que el controlador envíe los datos

del modelo a la vista. Por ejemplo en el MVC usado por Apple

84

en su framework Cocoa. Suele citarse como Modelo-Interface-

Control, una variación del MVC más puro

La interfaz de usuario espera nuevas interacciones del usuario,

comenzando el ciclo nuevamente.

2.2.6.5. MODELO VISTA PRESENTADOR (MVP)37

Este Patrón surge para ayudar a realizar pruebas automáticas de la

interfaz gráfica, para ello la idea es codificar la interfaz de usuario lo

más simple posible, teniendo el menor código posible, de forma que

no merezca la pena probarla. En su lugar, toda la lógica de la interfaz

de usuario, se hace en una clase separada (que se conoce como

Presentador), que no dependa en absoluto de los componentes de la

interfaz gráfica y que, por tanto, es más fácil de realizar pruebas. La

idea básica es que la clase Presentador haga de intermediario entre la

Vista (la interfaz gráfica de usuario) y el modelo de datos. La vista

tiene métodos en los que le pasan los datos que debe pintar ya

"mascados" (una lista de cadenas por ejemplo, en vez del modelo...).

Únicamente debe meter esos datos en los componentes gráficos

(cajas de texto, checkbox, etc.). También métodos get para obtener el

contenido de esos componentes. El Presentador hará de enlace entre

el modelo y la vista, y dotará de inteligencia a la vista. Como el

objetivo es poder probarlo fácilmente, el Presentador recibe las

interfaces que deben implementar el modelo y la vista, con los

métodos públicos a los que el Presentador debe llamar.

37

DEFINICIÓN DE MODELO VISTA PRESENTADOR, Disponible en:[http://WWW.imaginanet.com/blog/patron-mvp.html]

85

Figura 16: Flujo de Patrón Modelo Vista Presentador

Se puede decir que el patrón MVP es una mejora del patrón Modelo-

Vista-Controlador (MVC) basado en tres características:

La vista no conoce el modelo.

El presentador es independiente de la tecnología de interfaz de

usuario.

La vista y el presentador son testeables puesto que está

basada en un contrato.

2.2.6.5.1. MVP COMO CONTROLADOR SUPERVISADO38

Por un lado, podemos tener un presentador que no gestione la

forma en que la información es mostrada en la vista. Es la vista

quien define la lógica de cómo la información es formateada y

mostrada en la pantalla a partir de los controles que contiene. En

este caso, el presentador únicamente gestiona los casos más

complejos para facilitar el trabajo de la vista. Martin Fowler llama a

esta variación Controlador Supervisado.

38 MVP COMO CONTROLADOR SUPERVISADO, Disponible en: [http://theartoftheleftfoot.blogspot.com/2010/10/el-patron-

Gmodelo-vista-presentador-mvp.html]

86

Figura 17: Flujo de patrón Modelo Vista Presentador Supervisado

Cuando la vista recibe algún evento de ratón o teclado por parte del

usuario, delega el control del evento en el presentador. Este puede

realizar ciertas operaciones relacionadas con la vista como el

control del estado de los controles y después realizar la llamada a

algún comando en el modelo que realice la operación requerida por

el usuario. El modelo realiza las operaciones pudiendo realizar

cambios en su estado generando el evento correspondiente, el cual

es manejado por la vista para actualizar los controles de la pantalla.

Hay que tener en cuenta de que el hecho de que la vista pueda

hacer referencia al modelo nos da como resultado un diagrama

muy parecido al de MVC. Aunque este enfoque nos permita el uso

de técnicas de Data Binding. Con lo cual la cantidad de código que

la vista y presentador necesitan, se disminuye. Este enfoque nos

va a permitir el uso de técnicas de Data Binding sobre el modelo.

Por tanto, la cantidad de líneas de código fuente en la vista y el

presentador disminuyen. Si nos fijamos en el diagrama, este es

similar al de MVC por lo que hay que tener mucho cuidado en no

caer en un cambio de patrón.

87

2.2.6.5.2. MVP COMO VISTA PASIVA39

Por otro lado, podemos hacer que el presentador gestione

totalmente cómo la información se muestra en la vista. Es decir,

tenemos una vista "tonta", sin ningún tipo de lógica, cuya única

función es la de mostrar la información que se le pasa a través de

la interfaz de la vista. Martin Fowler llama a esta variación Vista

Pasiva.

Figura 18: Flujo de patrón modelo vista presentador con vista pasiva

En este caso, cuando un usuario realiza alguna operación sobre la

interfaz de usuario, la vista delega los eventos sobre el

presentador. Este realizará algún cambio sobre la vista para indicar

el cambio de estado y hará las llamadas a los comandos sobre el

modelo para llevar a cabo la operación requerida por el usuario.

Cuando el modelo provoque cambios en su estado, estos serán

recogidos por el presentador (al contrario que en el controlador

supervisado, que era la vista quien atendía a estos cambios de

estado en el modelo), el cual pedirá al modelo los cambios

realizados para luego actualizar la vista acorde a los cambios

recibidos.

39 MVP COMO VISTA PASIVA, Disponible en: [http://theartoftheleftfoot.blogspot.com/2010/10/el-patron-modelo-vista-

presentador-mvp.html]

88

2.2.6.6. JAVASCRIPT

JavaScript es un lenguaje de programación que se utiliza

principalmente para crear páginas web dinámicas.

Una página web dinámica es aquella que incorpora efectos como

texto que aparece y desaparece, animaciones, acciones que se

activan al pulsar botones y ventanas con mensajes de aviso al

usuario.

Técnicamente es un lenguaje de programación interpretado, por lo

que no es necesario compilar los programas para ejecutarlos. En

otras palabras, Es un lenguaje que se ejecuta en el ambiente de un

anfitrión. El navegador web es el ambiente más común pero no es el

único (los programas escritos con JavaScript se pueden probar

directamente en cualquier navegador sin necesidad de procesos

intermedios).

En un principio JavaScript comenzó con simples animaciones

introducidos en HTML, pero es usado ahora de modos mucho más

sofisticado. Los desarrolladores aprovechan la naturaleza orientada al

objeto del lenguaje para construir arquitecturas de código escalables

formadas por piezas reutilizables. JavaScript representa el tercer pilar

en el paradigma actual de las páginas Web que consiste en tres

partes claramente distinguibles: contenido (HTML), presentación

(CSS), y comportamiento (JavaScript).

2.2.8.6.1. ORIGENES40

Inicialmente, la Web fue concebida como una colección de

documentos HTML estáticos, unidos mediante hipervínculos. Pero

Con el crecimiento rápido de popularidad y tamaño de la Web, los

webmasters que estaban creando páginas web HTML estáticas

sentían que necesitaba algo más. Querían que la oportunidad para

la interacción del usuario sea más rica, principalmente impulsado

por el deseo de evitar consultas al Servidor para tareas simples,

tales como la validación de formularios. Se presentaron dos

40

JAVASCRIPT ORIENTADO A OBJETOs: Stoyan Stefanov

89

opciones para resolver dicho problema: Applets de Java (que no

llegaron a tener éxito) y LiveScript, que fue concebido por Netscape

en 1995 y más tarde incluido en el navegador Netscape 2.0, bajo el

nombre de JavaScript.

La capacidad de alterar de otro modo los elementos estáticos de

una página web fue muy bien recibida y otros exploradores

siguieron su ejemplo. Microsoft Internet Explorer (IE) 3.0 se incluye

con JScript, que era una copia del mismo lenguaje además de

algunas funciones específicas de IE. Con el tiempo se hizo un

esfuerzo para estandarizar las diversas implementaciones del

lenguaje y así es como ECMAScript (European Computer

Manufacturers Association) nació. Hoy tenemos el estándar,

llamado ECMA-262, y JavaScript es sólo una aplicación de esta

norma, aunque el más popular.

Para bien o para mal, la popularidad instantánea de JavaScript que

sucedió durante el período del Browser Wars I (aproximadamente

1996-2001). Eran los tiempos del boom de Internet inicial, cuando

los dos principales proveedores de navegador, Netscape y

Microsoft, estaban compitiendo por la cuota de mercado. Estos dos

vendedores estaban constantemente añadiendo características

para sus navegadores y sus versiones de JavaScript. Esta

situación, junto con la falta de un estándar trajo un montón de

malas opiniones sobre JavaScript. Muy a menudo, el desarrollo era

muy complicado: ya que una vez escrito el código para un

navegador, al probarlo en otro navegador simplemente no

funcionaba. Al mismo tiempo, los fabricantes de navegadores

añadían constantemente nuevas características a sus navegadores

obviando proporcionar herramientas adecuadas para el desarrollo,

generando con esto incompatibilidades molestas para los

desarrolladores web, pero esto fue sólo una parte del problema. La

otra parte del problema eran los mismos desarrolladores web, que

se añaden demasiadas características a sus páginas web. Los

desarrolladores estaban ansiosos por hacer uso de todas las

posibilidades que los nuevos navegadores para "mejorar" sus

90

páginas web con cosas como las animaciones en la barra de

estado, colores parpadeantes, textos parpadeantes, sacudiendo las

ventanas del navegador, copos de nieve y así sucesivamente. Este

abuso de JavaScript fue la otra razón por la que este lenguaje tuvo

mala reputación, haciendo que los programadores "reales" (los

desarrolladores con conocimientos de lenguajes más establecidos,

como Java o C / C + +) vieran a JavaScript nada más que como un

juguete para los diseñadores de front-end.

Causando en algunos proyectos, la prohibición de la programación

del lado del cliente en JavaScript y confiar sólo su Servidor

predecible y fiable.

2.2.8.6.2. EVOLUCION41

Una vez terminada la guerra de los navegadores se produjeron una

serie de procesos que reconfiguraron el panorama de desarrollo

web de una manera muy positiva.

Microsoft ganó la guerra y durante unos cinco años (que es un

periodo muy largo en el ámbito de Internet), dejaron de agregar

características a Internet Explorer y JScript. Este tiempo permitido

a otros navegadores, así como desarrolladores alcanzar e incluso

superar las capacidades de Internet Explorer. El movimiento por los

estándares web fue abrazado por los desarrolladores y

proveedores de navegadores por igual. Naturalmente a los

desarrolladores no les gustaba tener que implementar código para

cada navegador, por lo que la idea de tener estándares acordados

tuvo mucha aceptación.

Todavía estamos lejos de poder desarrollar de una manera

plenamente compatible con los estándares, pero lo ideal es

conseguir que esto suceda en el futuro.

Tanto desarrolladores como tecnologías fueron madurado y más

gente comenzó a preocuparse por cosas como la usabilidad,

técnicas progresivas de mejora y accesibilidad.

41

JAVASCRIPT ORIENTADO A OBJETOS: Stoyan Stefanov

91

En este entorno más saludable, los desarrolladores comenzaron a

descubrir nuevas y mejores formas de utilizar los instrumentos que

ya estaban disponibles. Después de la publicación de aplicaciones,

como Gmail y Google Maps, que eran ricos en la programación del

lado del cliente, se hizo evidente que JavaScript ya era una

tecnología madura, teniendo como uno de los mejores ejemplos de

su redescubrimiento la amplia adopción de la funcionalidad

proporcionada por el objeto XMLHttpRequest, que comenzó como

una innovación para Internet Explorer, pero luego se puso en

práctica por la mayoría de los navegadores.

XMLHttpRequest permite a JavaScript realizar peticiones HTTP y

obtener un nuevo contenido desde el Servidor a fin de actualizar

algunas partes de una página, sin una recarga de página completa.

Debido al amplio uso de XMLHttpRequest, una nueva generación

de aplicaciones web como de escritorio, llamada aplicaciones

AJAX, nació.

2.2.8.6.3. PRESENTE42

Una cosa interesante acerca de JavaScript es que siempre se

ejecuta en el ambiente de su anfitrión. El navegador es el anfitrión

más popular, pero no es el único. JavaScript puede ejecutar en el

Servidor, en el escritorio, las capacidades actuales de JavaScript

son:

Crear aplicaciones de internet enriquecidas y poderosas (el

tipo de aplicaciones que se ejecutan dentro del navegador

web, como Gmail)

Escribir el código de Servidor, tales como secuencias de

comandos ASP, el código que se ejecuta utilizando Rhino(un

motor de JavaScript escrito en Java)

Crear aplicaciones multimedia (Flash, Flex) con ActionScript,

que se basa en ECMAScript

42

JAVASCRIPT ORIENTADO A OBJETOS: Stoyan Stefanov

92

Escribir scripts que automatizan las tareas administrativas

en el escritorio de Windows, utilizando Windows Scripting

Host

Escribir extensiones / plugins para una gran cantidad de

aplicaciones de escritorio como Firefox, Dreamweaver, y

Fiddler

Crear aplicaciones web que almacenan la información en

una base de datos fuera de línea en el escritorio del usuario,

el uso de Google Gears.

Crear Yahoo! Widgets, widgets del Dashboard de Mac, o

aplicaciones de Adobe AIR que se ejecutan en el escritorio

2.2.8.6.4. ESPECIFICACIONES OFICIALES

ECMA ha publicado varios estándares relacionados con

ECMAScript. En Junio de 1997 se publicó la primera edición del

estándar ECMA-262. Un año después, en Junio de 1998 se

realizaron pequeñas modificaciones para adaptarlo al estándar

ISO/IEC-16262 y se creó la segunda edición. La tercera edición del

estándar ECMA-262 (publicada en Diciembre de 1999) es la

versión que utilizan los navegadores actuales y se puede consultar

gratuitamente en http://www.ecma-international.org/publications/

standards/Ecma-262.htm. Actualmente se encuentra en desarrollo

la cuarta versión de ECMA-262, que podría incluir novedades como

paquetes, namespaces, definición explícita de clases, etc. ECMA

también ha definido varios estándares relacionados con

ECMAScript, como el estándar ECMA-357, que define una

extensión conocida como E4X y que permite la integración de

JavaScript y XML.

http://www.ecma-international.org/

93

2.2.8.6.5. CÓMO INCLUIR JAVASCRIPT EN DOCUMENTOS XHTML

La integración de JavaScript y XHTML es muy flexible, ya que

existen al menos tres formas para incluir código JavaScript en las

páginas web.

INCLUIR JAVASCRIPT EN EL MISMO DOCUMENTO XHTML

El código JavaScript se encierra entre etiquetas <script> y se

incluye en cualquier parte del documento. Aunque es correcto

incluir cualquier bloque de código en cualquier zona de la página,

se recomienda definir el código JavaScript dentro de la cabecera

del documento (dentro de la etiqueta <head>). Para que la página

XHTML resultante sea válida, es necesario añadir el atributo type a

la etiqueta <script>. Los valores que se incluyen en el atributo type

están estandarizados y para el caso de JavaScript, el valor correcto

es text/JavaScript. Este método se emplea cuando se define un

bloque pequeño de código o cuando se quieren incluir

instrucciones específicas en un determinado documento HTML que

completen las instrucciones y funciones que se incluyen por

defecto en todos los documentos del sitio web. El principal

inconveniente es que si se quiere hacer una modificación en el

bloque de código, es necesario modificar todas las páginas que

incluyen ese mismo bloque de código JavaScript.

DEFINIR JAVASCRIPT EN UN ARCHIVO EXTERNO

Las instrucciones JavaScript se pueden incluir en un archivo

externo de tipo JavaScript que los documentos XHTML enlazan

mediante la etiqueta <script>. Se pueden crear todos los archivos

JavaScript que sean necesarios y cada documento XHTML puede

enlazar tantos archivos JavaScript como necesite. Además del

atributo type, este método requiere definir el atributo src, que es el

que indica la URL correspondiente al archivo JavaScript que se

quiere enlazar. Cada etiqueta <script> solamente puede enlazar un

único archivo, pero en una misma página se pueden incluir tantas

etiquetas <script> como sean necesarias. Los archivos de tipo

94

JavaScript son documentos normales de texto con la extensión .js,

que se pueden crear con cualquier editor de texto como Notepad,

Wordpad, EmEditor, UltraEdit, Vi, etc. la principal ventaja de

enlazar un archivo JavaScript externo es que se simplifica el código

XHTML de la página, que se puede reutilizar el mismo código

JavaScript en todas las páginas del sitio web y que cualquier

modificación realizada en el archivo JavaScript se ve reflejada

inmediatamente en todas las páginas XHTML que lo enlazan.

2.2.8.6.6. COMO INCLUIR JAVASCRIPT EN DOCUMENTOS XHTML

INCLUIR JAVASCRIPT EN EL MISMO DOCUMENTO XHTML

El código JavaScript se encierra entre etiquetas <script> y se

incluye en cualquier parte del documento. Aunque es correcto

incluir cualquier bloque de código en cualquier zona de la página,

se recomienda definir el código JavaScript dentro de la cabecera

del documento (dentro de la etiqueta <head>)

INCLUIR JAVASCRIPT EN LOS ELEMENTOS XHTML43

Este método es el menos utilizado, ya que consiste en incluir trozos

de JavaScript dentro del código XHTML de la página por ejemplo:

<p onclick="alert('Un mensaje de prueba')">Un párrafo de

texto.</p> El mayor inconveniente de este método es que ensucia

innecesariamente el código XHTML de la página y complica el

mantenimiento del código JavaScript. En general, este método sólo

se utiliza para definir algunos eventos y en algunos otros casos

especiales, como se verá más adelante.

DEFINIR JAVASCRIPT EN UN ARCHIVO EXTERNO44

Las instrucciones JavaScript se pueden incluir en un archivo

externo de tipo JavaScript que los documentos XHTML enlazan

mediante la etiqueta <script>. Se pueden crear todos los archivos

43

INTRODUCCION A JAVASCRIP: Javier Eguíluz Pérez 44

INTRODUCCION A JAVASCRIP: Javier Eguíluz Pérez

95

JavaScript que sean necesarios y cada documento XHTML puede

enlazar tantos archivos JavaScript como necesite.

2.2.8.6.7. SINTAXIS

La sintaxis de un lenguaje de programación se define como el

conjunto de reglas que deben seguirse al escribir el código fuente

de los programas para considerarse como correctos para ese

lenguaje de programación. La sintaxis de JavaScript es muy similar

a la de otros lenguajes de programación como Java y C. Las

normas básicas que definen la sintaxis de JavaScript son las

siguientes:

No se tienen en cuenta los espacios en blanco y las nuevas

líneas: como sucede con XHTML, el intérprete de JavaScript

ignora cualquier espacio en blanco sobrante, por lo que el

código se puede ordenar de forma adecuada para

entenderlo mejor (tabulando las líneas, añadiendo espacios,

creando nuevas líneas, etc.) Se distinguen las mayúsculas y

minúsculas: al igual que sucede con la sintaxis de las

etiquetas y elementos XHTML. Sin embargo, si en una

página XHTML se utilizan indistintamente mayúsculas y

minúsculas, la página se visualiza correctamente, siendo el

único problema la no validación de la página. En cambio, si

en JavaScript se intercambian mayúsculas y minúsculas el

script no funciona.

No se define el tipo de las variables: al crear una variable, no

es necesario indicar el tipo de dato que almacenará. De esta

forma, una misma variable puede almacenar diferentes tipos

de datos durante la ejecución del script.

No es necesario terminar cada sentencia con el carácter de

punto y coma (;): en la mayoría de lenguajes de

programación, es obligatorio terminar cada sentencia con el

carácter “;”. Aunque JavaScript no obliga a hacerlo, es

conveniente seguir la tradición de terminar cada sentencia

con el carácter del punto y coma (;).

96

Se pueden incluir comentarios: los comentarios se utilizan

para añadir información en el código fuente del programa.

Aunque el contenido de los comentarios no se visualiza por

pantalla, sí se envía al navegador del usuario junto con el

resto del script, por lo que es necesario extremar las

precauciones sobre la información incluida en los

comentarios.

2.2.8.6.8. POSIBILIDADES Y LIMITACIONES45

Desde su aparición, JavaScript siempre fue utilizado de forma

masiva por la mayoría de sitios de Internet. La aparición de Flash

disminuyó su popularidad, ya que Flash permitía realizar algunas

acciones imposibles de llevar a cabo mediante JavaScript. Sin

embargo, la aparición de las aplicaciones AJAX programadas con

JavaScript le ha devuelto una popularidad sin igual dentro de los

lenguajes de programación web. En cuanto a las limitaciones,

JavaScript fue diseñado de forma que se ejecutara en un entorno

muy limitado que permitiera a los usuarios confiar en la ejecución

de los scripts. De esta forma, los scripts de JavaScript no pueden

comunicarse con recursos que no pertenezcan al mismo dominio

desde el que se descargó el script. Los scripts tampoco pueden

cerrar ventanas que no hayan abierto esos mismos scripts. Las

ventanas que se crean no pueden ser demasiado pequeñas ni

demasiado grandes ni colocarse fuera de la vista del usuario

(aunque los detalles concretos dependen de cada navegador).

Además, los scripts no pueden acceder a los archivos del

ordenador del usuario (ni en modo lectura ni en modo escritura) y

tampoco pueden leer o modificar las preferencias del navegador.

Por último, si la ejecución de un script dura demasiado tiempo (por

ejemplo por un error de programación) el navegador informa al

usuario de que un script está consumiendo demasiados recursos y

le da la posibilidad de detener su ejecución. A pesar de todo,

45

INTRODUCCIÓN A JAVASCRIPT: Javier Eguíluz Pérez

97

existen alternativas para poder saltarse algunas de las limitaciones

anteriores. La alternativa más utilizada y conocida consiste en

firmar digitalmente el script y solicitar al usuario el permiso para

realizar esas acciones.

2.2.8.6.9. PROGRAMACIÓN ORIENTADA A OBJETOS (OOP) CON

JAVASCRIPT

El lenguaje JavaScript está normalmente vinculado a la idea de

pequeños fragmentos de código que sirven para “enriquecer” las

páginas Web. Sin embargo, con las versiones que implementan

actualmente los navegadores, las tareas que pueden llevarse a

cabo empleando este lenguaje son de mucha mayor envergadura y

complejidad. Quizás una de las más interesantes estriba en la

posibilidad que tiene el programador de crear sus propios objetos,

a imagen y semejanza de otros objetos definidos por el estándar,

como son Date, Array, etc. Esto representa un avance considerable

a la hora de afrontar el desarrollo de sitios Web complejos (HTML,

DHTML, XML, XSL, etc.) y cambia por concepto la idea habitual de

que JavaScript es un lenguaje tan sencillo como limitado.

El lenguaje JavaScript se utiliza normalmente para crear pequeños

bloques de código dentro de las páginas web. Con ellos es posible

controlar los eventos originados por la interacción de los usuarios,

comprobar los formularios y en general, llevar a cabo todo un sinfín

de pequeñas tareas rutinarias y simples. Ahora bien, a medida que

las páginas se complican y ofrecen más posibilidades a los

usuarios, los scripts también crecen, en tamaño y complejidad. En

estos casos el código resultante suele ser bastante confuso,

ineficiente y poco reutilizable, debido principalmente a la falta de

conocimientos serios acerca de este lenguaje de programación, así

como al hecho de que normalmente no se le concede demasiada

importancia a este tipo de desarrollos. Sin embargo el lenguaje

JavaScript dispone de los recursos necesarios para trabajar con

orientación a objetos, que si no se ajusta por completo a la

metodología ortodoxa, sí permite al menos organizar el código

98

dando lugar a scripts más reducidos, eficientes y reutilizables.

Creación de objetos: el constructor, las propiedades y los métodos

El lenguaje JavaScript cuenta con varios objetos predefinidos. Por

ejemplo: window, document, form, etc. Todos ellos tienen una serie

de métodos y propiedades. De manera equivalente el programador

tiene la facultad de definir los objetos que considere necesarios. Un

objeto queda definido por su constructor. En JavaScript, éste no es

más que una función que se define de manera especial. El

siguiente fragmento de código muestra un ejemplo:

function MyDate(year, month, date)

{

this.year = year;

this.month = month;

this.date = date;

return this;

}

El objeto MyDate representa una fecha. Cuenta con tres

propiedades, year, month y date, que se corresponden

respectivamente con el año, el mes y el día de la fecha. La palabra

reservada this se emplea para hacer referencia al propio objeto.

2.2.8.6.10. LENGUAJES BASADOS EN CLASES vs BASADOS EN

PROTOTIPOS

Los lenguajes orientados a objetos basados en Clases, tales como

Java y C++, están fundamentados sobre los conceptos de clase e

instancia. Donde la clase establece la naturaleza compartida por un

grupo de objetos y las instancias son los objetos que comparten

dichos objetos.

Una clase define todas las propiedades (considerando los métodos

y los campos en Java, o miembros en C++, para considerarse

como propiedades) que caracterizan a un cierto conjunto de

objetos. Una clase es una cosa abstracta, más que cualquier

miembro particular de un conjunto de objetos que describe. Por

ejemplo, la clase Empleado podría representar el conjunto de todos

los empleados.

99

Una instancia, por otro lado, es la particularización de una clase (se

usa instanciación, por abuso de lenguaje); esto es, uno de sus

miembros. Por ejemplo, Victoria podría ser una instancia de la

clase Empleado, representando a un individuo particular como un

empleado. Una instancia tiene exactamente las propiedades de su

clase padre (no más, no menos)

Un lenguaje basado en prototipos, tal como JavaScript, no hace

esta distinción, simplemente tiene objetos, que son

simultáneamente clase e instancia: son clase con respecto de

aquellos objetos que se crean como instancias suyas y objetos en

si, tomados como instancias de una clase implícita, que se

establece con su creación, y se conoce como su prototipo. Un

lenguaje basado en prototipos tiene la noción de un objeto

prototipo, un objeto utilizado como una plantilla de la cual se

obtiene las propiedades iniciales para un nuevo objeto. Cualquier

objeto puede especificar sus propias propiedades, tanto al ser

creado como en tiempo de ejecución. Adicionalmente, cualquier

objeto puede estar asociado como el prototipo de cualquier otro

objeto, permitiendo que el segundo objeto comparta las

propiedades del primero. Y, el prototipo puede ser modificado

dinámicamente de modo que se afecten en cascada todos los

objetos que comparten tal prototipo.

DEFINIENDO UNA CLASE

En los lenguajes basados en clases, se define una clase en una

definición de clase separada. En esta definición puede especificar

métodos especiales, llamados constructores, para crear instancias

de una clase. Un método constructor puede especificar valores

iniciales para las propiedades de la instancia y desarrollando

procesamiento apropiado en tiempo de creación. Utilice el operador

new en asociación con el método constructor para crear instancias

de las clases.

JavaScript sigue un modelo similar, pero no tiene una definición de

clase por separado del constructor. En su lugar, define una función

100

constructora para crear objetos con un conjunto inicial particular de

propiedades y valores. Cualquier función JavaScript puede ser

utilizada como un constructor. Utilice el operador new con una

función constructora para crear un nuevo objeto.

SUBCLASES Y HERENCIA

Un lenguaje basado en clases, crea una jerarquía de clases por

medio de la definición de clases. En una definición de clases,

puede especificar que la nueva clase sea una subclase de una

clase ya existente. La subclase hereda todas las propiedades de la

superclase y adicionalmente puede añadir nuevas propiedades o

modificar las heredadas. Por ejemplo, asumiendo que la clase

Empleado incluye solamente las propiedades del nombre y

departamento y que Administrador es una subclase de Empleado

que añade la propiedad reporta. En este caso, una instancia de la

clase administrador puede tener tres propiedades: nombre,

departamento y reporta.

JavaScript implementa la herencia permitiendo asociar un objeto

prototipo con cualquier función constructora. Así que, puede crear

exactamente el ejemplo Empleado-Administrador, pero utiliza una

terminología ligeramente diferente. Primero defina la función

constructora de Empleado, especificando las propiedades del

nombre y departamento. Luego, defina una función constructora

Administrador, especificando la propiedad reporta. Finalmente,

asigne un nuevo objeto Empleado como el prototipo para la función

constructora Administrador. Luego, cuando cree un nuevo

Administrador, este hereda las propiedades de nombre y

departamento del objeto Empleado.

AÑADIENDO Y REMOVIENDO PROPIEDADES

En los lenguajes basados en clases, típicamente crea una clase en

tiempo de compilación y luego instancia la clase ya sea en tiempo

de compilación o en tiempo de ejecución. No puede cambiar el

número o tipo de las propiedades de una clase después de definir

101

la clase. En JavaScript, sin embargo, en tiempo de ejecución puede

añadir o eliminar propiedades de cualquier objeto. Si añade una

propiedad a un objeto que es utilizado como prototipo para un

conjunto de objetos, los objetos para los cuales este es el prototipo

también obtienen la nueva propiedad.

2.2.7. SCRUM46

Es un enfoque iterativo para el desarrollo de software estrechamente

alineado con los principios ágiles y el Manifiesto Ágil. Scrum se

compone de una serie de bloques de tiempo llamado sprints, que se

centran en la distribución de trabajo para el desarrollo de software. Un

sprint típico tiene una longitud de dos a cuatro semanas y se define

por un objetivo o contenido que ayuda a aclarar el objetivo del sprint.

Los sprints están aislados de cambios, permitiendo al equipo a

centrarse en la entrega de software de trabajo sin distracciones.

Scrum se enfoca en ayudar a la entrega del proyecto a las personas

comprometidas con el desarrollo del mismo.

Scrum, es un marco de trabajo para el desarrollo ágil de proyectos, en

principio surgido en la industria del software, pero de suficiente

sencillez y flexibilidad como para ser aplicado en contextos muy

diversos. Dentro de este marco, el proceso de desarrollo de un

proyecto se concibe como una sucesión de ciclos cortos de trabajo

denominados sprints, obteniendo de cada uno de ellos un producto

funcional que va completándose en forma iterativa.

Esta forma de concebir la gestión de proyectos es radicalmente

diferente al modo secuencial en que se afrontan tradicionalmente los

mismos, dividiéndolos en etapas, sucesivas y especializadas,

planificadas a priori en forma detallada; proponiendo en cambio un

desarrollo en forma iterativa, como trabajo de un equipo

multidisciplinario o crosfuncional (scrumteam) sobre una versión

completa del producto, centrada en el valor para el cliente o

destinatario.

Es así que uno de los roles clave definidos en Scrum es el 46

PRO AGILE .NET DEVELOPMENT WITH SCRUM , Jerrel Blankenship, Matthew Bussa, an Scott Millett.

102

denominado propietario del producto (product owner), que participa

activamente en el proceso de desarrollo, facilitando la comprensión

por parte del equipo de los aspectos prioritarios y centrales del

resultado esperado. Es quien representa al cliente, con una fuerte y

continua interacción con el equipo, facilita desde el inicio la clara

percepción de la visión del producto y de los aspectos que se

consideran de valor sustancial en el mismo. Al mismo tiempo que

provee retroalimentación continua al equipo sobre estos aspectos,

adquiere una comprensión de las posibilidades y dificultades a partir

de la comunicación con ellos.

Con el fin de guiar al equipo en los principios de trabajo implícitos en

un enfoque ágil de gestión, se define otro rol relevante: el scrum

master o facilitador, quien es responsable de orientar al equipo en la

aplicación de las prácticas adecuadas para lograrlos beneficios

esperados de esta modalidad de gestión, al mismo tiempo que se

encarga de remover impedimentos y reducir las fricciones que la

dinámica de trabajo pueda producir. Trabajar de esta forma exige en

etapas tempranas de un proyecto lograr una visión clara y enfocada

del objetivo a corto plazo, pues se apunta a obtener en un lapso de

tiempo reducido una versión “demostrable” del producto, aunque

restringida a sus características más importantes. Esto induce a

concentrarse en los aspectos de mayor relevancia. Se espera de cada

iteración o sprint, un entregable denominado “incremento” que es

considerado un producto potencialmente completo en su totalidad y

listo para su utilización. Esto promueve una gran transparencia

respecto a los problemas que se interponen en su desarrollo, así

como sobre las capacidades del equipo para lograrlo.

Este ciclo corto de trabajo también exige al equipo un alto grado de

interacción para concretar el objetivo, favoreciendo que surjan

tempranamente las dificultades o impedimentos que serán afrontados

diariamente a través de reuniones de seguimiento, breves y

enfocadas, tradicionalmente realizadas de pie (daily stand-up

meetings). Estas reuniones no sólo apuntan a realizar un control del

avance sino también a coordinar esfuerzos para superar obstáculos,

103

compartir estrategias y técnicas para afrontar situaciones y mejorar la

cohesión del equipo de trabajo.

Es así que cada sprint se desarrolla en tres fases: una reunión de

planificación, un período de trabajo a lo largo del cual se realizan las

reuniones diarias de seguimiento, y una reunión de revisión del

producto desarrollado en el sprint, denominado “incremento”, seguido

de una reunión de evaluación del proceso de trabajo con miras a

mejorarlo en forma continua, denominada “retrospectiva”. Un proyecto

completo entonces será visto como una sucesión de sprints a través

de los cuales se irá perfeccionando el producto objetivo hasta que el

product owner considere que se ha alcanzado el estado deseado. Este

enfoque iterativo de desarrollo permite una máxima flexibilidad a la

hora de especificar requisitos y recibir cambios en los mismos, al

mismo tiempo que produce en pocos ciclos de trabajo un equipo

cohesionado y sinérgico.

Este proceso se apoya a su vez en tres instrumentos que dan

visibilidad y soportan diferentes aspectos del mismo. Primero, una

lista de los requisitos o características del producto, también

conocidas como “historias de usuario”, porque representan el relato

desde el punto de vista del product owner, de lo que se necesita o

desea que el producto posea y proporcione como funcionalidad,

definiendo también el grado de prioridad entre ellas, denominada “Pila

del producto” (ProductBacklog). Segundo, una lista producida antes de

iniciar cada sprint, donde se define qué “historias de usuario” serán

satisfechas en ese ciclo de trabajo, así como las tareas necesarias

para lograrlo, denominada “Pila del sprint” (Sprint Backlog), que es

preparada por el equipo de trabajo con la colaboración del product

owner y finalmente contendrá la estimación del esfuerzo o tamaño de

cada tarea y la asignación del responsable. Tercero, a través del

desarrollo de un sprint, en base a cómo se irán completando las

tareas se construye lo que se denomina “gráfico de burndown”, una

herramienta que permite visualizar rápidamente la cantidad de trabajo

remanente y cómo se va concluyendo a través del tiempo, facilitando

la detección temprana de dificultades con el fin de actuar sobre ellas

104

en forma inmediata.

Resumiendo, Scrum se caracteriza por tres roles, tres reuniones y tres

artefactos:

Roles

o Propietario del Producto (product owner),

o Scrum Master o facilitador,

o Equipo (scrumteam).

Reuniones

o Planificación del Sprint (sprint planning),

o Seguimiento diario del Sprint (daily scrum),

o Revisión del Sprint y Retrospectiva (sprint review/

retrospective).

Artefactos

o Pila de producto (productbacklog),

o Pila de Sprint (sprint backlog),

o GraficoBurndown (burndown chart).

Figura 19: Flujo de trabajo entre elementos de Scrum

Fuente: Jerrel Blankenship, Matthew Bussa and Scott Millett, Pro Agile .NET

Development with Scrum

105

CAPITULO III

ESTUDIO DE

FRAMEWORKS PARA LA

IMPLEMENTACION DE

APLICACIONES WEB DEL

LADO DEL CLIENTE

BASADOS EN

JAVASCRIPT, CSS, HTML

106

3.1. DOJO TOOLKIT47

Dojo es un framework que contiene APIs y widgets (controles) para

facilitar el desarrollo de aplicaciones Web que utilicen tecnología AJAX.

Contiene un sistema de empaquetado inteligente, los efectos de UI, drag

and drop APIs, widget APIs, abstracción de eventos, almacenamiento de

APIs en el cliente, e interacción de APIs con AJAX.

Resuelve asuntos de usabilidad comunes como pueden ser la

navegación y detección del navegador, soportar cambios de URL en la

barra de URLs para luego regresar a ellas (bookmarking), y la habilidad

de degradar cuando AJAX/JavaScript no es completamente soportado

en el cliente. Es conocido como "la navaja suiza del ejército de las

bibliotecas JavaScript". Proporciona una gama más amplia de opciones

en una sola biblioteca JavaScript y es compatible con navegadores

antiguos.

3.1.1. ORIGEN Y DESARROLLO

Dojo Toolkit tiene su origen en 2004 con Alex Russell, quien inició un

proyecto para mejorar el desarrollo de DHTML. Para ello contactó con

otros programadores, de los cuales destacan David Schontzler y

Dylan Schiemann. Ellos, junto con Russell, son considerados los

fundadores de este framework. Sin embargo, no fueron los únicos:

una amplia comunidad de desarrolladores quisieron contribuir en el

proyecto, que concluyó en la formación de Dojo Foundation.

A día de hoy se han realizado ocho grandes actualizaciones en las

que han participado sesenta desarrolladores con más de un millón de

descargas.

Es de destacar que esta biblioteca es de código abierto y se puede

descargar de forma gratuita en su página oficial. La licencia nos

permite crear aplicaciones, utilizarlo en productos comerciales y

modificarlo. Cuenta con el patrocinio de IBM, Google, AOL y

Nexaweb.

Estas son algunas razones por las que esta caja de herramientas está

47

RESUMEN DE TECNOLOGÍA DOJO TOOLKIT, Disponible en: [http://es.wikipedia.org/wiki/Dojo_toolkit]

107

cubierta por una gran comunidad, con multitud de desarrolladores e

información que la hacen muy accesible y transparente de cara a

nuevos usuarios. De hecho, cualquier usuario puede navegar por el

chat IRC y conversar con contribuidores del proyecto e incluso

participar en reuniones oficiales para discutir temas estratégicos.

3.1.2. CARACTERÍSTICAS

3.1.2.1. COMPLEMENTOS

Los complementos de Dojo son componentes pre empaquetados de

código JavaScript, HTML y CSS que pueden ser usados para

enriquecer aplicaciones web.

Menús, pestañas y tooltips.

Tablas ordenables, gráficos dinámicos y dibujado de vectores

2D.

Efectos de animación y la posibilidad de crear animaciones

personalizables.

Soporte para arrastrar y soltar.

Formularios y rutinas de validación para los parámetros.

Calendario, selector de tiempo y reloj.

Editor online de texto enriquecido.

Núcleo de componentes (dijit) accesible desde versiones

anteriores y lector de pantalla.

3.1.2.2. COMUNICACIÓN ASÍNCRONA

Una característica importante de las aplicaciones AJAX es la

comunicación asíncrona entre el navegador y el Servidor.

Tradicionalmente, se realizaba con el comando JavaScript

XMLHttpRequest. Dojo provee de una capa de abstracción

(dojo.io.bind) para varios navegadores web con la que se pueden usar

otros transportes (como IFrames ocultos) y diferentes formatos de

datos. De esta forma podemos obtener los campos que se van a

enviar como parámetros del formulario de una manera sencilla.

108

3.1.2.3. SISTEMA DE PAQUETES

Dojo provee de un sistema de paquetes para facilitar el desarrollo

modular. El script de inicio inicializa una serie de jerarquías de

paquetes de espacios de nombre (io, event, etc.) bajo el paquete raíz

dojo. Después de la inicialización del paquete dojo, cualquier otro

paquete puede ser cargado (vía XMLHttpRequest o cualquier otro

transporte similar) usando las utilidades ofrecidas en el arranque.

También es posible inicializar paquetes adicionales dentro o al mismo

nivel que el paquete dojo, permitiendo extensiones o bibliotecas de

terceros.

Los paquetes de Dojo pueden contener múltiples archivos. Cualquier

paquete o archivo puede depender de otro. En este caso, cuando el

paquete es cargado, cualquier dependencia será también cargada.

Dojo también brinda una manera de crear perfiles; el sistema ofrece

una lista de paquetes y usa Apache Ant para crear un archivo

JavaScript comprimido que contiene dichos paquetes y dependencias.

De esta manera se tiene todo el código necesario para ser cargado y

es inicializado de una sola vez, permitiendo así el cacheado (la

mayoría de los navegadores web no permiten el cacheado de

archivos vía XMLHttpRequest).

3.1.2.4. ALMACENAMIENTO DE DATOS EN EL CLIENTE

Adicionalmente, ofrece funciones para leer y escribir cookies,

proporcionando en el lado cliente una abstracción llamada Dojo

Storage. Dojo Storage permite a la aplicación web almacenar datos en

el lado cliente, persistencia y seguridad. Cuando se incluye en una

página web, determina cual es el mejor método para almacenar la

información. Cuando la aplicación web ha sido cargada desde el

sistema de archivos (por ejemplo desde file://URL), Dojo Storage usa

de manera transparente XPCOM en Firefox y ActiveX en Internet

Explorer para mantener la persistencia de la información. El

desarrollador que use Dojo Storage no se tiene que preocupar de

esto, ya que Dojo tiene una capa de abstracción con métodos put() y

get().

109

3.1.2.5. ALMACENAMIENTO EN EL SERVIDOR

Desde enero de 2007, Dojo incluye las siguientes implementaciones

de almacenamiento de datos en el paquete dojo.data:

CsvStore: almacenamiento de sólo lectura y acceso CSV.

OpmlStore: almacenamiento de sólo lectura y lectura

jerárquica desde archivos en formato OPML.

YahooStore: almacenamiento de sólo lectura que obtiene los

resultados del servicio web del buscador de Yahoo Search!.

DeliciousStore: almacenamiento de sólo lectura que obtiene

los marcadores del servicio web que ofrece Del.icio.us.

RdfStore: almacenamiento de solo lectura que usa SPARQL

para comunicarse con el Servidor de datos RDF.

3.1.2.6. SOPORTE PARA ADOBE INTEGRATED RUNTIME (AIR)

Dojo permite usar aplicaciones Adobe AIR basadas en JavaScript. Ha

sido modificada para satisfacer los requisitos de seguridad de Adobe.

La consultora SitePen ha desarrollado una aplicación Adobe AIR

llamada Dojo Toolbox usando Dojo, en la que se incluye un API y un

sistema de construcción gráfico. Generalmente, el sistema de

construcción se ejecuta dentro de Rhino, pero esta aplicación AIR

puede ejecutarse desde el mismo AIR, sin el uso de Java.

3.1.3. ARQUITECTURA

Como caja de herramientas, la arquitectura de Dojo Toolkit consta de

una serie de componentes principales.

DOJO BASE.

Dojo Base es el kernel de Dojo: una biblioteca compacta y optimizada

que, entre otras muchas cosas, ofrece utilidades AJAX y un sistema

de paquetes y herramientas para crear y manipular jerarquías de

herencia. La Base se recoge en un único archivo llamado dojo.js.

Todas las funcionalidades de Base son accesibles a través de

funciones o atributos dojo.*.

DOJO CORE.

Dojo Core se construye sobre Dojo Base y ofrece soluciones más

110

avanzadas como son los efectos de animación, funcionalidades "drag

and drop" o el manejo de cookies. Cualquier recurso externo a dojo.js

que se tiene que importar de manera explícita es parte de Core. El

sistema de paquetes de Dojo utiliza mecanismos simples como los

#include de C o import de Java para acceder a sus servicios.

DIJIT.

Dijit (Dojo Widget) es una biblioteca de widgets para crear interfaces

gráficos. Está construida directamente sobre Dojo Core y en

ocasiones no requiere de código JavaScript para ser utilizada. Los

widgets son altamente portables y se pueden compartir fácilmente en

cualquier Servidor o incluso funcionar localmente sin Servidor web

mediante el protocolo file//.

DOJOX.

DojoX (Dojo Extensions) es una colección independiente de

subproyectos en estado de incubación que no encajan a la perfección

en Dojo Core o Dijit. Cada subproyecto suele incluir un archivo

readme con información sobre su estado. Se trata de la parte del

proyecto abierta a nuevas ideas. Su independencia permite que las

altas expectativas y la estabilidad del resto de componentes de Dojo

Toolkit no se vean comprometidas.

UTIL.

Util es una colección de utilidades que incluye una unidad de prueba y

herramientas para crear versiones personalizadas de Dojo. Estas

herramientas pueden disminuir el tamaño del código e incluir capas

con distintos archivos JavaScript. Esta disminución se consigue a

través de ShrinkSafe, un eficiente motor de compresión independiente

de Dojo.

3.2. EXTJS48

ExtJS es el framework de JavaScript que consta de varias Apis para el

desarrollo de aplicaciones web interactivas usando tecnologías como

AJAX, DHTML y DOM. Fue desarrollada por Sencha. Originalmente

48

EXTJS IN ACTION: Jesus Garcia.

111

construida como una extensión de la biblioteca YUI por Jack Slocum, en

la actualidad puede usarse como extensión para las bibliotecas YUI,

jQuery y Prototype. Desde la versión 1.1 puede ejecutarse como una

aplicación independiente.

El ExtJS no sólo proporciona widgets de interfaz de usuario sino que

también contiene una serie de otras características. Estas se dividen en

seis áreas principales:

core

UI components

comunicación remota

data services

drag and drop

general utilities

Figura 20: Arquitectura de Librerias de ExtJS in Action: Jesus Garcia

3.2.1. CORE

Está compuesta de muchas de las características básicas tales como

comunicación mediante Ajax, manipulación DOM, y gestión de

eventos. Todo lo demás es dependiente de este núcleo pero el

núcleo no depende de nada.

3.2.2. UI COMPONENTS49

Textfield._ Añade características al campo de entrada HTML

existente como validaciones básicas, un método de validación

49

EXTJS IN ACTION: Jesus Garcia.

112

personalizado, cambio de tamaño automático, y el filtrado de

teclado a través de expresiones regulares.

Textarea._ Extiende el TextField y es un campo de entrada de

varias líneas.

NumberField._ Este control hace casi el total de las

validaciones para los números enteros y flotantes.

ComboBox._ Es una combinación de un campo de texto de

entrada general y una casilla desplegable para darle una

combinación de campos de entrada flexible y altamente

configurable. El ComboBox tiene la capacidad de ejecución

automática de texto (conocido como de escritura anticipada) en

el área de introducción de texto, y junto con un almacén de

datos remoto, se puede trabajar con el Servidor para filtrar los

resultados. Si el cuadro combinado está realizando una

solicitud a distancia contra un gran conjunto de datos, puede

habilitar la paginación resultado estableciendo la propiedad

pageSize.

La Figura xxx ilustra la anatomía de una carga remota y

ComboBox con paginación.

Figura 21:Ejemplo de Renderizado de controles ExtJS

TimeField._ Es otro control que permite agregar fácilmente un

selector de tiempo a un formulario.

113

HTMLEditor._ Conocido en Extjs como WYSIWYG, o lo que

ves es lo que obtienes, editor. Este control permitir a los

usuarios introducir texto rico en formato HTML sin tener que

obligarnos a dominar HTML y CSS. permitiendo configurar los

botones de la Barra de herramientas para prevenir ciertas

interacciones por el usuario.

DateField._ Es un pequeño widget que permite al usuario

introducir un fecha a través de un campo de entrada o

seleccionarla de un DatePicker.

CheckBox._ Control de selección que puede ser agrupado en

un contenedor CheckboxGroup que proporciona un conjunto de

métodos de conveniencia, validaciones y la disposición para

organizar las casillas de verificación en las columnas.

RadioGroup._ Este control extiende la clase CheckboxGroup,

con la única diferencia que solo puede seleccionarse un radio a

la vez.

TabPanels._ También llamados pestañas sirven para dividir la

información por secciones o por categorías.

ToolBars._ Este control actúa como contenedor agrupando

múltiples controles en la parte superior de un formulario.

ExtJS Desktop ._Este control actúa como un escritorio virtual y

permite registrar múltiples iconos (lanzadores de aplicaciones),

en su interior mostrándolos de forma similar a la del escritorio

de Windows.

Layouts._ y maquetación._ Componente que permite organizar

nuestros controles de diferentes formas según el layout

elegido.

Sliders._ Control deslizante dotado de posibilidades como

múltiples punteros deslizantes y configuración a través de CSS.

Charts._ Desde la versión tres de la librería de Ext JS es la

posibilidad crear fácilmente gráficas de barras, lineares y de

pastel a partir de un Store.

ListBoxy TreeView._ Estos controles permiten la carga de

114

datos desde un Store,

GridPanel._ Grid que puede actuar en modo de solo lectura o

también en modo escritura permitiendo el desplazamiento y

ordenamiento de columnas

3.2.3. WEB REMOTING

Es un medio de JavaScript (a distancia) para realizar llamadas a

métodos que son definidos y expuestos en el Servidor, lo que se

conoce comúnmente como un procedimiento remoto o RPC. Es

conveniente para los entornos de desarrollo en los que desea exponer

los métodos del Servidor al cliente y evitar el trabajo adicional que

genera la gestión de métodos en Ajax.

3.2.4. DATA SERVICES

Esta sección se encarga de las necesidades de datos, que incluyen ir

a buscar, analizar y cargar la información en los stores (encargados

de alimentar de datos a las interfaces de usuario), mediante la lectura

de Array, XML y JSON (JavaScript Object Notation serializado).

3.2.5. DRAG AND DROP

Es un pequeño framework dentro ExtJS, que permite dotar a los

componentes ExtJs o a cualquier elemento HTML de la posibilidad de

arrastrar y soltar. Este framework incluye todo lo necesario para

gestionar el proceso de arrastrar y soltar.

3.2.6. GENERAL UTILITIES

La sección de utilidades comprende clases interesantes, utilidades

que ayudan con las tareas rutinarias. Por ejemplo Ext.util.Format,

permite dar formato transformar datos con facilidad. Otra utilidad

interesante es el singleton CSS, que permite crear, actualizar, cambiar

y eliminar hojas de estilo, así como solicitar el navegador para

Actualizar su caché.

115

3.3. YUI (INTERFAZ DE USUARIO YAHOO)

YUI es una biblioteca JavaScript de código abierto para la construcción

de aplicaciones web ricas en interactividad, la misma que hace uso de

técnicas tales como Ajax, DHTML y DOM scripting.

La página de Yahoo! fue la primera en usar YUI en el verano de 2005.

YUI fue lanzado para el uso público en febrero de 2006. Su activo

desarrollo por parte del equipo de ingenieros de Yahoo! permitió que en

septiembre de 2009, Yahoo! lanzara YUI 3, una nueva versión

reconstruida desde cero con el objetivo de modernizar la biblioteca e

incorporar las lecciones aprendidas de YUI 2. Entre las mejoras

incorporadas están un selector de CSS accionado por un motor para la

recuperación de elementos DOM, un mayor énfasis en la granularidad

de módulos, un archivo base más pequeño que carga otros módulos

cuando sea necesario, y una variedad de modificaciones sintácticas

destinados a hacer que la escritura de código sea más rápida y fácil.

Esta biblioteca se divide en seis componentes que su vez se

descompone en componentes individuales que pueden ser utilizados

según sea necesario sin tener que incluir toda la biblioteca en un

proyecto. Todos los componentes tienen una dependencia en el objeto

YAHOO Global que establece algunas bases necesarias. Después de

eso, la mayoría de los componentes también necesitan la colección

DOM y la Utilidad de eventos. Cada componente se presenta en una

versión miniaturizada, una versión estándar, y una versión de

depuración, esta última registra todos los tipos de información que

permite el funcionamiento interno de los componentes a ser depurados.

3.3.1. NÚCLEO50

El núcleo de YUI es un ligero conjunto de herramientas (31KB la

versión compacta) para manejar eventos y manipular el árbol DOM.

YAHOO Global Object: Los Objetos Globales Yahoo

contienen utilidades y otras infraestructuras base para la

biblioteca.

DomCollection: Ayuda para la manipulación del árbol DOM,

50

RESUMEN DE YAHOO UI LIBRARY, Disponible en: [http://es.wikipedia.org/wiki/Yahoo!_UI_Library]

116

incluyendo posicionamiento de elementos y gestión de estilos

CSS.

EventUtility: Permite acceder de forma segura y sencilla a los

eventos de un navegador web y, mediante el objeto

CustomEvent, publicar y suscribirse a eventos customizados.

3.3.2. UTILIDADES51

Animation: Ayuda a crear efectos animados.

Browser History Manager: Ayuda complementaria para el

botón Atrás y la gestión de Marcadores/Favoritos de los

navegadores web.

Connection Manager: Ayuda para manejar el objeto

XMLHttpRequest.

Cookie: Permite gestionar las cookies.

DataSource: Proporciona una interfaz común para que otros

componentes puedan interactuar con diferentes tipos de datos.

Drag and Drop: Facilita la creación de eventos y elementos

que pueden ser arrastrados.

Element: Proporciona una capa para los elementos que facilita

el añadido de escuchadores, manipulación del árbol DOM y

atributos 'get' y 'set'.

Get: La utilidad Get soporta la carga asíncrona de datos y

archivos de estilos CSS externos.

ImageLoader: Permite aplazar la carga de imágenes que no

son visibles durante la carga de la página, proporcionando un

aumento del rendimiento.

JSON: Proporciona métodos para el tratamiento de datos

JSON. Estos métodos están basados en el trabajo de Douglas

Crockford.

Resize: Permite redimensionar los elementos HTML.

Selector: Permite referenciar elementos HTML mediante la

sintaxis CSS3.

51

UTILIDADES DE YAHOO UI LIBRARY, Disponible en: [http://es.wikipedia.org/wiki/Yahoo!_UI_Library]

117

YUI Loader: Es un cargador del lado cliente que permite la

carga de forma dinámica de cualquier componente y

dependencia de la biblioteca al vuelo.

3.3.3. CONTROLES / WIDGETS

AutoComplete: Proporciona la función de auto completado

(lista de sugeridos) para los usuarios. Soporta varios formatos

de datos, tanto del lado cliente como del lado Servidor (vía

XMLHttpRequest).

Button: Permite la creación de botones gráficos que funcionan

como un botón tradicional en HTML.

Calendar: Un calendario gráfico y de control dinámico.

Charts: Permite la creación de diferentes tipos de gráficos

(lineales, de barras, etc.).

Color Picker: Proporciona una interfaz gráfica para la

selección de colores.

Container: Proporciona una interfaz gráfica como Tooltip,

paneles, cuadros de diálogo, etc.

DataTable: Una potente herramienta para mostrar tablas

tabulares en una página web. Permite la ordenación de

columnas tanto en el lado cliente como en el Servidor,

paginación, scroll, selección de filas, redimensionado de

columnas y edición inline.

ImageCropper: Proporciona una interfaz gráfica para recortar

una imagen desde el lado cliente.

Layout Manager.

Menu: Proporciona una API para la creación de menús

flotantes, barras de menú y menús de contexto.

Rich Text Editor: Es un sofisticado editor de texto rico modular

del lado cliente y muy configurable.

Slider: Proporciona un elemento genérico que permite al

usuario elegir entre un rango de valores.

TabView: Permite la navegación entre pestañas, soportando la

118

carga dinámica de contenido vía XMLHttpRequest.

TreeView: Añade un árbol de contenido con nodos que se

pueden contraer y expandir para navegar por los elementos.

Uploader: Permite la carga de varios archivos mostrando una

barra de progreso.

3.3.4. CSS HERRAMIENTAS52

Aunque YUI es ante todo un marco de JavaScript, también

proporciona recursos CSS. El apoyo de YUI a CSS se remonta a

versiones muy tempranas de YUI 2, ahora en su nueva versión

incluyen:

YUI CSS Reset, que anula fuera de estilos por defecto del

navegador.

YUI CSS Base, que junto con YUI Cambiar CSS, establece

que todos los navegadores tienen una línea de base común ver

y sentir.

YUI CSS Fonts, lo que proporciona un conjunto coherente de

tamaños de fuente en todos los navegadores.

YUI Grids CSS, que le permite crear rápidamente diseños

sofisticados que utilizan un mínimo CSS.

Aunque se desarrolló junto a la API de JavaScript YUI 3, las

hojas de estilo de ninguna manera están atadas a YUI JS 3.

Esta biblioteca trabaja muy bien con YUI 2, con otras

bibliotecas JavaScript o sin JavaScript en absoluto.

3.3.5. HERRAMIENTAS DE DESARROLLO

Logger: Permite escribir mensajes de log en una consola, o

utilizar las que proporcionan la extensión Firebug para el

navegador Mozilla Firefox o la consola JavaScript del

navegador Safari.

Profiler: Para perfilar el código JavaScript.

ProfilerViewer: Usado con el anterior componente (Profiler)

52

YUI3 COOKBOOK: Evan Goer

119

proporciona un perfilado visual.

YUI Test: Permite añadir unidades de testeo al código

JavaScript.

3.3.6. HERRAMIENTAS DE CONTRUCCIÓN

YUI Compressor Es un compresor de código JavaScript y

CSS diseñado para proporcionar un resultado 100% seguro.

120

CAPITULO IV

IMPLEMENTACION DE

FRAMEWORK MODELO

VISTA PRESENTADOR

PARA APLICACIONES WEB

DEL LADO DEL CLIENTE

BASADOS EN

JAVASCRIPT, CSS, HTML

121

4.1. DESCRIPCION DEL PROBLEMA

Actualmente existe un conjunto de Framework como EXTJS, YUI, DOJO

TOOLKIT que están basado en HTML, JavaScript y CSS que nos

permiten la implementación y desarrollo de aplicaciones web del lado del

cliente, Estos Framework constan de un conjunto de librerías que

facilitan el desarrollo de aplicaciones Web, permitiendo resolver asuntos

de usabilidad comunes como pueden ser la navegación y detección del

navegador, soportar cambios de URL en la barra de URLs para luego

regresar a ellas (bookmarking).

Cuentan con un número considerable widgets o controles de usuario que

nos permiten interactuar con el usuario de manera similar a las

aplicaciones de escritorio, Así como también de Frameworks necesarios

para poder implementar el patrón modelo vista controlador.

Actualmente estos Framework que si bien es cierto facilitan la

implementación de aplicaciones web del lado del cliente, a la hora de

utilizarlos muestran deficiencias en algunos aspectos como son:

Definición de Interface de Usuario._ El problema principal en

la definición de interfaces de usuario es el uso del lenguaje

JavaScript el cual no fue diseñado para definir Interfaces de

usuario sino más bien para poder interactuar con las mismas.

Actualización de datos en los Patrones de Diseño._ Esta

deficiencia obliga al programador a definir controladores

encargados de sincronizar los datos de las diferentes capas.

Debido a estas deficiencias es necesario desarrollar un Framework que

permita la implementación de un patrón de diseño mucho más simple

como es el patrón Modelo Vista Presentador, así como también un motor

generador de interfaz gráfica de usuario en base a descriptores XML.

4.2. RESUMEN DEL PROYECTO

Este proyecto se encarga de la implementación de un Framework

Modelo Vista Presentador como controlador supervisado basado en las

librerías del Framework ExtJS la misma que fue elegida por estar entre

los Framework más utilizados, de mayor simplicidad en su uso y por

disponer de un número considerable de controles de usuario.

122

Entre las características principales que tendrá este Framework:

Definición de interfaz de usuario mediante documentos XML

(Extensible Markup Language).

Sincronización de la vista y el presentador a través de

descriptores en el Documento XML que define la interfaz de

usuario.

Sincronización del modelo y la vista en función a descriptores

definidos en un documento XML.

4.3. BENEFICIOS

Mejorar la reutilización de código e interfaces.

Mejorar la mantenibilidad de los proyectos.

Reducir el tiempo de desarrollo de aplicación web del lado del

cliente.

Poseer un Framework que nos permita la implementación del

patrón modelo vista presentador.

Delegar el diseño de interfaces de usuario a especialistas en el

área sin necesidad de que estos tengan conocimiento de

lenguajes de programación.

4.4. DESCRIPCIÓN DE LA METODOLOGÍA DE TRABAJO

4.4.1. INTRODUCCIÓN

Este documento describe la implementación de la metodología de

trabajo Scrum en el desarrollo de la tesis para obtener el Título

Profesional de Ingeniero Informático y de Sistemas de los Bachilleres

Jorge Francisco Castro Alvarez y Luis Rafael Callapiña Cosio para la

gestión de la implementación del proyecto RAFMVP.

Incluye junto con la descripción de este ciclo de vida iterativo e

incremental para el proyecto, los artefactos o documentos con los que

se gestionan las tareas de adquisición y suministro: requisitos,

monitorización y seguimiento del avance, así como las

responsabilidades y compromisos de los participantes en el proyecto.

123

4.4.1.1. PROPÓSITO DE ESTE DOCUMENTO

Facilitar la información de referencia necesaria a las personas

implicadas en la implementación y calificación del Framework

RAFMVP.

4.4.1.2. ALCANCE

Personas y procedimientos implicados en la implementación y

calificación del Framework RAFMVP.

4.4.2. DESCRIPCIÓN GENERAL DE LA METODOLOGÍA

4.4.2.1. FUNDAMENTACIÓN

Las principales razones del uso de un ciclo de desarrollo iterativo e

incremental de tipo Scrum para la ejecución de este proyecto son:

Sistema modular. Las características del sistema [Nombre del

sistema] permiten desarrollar una base funcional mínima y

sobre ella ir incrementando las funcionalidades o modificando

el comportamiento o apariencia de las ya implementadas.

Entregas frecuentes y continuas al cliente de los módulos

terminados, de forma que puede disponer de una funcionalidad

básica en un tiempo mínimo y a partir de ahí un incremento y

mejora continua del sistema.

Previsible inestabilidad de requisitos.

Es posible que el sistema incorpore más funcionalidades de las

inicialmente identificadas.

Es posible que durante la ejecución del proyecto se altere el

orden en el que se desean recibir los módulos o historias de

usuario terminadas.

Para el cliente resulta difícil precisar cuál será la dimensión

completa del sistema, y su crecimiento puede continuarse en el

tiempo suspenderse o detenerse.

124

4.4.2.2. VALORES DE TRABAJO

Los valores que deben ser practicados por todos los miembros

involucrados en el desarrollo y que hacen posible que la metodología

Scrum tenga éxito son:

Autonomía del equipo

Respeto en el equipo

Responsabilidad y auto-disciplina

Foco en la tarea

Información transparencia y visibilidad.

4.4.3. PERSONAS Y ROLES DEL PROYECTO.

Tabla Nº 6

Persona Contacto Rol

Luis Rafael Callapiña Cosio [email protected] Scrum Master

Jorge Francisco Castro Alvarez [email protected] Dueño de producto

Jorge Francisco Castro Alvarez [email protected] Equipo

Luis Rafael Callapiña Cosio [email protected] Equipo

Fuente: Elaboración propia

4.4.4. ARTEFACTOS

Documentos

Pila de producto o Product Backlog

Pila de sprint o Sprint Backlog

Sprint

Incremento

Gráficas para registro y seguimiento del avance.

Gráfica de producto o Burn Up

Gráfica de avance o Burn Down.

Comunicación y reporting directo.

Reunión de inicio de sprint

Reunión técnica diaria

Reunión de cierre de sprint y entrega del incremento

125

4.4.2.3. PILA DE PRODUCTO

Es el equivalente a los requisitos del sistema o del usuario en esta

metodología.

Se trata de una lista que contiene elementos denominados historias

de usuario, las cuales son descripciones genéricas de los

requerimientos con estimaciones a groso modo sobre la importancia

de la historia y el esfuerzo que costará desarrollarlas.

La pila de producto es elaborada por el dueño de producto (gestor de

producto) con la ayuda del Scrum Master (facilitador). El resultado de

este trabajo es la pila siguiente:

Tablas Nº 7

ID Nombre Cómo probarlo Importancia Estimación

1 Crear los componentes básicos adecuados para el modelo MVP.

Deben existir componentes Modelo, Vista y Presentador

10 13

2 Desarrollar las clases para el componente Presentador

Al modificar el valor de una variable enlazable en el Presentador, este cambio debe reflejarse en el Modelo o la Vista, según con quien sea enlazado esta variable.

9 5

3 Desarrollar las clases para el componente Vista

Al modificar el valor de una variable mediante la Vista, esta debe ser reflejada en el Modelo y en el Presentador.

8 8

4 Desarrollar las clases para el componente Modelo

El Modelo debe ser capaz de enlazarse al Presentador mediante descriptores en un documento XML y debe ser capaz de invocar servicios del lado del Servidor (RPC

9 8

126

o REST)

5 Procesador de XML que renderiza vistas en HTML y JavaScript

Definir una vista en XML y verla en HTML y JavaScript en el navegador.

7 5

6 Mecanismo para invocar eventos y métodos desde los documentos XML

Definir eventos y métodos en el Presentador y enlazarlos en las definiciones XML de las vistas y que estas funcionen.

5 8

7 Mecanismo de reutilización de componentes existentes

Embeber (anidar) vistas ya creadas con XML dentro de otras y que se rendericen sin problema en el navegador.

5 8

8 Mecanismo de Binding entre propiedades y vistas.

Al modificar el valor de una propiedad en el Presentador, esta se debe de modificarse en la Vista y viceversa.

7 21

9 Mecanismo de Binding entre métodos y eventos de las vistas.

Al invocar los eventos de la vista, estos deben invocar a métodos definidos dentro del Presentador.

7 21

10 Mecanismos de invocación de servicios del lado del cliente.

Se deben de obtener datos desde servicios REST desde el lado del Servidor.

9 34

11 Crear mecanismos de asistencia a desarrolladores (plugins)

El plugin debe estar disponible para algún IDE de desarrollo web.

7 21


4.4.2.4. PILA DEL SPRINT

Es el documento de registro de los requisitos detallados o tareas que

va a desarrollar el equipo técnico en la iteración (actual o que está

preparándose para comenzar).

127

Los responsables de este trabajo son el dueño de producto, que

absuelve dudas respecto de las historias a ser desarrolladas, el

equipo de desarrolladores, que se divide las tareas, colocan

estimaciones más exactas y otras, y el Scrum master que dirige la

reunión.

4.4.2.5. SPRINT

Cada una de las iteraciones del ciclo de vida iterativo Scrum. La

duración de cada sprint en la mayoría de casos es fija para todas,

pero esto no es una regla fija. Se puede acordar la duración de estos

según las tareas que se estén asignadas a este periodo de trabajo.

Para el control del proyecto se usó un sistema de control de proyectos

ágiles llamado PangoScrum y mostramos la lista de los sprints que se

desarrollaron y las fechas en las que se desarrollaron:

Figura 22: Pila de definición de Sprints

4.4.2.6. INCREMENTO

Parte o subsistema que se produce en un sprint y se entrega al gestor

del producto completamente terminado y operativo.

128

4.4.2.7. Gráfica de avance (Burn Down)

Gráfico que muestra el estado de avance del trabajo del sprint en

curso. El dueño del producto no tiene responsabilidades específicas

en este artefacto, salvo el de estar informado de este. El Scrum

master mantiene actualizado este gráfico con los datos obtenidos de

las reuniones diarias con el equipo de desarrollo.

4.4.2.8. REUNIÓN DE INICIO DE SPRINT

Reunión para determinar las funcionalidades o historias de usuario

que se van a incluir en el próximo incremento. En esta reunión

participan: el dueño de producto, el scrum master y el equipo de

desarrollo.

4.4.2.9. REUNIÓN TÉCNICA DIARIA

Puesta en común diaria del equipo con presencia del Coordinador del

proyecto o Scrum Manager de duración máxima de 10 minutos. Las

reuniones diarias durante este proyecto se realizaron por la mañana

antes del inicio de cada jornada, donde se intercambiaron los avances

del día anterior y el avance previsto para ese día.

4.4.2.10. REUNIÓN DE CIERRE DE SPRINT Y ENTREGA DEL

INCREMENTO.

Reunión para probar y entregar el incremento al gestor del producto.

En esta reunión participan el dueño de producto para realizar las

pruebas necesarias, el equipo de producto que realiza la

demostración y el scrum master que coordina y cumple la función de

facilitador. En algunos sprints la reunión de retroalimentación se

realizó al día siguiente de la entrega y hubo un descanso el resto de la

semana. En los últimos sprints las reuniones de entrega y de

retroalimentación se realizaron el mismo día, debido a la proximidad

de la fecha final prevista para la entrega final. Estos últimos sprints

fueron muy cortos y sin periodos de descanso.

129

4.4.5. RESUMEN DE SPRINTS

Para mostrar el desarrollo de cada uno de los sprints mostraremos las

capturas de los siguientes artefactos:

Pila de Sprint (Backlog).

Calendario.

Gráfico Burn Down.

4.4.2.11. SPRINT 1

Tabla Nº8

Objetivo Fecha de Inicio Fecha de Término

Componentes MVP terminados 03-09-2012 25-09-2012


Figura 23: Tiempo Estimado para la entrega del Sprint 1

130

Figura 24: Definición de Tareas del Sprint 1

Figura 25: Grafico Burndown que refleja el avance del Sprint 1 en función del tiempo

131

4.4.2.12. SPRINT 2

Tabla Nº9


Renderizador de HTML listo 01-10-2012 23-10-2012




132


4.4.2.13. SPRINT 3

TablaNº10


Binding de métodos y propiedades listos

29-10-2012 12-11-2012


133



134


4.4.2.14. SPRINT 4

Tabla Nº11


Integración con servicios del lado del Servidor terminados

13-11-2012 26-11-2012


135



136


4.4.2.15. SPRINT 5

Tabla Nº12


Plugins de desarrollo terminados 27-11-2012 07-12-2012


137



138

Figura 37: Grafico Burndown que refleja el avance del Sprint en función del tiempo

139

CAPITULO V

DISCUSIÓN RESULTADOS

140

CONCLUSIONES

1. Los Framework basados en Javascript y HTML son un resultado de la

evolución de capacidades implementadas en JavaScript teniendo como

base la orientación a documentos lo cual genera inconvenientes a la

hora de implementar aplicaciones web del lado del cliente.

2. Los Framework para la implementación de aplicaciones web del lado del

cliente basadas en JavaScript y HTML superan las limitaciones de

usabilidad e interacción de las aplicaciones web tradicionales debido a

que estas librerías se encarga de gestionar las solicitudes al servidor de

manera asíncrona.

3. La aparición de HTML5 reduce la brecha entre las aplicaciones de

escritorio y las aplicaciones web.

4. Se estudiaron las principales Framework orientados a desarrollo de

aplicaciones Web, estudio que sirvió para la elección del Framework en

el cual se basaría el desarrollo del framework modelo vista presentador

planteado en esta tesis.

5. Se implementó un Framework Modelo vista presentador para el

desarrollo de aplicaciones Web del lado del cliente el cual nos permite

enlazar los datos y métodos de los diferentes componentes en base a

descriptores definidos en documentos XML.

141

RECOMENDACIONES

1. Los Framework para desarrollo de aplicaciones Web del lado del cliente

son nuevos y complejos generando con esto problemas de

vulnerabilidad, fallas de usabilidad y seguridad. Para asegurarse de que

los usuarios de estas aplicaciones Web no sufran estos inconvenientes,

futuros trabajos deben buscar metodologías de probar la usabilidad y

seguridad de estas aplicaciones en el contexto de la experiencia del

usuario.

2. Para poder desarrollar aplicaciones web se recomienda el uso de los

diferentes patrones de diseño para así poder evitar problemas de

escalabilidad, mantenibilidad y reutilización de código.

3. Se propone como futuras investigaciones, El desarrollo de Controles de

Usuarios basados en JavaScript y HTML con mayor orientación al

desarrollo de aplicaciones Web.

4. Se propone como futuras investigaciones, El desarrollo de Frameworks

modelo vista controlador para las librerías como Dojo ToolKit y Yahoo UI

que permitan en desarrollo de aplicaciones Web del lado del cliente con

una menor orientación a documentos,

142

BIBLIOGRAFÍA

LIBROS

GOER, EVAN. Yui 3 Cookbook. Editorial O‟Reilly Media, Inc. Edición 2012

OSMANI, ADDY. Developing Backbone.Js Applications. Editorial ISBN edición 2012

GRONER, LOIANE. Ext Js 4 First Look. Editorial Packt Publishing Copyright © 2011

PALACIO, JUAN. Flexibilidad con Scrum Principios de Diseño e Implantación de Campos de Scrum. Editorial Safecreative Edición Octubre – 2008

PALACIO, JUAN Y RUATA, CLAUDIA. Scrum Manager: Proyectos – Formación. Editorial Safecreative Edición 1.3.2 Octubre – 2010

GARCIA, JESUS. Ext Js In Action. Editorial Manning Publications Edición 2011

RAMON, JORGE Ext.Js.3.0.Cookbook. Editorial Packt Publishing Edición Octubre 2009

MACLEES, NATALIE. Jquery For Designers Beginner's Guide. Editorial Packt Publishing Copyright © 2012

SNIDER, MATT. Yahoo User Interface 2.X Cookbook. Editorial Packt Publishing Copyright © 2010

GILL RAWLD, RIECKE CRAIG & RUSSELL ALEX. Mastering Dojo Javascript And Ajax Tools For Great Web Experiences. Editorial ISBN Edición 2008

Scrum Manager Proyectos Apuntes De Formación. Editorial Safecreative 2009

DEEMER PETE, BENEFIELD GABRIELLE, LARMAN CRAIG & VODDE BAS. Información Básica De Scrum (The Scrum Primer). Versión 1.1 2009

KNIBERG, HENRIK. Scrum y XP Desde Las Trincheras Como Hacemos Scrum. Editorial C4Media Inc Edición © 2007

143

ORCHARD LESLIE MICHAEL, PEHLIVANIAN ARA, KOON SCOTT & JONES HARLEY. Professional Javascript Frameworks Prototype, Yui, Ext Js, Dojo And Mootools. Editorial Wiley Publishing, Inc. Edición 2009

BLANKENSHIP JERREL, BUSSA MATTHEW & MILLETT SCOTT. Pro Agile .Net Development With Scrum. Editorial Apress Edición 2010

P. CLARK, MARTIN. Data Networks, Ip And The Internet: Protocols, Design And Operation. Editorial John Wiley& Sons, Ltd., 2003

BERGSTEN, HANS. Java Server Pages™. Editorial O'Reilly Edición 2nd Edition, 2002

MORITZ, FLORIAN. Rich Internet Applications (Ria):A Convergence Of User Interface Paradigms Of Web And Desktop Exemplified. Edición 2008

BRINZAREA-IAMANDI BOGDAN, DARIE CRISTIAN & HENDRIX AUDRA. Ajax And Php Building Modern Web Applications. Editorial Packt Publishing 2nd Edition, 2009.

GASSNE, DAVID. Flash Builder 4 And Flex 4 Bible. Editorial Wiley Publishing, 2010.

FALKNER JAYSON & JONES KEVIN. Servlets And Java Server Pages™: The J2ee™ Technology Web Tier. Editorial Addison Wesley, 2003

GASSNER, DAVID. Flash Builder 4 And Flex 4 Bible. Editorial Wiley Publishing, 2010

HORN, SHANNON. Microsoft Silverlight 3: A Beginner‟s Guide. Editorial McGraw Hill, 2010

GAMMA ERICH, HELM RICHARD, JOHNSON RALPH & VLISSIDES JOHN. Patrones De Diseño (Elementos De Software Orientado A Objetos Reutilizables).

STEFANOV, STOYAN. Javascript Orientado A Objetos.

EGUÍLUZ PÉREZ, JAVIER. Introduccion A Javascrip.

BLANKENSHIP JERREL, BUSSA MATTHEW & MILLETT SCOTT. Pro Agile .Net Development With Scrum.

144

TESIS

ADRIÁN YAZYI, SERGIO. Una Experiencia Práctica de Scrum a Través del Aprendizaje Basado en Proyectos Mediado por Tic en un Equipo Distribuido. Salamanca (España). Universidad de Salamanca. Junio 2011

OCHOA TAPIA, GRETTY MAIBELY Y TEJADA AUCCACUSI, JORGE CARLOS. Estudio de las Tecnologías Ria y Data Push de Servicios Multimedia en Tiempo Real. Cusco (Perú). Universidad Nacional de San Antonio Abad del Cusco. Agosto 2010

PÁGINAS WEB

Wikipedia.org, Comparativa de navegadores web [en línea]. Fundación

Wikimedia Inc. [actualizado 23 Dic 2012; accesado 24 Dic 2012].

Disponible en:

http://es.wikipedia.org/wiki/Anexo:Comparativa_de_navegadores_web

DesarrolloWeb.com, Ranking Navegadores Octubre 2012 [en línea].

Miguel Angel Alvarez Director de DesarrolloWeb.com [actualizado 07

Nov 2012; accesado 14 Dic 2012]. Disponible en:

http://www.desarrolloweb.com/de_interes/ranking-navegadores-octubre-

2012-7634.html

Mate.asfusion.com, Ejemplo de Ciclo de Vida de Mate [en línea].

WPDesigner. [actualizado 08 Ene 2009; accesado 24 Nov 2012]

Disponible en: http://mate.asfusion.com/archives/category/examples

Swizframework.jira.com, Que es Swiz? [en línea]. Administrador Brian

Kotek [actualizado 22 May 2009; accesado 12 Set 2012] Disponible en:

http://swizframework.jira.com/wiki/display/SWIZ/Home

Webvigo.com, Backbone.js estructura MVC en cliente [en línea].

Administrador Jacobo Varela 2010, accesado 12 Set 2012] Disponible

en: http://www.webvigo.com/blog/backbone-js-estructura-mvc-en-cliente/

Sproutcore.com, Statecharts en SproutCore [en línea]. Escrito por

Joachim Haagen Skeie, [actualizado 12 Dic 2012; accesado 01 Dic

2012] Disponible en: http://blog.sproutcore.com/tag/statecharts/

Slideshare.net, ExtJS4 Arquitectura MVC Mapa Mental [en línea].

Trabajo hecho por Loiane Groner, [actualizado 17 Jul 2012; accesado

10 Oct 2012] Disponible en: http://www.slideshare.net/loianeg/extjs-4-

mvc-architecture-mind-map-13669488

http://es.wikipedia.org/wiki/Anexo:Comparativa_de_navegadores_web

http://www.desarrolloweb.com/de_interes/ranking-navegadores-octubre-2012-7634.html

http://www.desarrolloweb.com/de_interes/ranking-navegadores-octubre-2012-7634.html

http://mate.asfusion.com/archives/category/examples

http://swizframework.jira.com/wiki/display/SWIZ/Home

http://www.webvigo.com/blog/backbone-js-estructura-mvc-en-cliente/

http://blog.sproutcore.com/tag/statecharts/

http://www.slideshare.net/loianeg/extjs-4-mvc-architecture-mind-map-13669488

http://www.slideshare.net/loianeg/extjs-4-mvc-architecture-mind-map-13669488

145

Mclibre.org, Historia de la Web: los navegadores [en línea]. Esta página

forma parte del curso "Páginas web HTML / XHTML y hojas de estilo

CSS" Autor: Bartolomé Sintes Marco, [actualizado 27 Nov 2012;

accesado 10 Oct 2012] Disponible en:

http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadore

s.html

Wikipedia.org, Navegador web [en línea]. Fundación Wikimedia Inc.

[actualizado 17 dic 2012; accesado 10 Oct 2012] Disponible en:


Wikipedia.org, Navegador web [en línea]. Fundación Wikimedia Inc.

[actualizado 17 dic 2012; accesado 10 Oct 2012] Disponible en:


Wikipedia.org, Mozilla Firefox [en línea]. Fundación Wikimedia Inc.

[actualizado 29 Dic 2012; accesado 10 Oct 2012] Disponible en:

http://es.wikipedia.org/wiki/Mozilla_Firefox

Wikipedia.org, Java Servlet [en línea]. Fundación Wikimedia Inc.


http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers

Microsoft.com, Guía básica de ASP.NET [en línea]. Microsoft

Corporation [actualizado 29 Jun 2012; accesado 18 Set 2012]

Disponible en: http://support.microsoft.com/?scid=kb;es;305140

Microsoft.com, .NET Framework [en línea]. Microsoft Corporation

[actualizado 01 Ene 2012; accesado 10 Oct 2012] Disponible en:


Wikipedia.org, WYSIWYG [en línea]. Fundación Wikimedia Inc.


http://en.wikipedia.org/wiki/WYSIWYG

Wikipedia.org, PHP [en línea]. Fundación Wikimedia Inc. [actualizado 30

Dic 2012; accesado 10 Oct 2012] Disponible en:


Wikipedia.org, Applet Java [en línea]. Fundación Wikimedia Inc.

[actualizado 09 Nov 2012; accesado 10 Oct 2012] Disponible en:

http://es.wikipedia.org/wiki/Applet_Java

http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadores.html

http://www.mclibre.org/consultar/amaya/otros/otros_historia_navegadores.html



http://es.wikipedia.org/wiki/Mozilla_Firefox

http://en.wikipedia.org/wiki/Java_Servlet#Servlet_containers

http://support.microsoft.com/?scid=kb;es;305140


http://en.wikipedia.org/wiki/WYSIWYG


http://es.wikipedia.org/wiki/Applet_Java

146

Wikipedia.org, Applet [en línea]. Fundación Wikimedia Inc. [actualizado

24 Oct 2012; accesado 10 Oct 2012] Disponible en:

http://es.wikipedia.org/wiki/Applet

Wikipedia.org, Kit de Herramientas de Ventana Abstracta [en línea].

Fundación Wikimedia Inc. [actualizado 24 Dic 2012; accesado 10 Oct

2012] Disponible en:

http://es.wikipedia.org/wiki/Abstract_Window_Toolkit

Wikipedia.org, Swing [en línea]. Fundación Wikimedia Inc. [actualizado

12 Jul 2012; accesado 10 Oct 2012] Disponible en:

http://es.wikipedia.org/wiki/Swing_(biblioteca_gráfica)

Microsoft.com, Common Language Runtime (CLR) [en línea]. Microsoft

Corporation [actualizado 30 Ago 2012; accesado 10 Oct 2012]

Disponible en: http://msdn.microsoft.com/es-pe/library/8bs2ecf4.aspx

Ibm.com, Nuevos elementos en HTML 5 [en línea]. International

Business Machines [actualizado 07 Ago 2009; accesado 10 Oct 2012]

Disponible en: http://www.ibm.com/developerworks/library/x-

html5/?ca=dgr-lnxw01NewHTML

Wikipedia.org, HTML5 [en línea]. Fundación Wikimedia Inc. [actualizado

15 Dic 2012; accesado 10 Oct 2012] Disponible en:

http://es.wikipedia.org/wiki/HTML5

Wikipedia.org, Patrón de diseño [en línea]. Fundación Wikimedia Inc.

[actualizado 25 Oct 2012; accesado 10 Oct 2012] Disponible en:

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o

Wikipedia.org, Modelo Vista Controlador [en línea]. Fundación Wikimedia

Inc. [actualizado 24 Dic 2012; accesado 10 Oct 2012] Disponible en:


TheArtofTheLeftFoot.blogspot.com, El patrón Modelo-Vista-Presentador

(MVP) [en línea]. Blog de Oscar Arrivi [actualizado 03 Oct 2010;

accesado 05 Oct 2012] Disponible en:

http://theartoftheleftfoot.blogspot.com/search/label/MVP

Wikipedia.org, Dojo toolkit [en línea]. Fundación Wikimedia Inc.


http://es.wikipedia.org/wiki/Dojo_toolkit

http://es.wikipedia.org/wiki/Applet

http://es.wikipedia.org/wiki/Abstract_Window_Toolkit

http://es.wikipedia.org/wiki/Swing_(biblioteca_gráfica)

http://msdn.microsoft.com/es-pe/library/8bs2ecf4.aspx

http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-lnxw01NewHTML

http://www.ibm.com/developerworks/library/x-html5/?ca=dgr-lnxw01NewHTML

http://es.wikipedia.org/wiki/HTML5

http://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o


http://theartoftheleftfoot.blogspot.com/search/label/MVP

http://es.wikipedia.org/wiki/Dojo_toolkit

147

Wikipedia.org, Yahoo! UI Library [en línea]. Fundación Wikimedia Inc.


http://es.wikipedia.org/wiki/Yahoo!_UI_Library

Wikipedia.org, Estilo Vancouver [en línea]. Fundación Wikimedia Inc.


http://es.wikipedia.org/wiki/Estilo_Vancouver#Libros_y_otras_monograf.

C3.ADas

http://es.wikipedia.org/wiki/Yahoo!_UI_Library

http://es.wikipedia.org/wiki/Estilo_Vancouver#Libros_y_otras_monograf.C3.ADas

http://es.wikipedia.org/wiki/Estilo_Vancouver#Libros_y_otras_monograf.C3.ADas

TesisFinal 30-12-12

Documents

Transcript of TesisFinal 30-12-12