Tags » ‘ExtJS’

Finalmente, luego una larga espera (y un atraso de un par de meses) en el dia de la fecha, Ed Spencer (lead developer en Sencha) anunció en el blog oficial el lanzamiento oficial de la librería en cuestión.

Para los desconocidos, ExtJS es un framework de desarrollo JavaScript basado en componentes (widgets), pero mucho (MUCHO) más potente que el popular jQuery UI. Además contempla aspectos más complejos como ser el manejo de datos y lógica de handlers.
Podríamos considerar como parecido (salvando las distancias) a SproutCore.

Ext JS 4

Documentacion

Junto a esta nueva versión, Sencha se encargó de darle una gran lavada de rostro a la documentación existente, migrando del sistema super dinámico a uno ligeramente más estático pero que aprovecha el indexado de google. Además, hay 40 nuevos ejemplos de distintos tipos listos para ser víctimas del copy-paste.

Arquitectura, clases y mixins

Clases y Mixins

Clases y Mixins

En esta nueva versión, Sencha agregó la posibilidad de trabajar con los componentes de manera modular y asincronica de manera similar a la que utiliza YUI.

// Solicitamos los modulos que vamos a utilizar
Ext.Loader.setPath('Ext.ux', '../ux/');
Ext.require([
    'Ext.grid.*',
    'Ext.data.*',
    'Ext.util.*'
]);

Cabe destacar que aún se puede (y es recomendable) usar el archivo ext-all.js que incluye todos los componentes (a excepción de los plugins).

Además, el nuevo sistema de clases incorpora mixins (implementaciones parciales por así decirlo) permitiendo lograr objetos flexibles con múltiples comportamientos posibles (draggable, resizable, etc).

Estilos

Al generar una capa de desarrollo propia, ExtJS4 permite trabajar los estilos de manera mucho mas desacoplada, permitiendo lograr grandes resultados de manera más intuitiva. Para lograr esta flexibilidad, hace uso de SASS (Syntactically Awesome Stylesheets) y del framework de desarrollo visual Compass.

Para mayor información, está disponible el video “SenchaCon 2010: Theming Ext JS 4” .

Sandbox

Con todo el refactor que recibió, era de esperar que corrigieran ciertos tópicos importantes, como ser la encapsulación y la contaminación de los objetos globales. Dentro de los ejemplos disponibles, tenemos una implementación de ExtJS4 y ExtJS3 en simultaneo, corriendo sin ningun tipo de problemas.
Por otra parte, se removieron todas las extensiones realizadas sobre los objetos nativos, a fines de evitar colisiones con librerías externas (como sucedía con ExtJS3 y Prototype).

Datos

Como se mencionó en una entrada anterior, Sencha movió bastante el piso en este aspecto, llevando el desarrollo a un paradigma más claro que el anterior (data stores diseminados por la aplicación). ExtJS4 soporta definición de entidades, con sus atributos, métodos e inclusive proxies para integrarlos de manera ágil con tecnologías server side.

Grid

Siendo el widget más usado y modificado, era de esperar que modifiquen muchas cosas del mismo. En principio hay que hablar del beneficio que recibe de la optimización de render general, lo cual sumado a un markup más liviano permite generar grids sin la sensación de “pesadez” que se nota con la versión 3 del framework. El render inteligente permite mantener el markup más básico para la configuración recibida, de manera que si no se va a usar una característica x, su markup no va a estar presente.
Con todos estos cambios, seguramente veamos muchas variantes y plugins en un futuro cercano.

Charts

Dentro de este rubro, Sencha se encargó de conseguir gente especializada como Nicolas Garcia Belmonte (autor del JavaScript InfoVis Toolkit)  y Dmitry Baranovskiy (autor de Raphael JS). El resultado es impresionante, logrando competir con gráficos generados con plugins (Flash, Java, Silverlight) de manera nativa y con amplio soporte (desde IE6 a iOS).


Descargar ExtJS4


Leer más:

En esta nueva versión (beta por el momento) de este framework, se dieron numerosos cambios en los temas de layouts y datos. Pero afortunadamente, la metodología de trabajo utilizada en versiones anteriores sigue siendo válida.

Resultado final

En su versión más básica, podemos concebir el formulario como una simple agrupación de campos bajo un componente padre que brinda ciertas caracteristicas adicionales. A fines de simplificar el ejemplo, al formulario en cuestión lo vamos a renderizar directamente sobre un elemento DOM existente en el html.En primer lugar vamos a definir los campos en un array. La definición individual de campos se puede realizar mediante instancias de los componentes a utilizar (textfield por ejemplo), o una definición plana (object) que representan un componente lazy (mediante la cual se genera la instancia una vez que sea requerida, ahorrando la memoria hasta entonces).

// Definimos una lista de campos
var campos = [
	// Esta es una definicion lazy, en la cual tipificamos el
	// campo mediante el atributo xtype
	{
		// Tipo de campo
		xtype: 'textfield',
		// Label del campo
		fieldLabel: 'Nombre',
		// nombre que se utilizara en el post del save
		name: 'nombre',
		// campo requerido
		allowBlank:false
	},
	// Esta es una definicion mediante instancia formal del
	// componente, en la cual podemos obviar el xtype
	new Ext.form.TextField({
		fieldLabel: 'Ocupacion',
		name: 'ocupacion'
	}),
	{
		xtype: 'textfield',
		fieldLabel: 'Email',
		name: 'email',
		// Indica el tipo de validacion que recibira
		vtype:'email',
		allowBlank:false
	}
];

Como se puede observar, la definición de campos se puede hacer de forma explícita (instancias de un componentes) o implícitas (definición del componente). Idealmente, se deberían utilizar las definiciones lazy siempre que se pueda, ya que implican un menor consumo de recursos hasta su utilización.

Posteriormente realizamos la instanciación del formulario:

// Instanciamos el formulario
var formBasico = new Ext.form.FormPanel({
	url:'response.json',
	border: false,
	width: 350,

	// Atributos por defecto para los campos,
	// en caso de que se definan dentro del campo
	// generan un override de estos defaults
	fieldDefaults: {
		msgTarget: 'side',
		labelWidth: 75,
		anchor: '100%'
	},		

	// asignamos los campos que creamos al formulario
	items: campos,

	// Creamos los botones
	buttons: [
		{
			text: 'Guardar',
			handler: function() {
				var form = this.up('form').getForm();

				form.submit({
					success: function(form, action) {
						// logica puntual
					},
					failure: function(form, action) {
						// logica puntual
					}
				});
			}
		},
		{
			text: 'Saludar',
			handler: function() {
				var nombre = this.up('form').getForm()
							.getFields().get(0).getValue();
				alert('Hola ' + nombre);
			}
		}
	],
	// elemento en el cual va a renderizarse
	renderTo: 'placeholder'
});

Con esto, tenemos el formulario renderizado, con los campos definidos con las validaciones correspondientes a su xtype y vtype. Este ejemplo completo puede descargarse de este link.

Leer más:


Shortlink: http://goo.gl/WQ4WA

Desde su blog personal, Ed Spencer (Software Architect at Sencha Inc) comparte el video del a presentación de ExtJS en la reciente SenchaCon 2010. En el video se habla de los objetivos que tuvieron a la hora de desarrollar, velocidad, flexibilidad y un api amigable.

Entre otras cosas se destaca la política de calidad, haciendo hincapié en los (numerosos) tests unitarios que realizan en cada build para asegurar la calidad y estabilidad del framework, QA visual, mejores defaults, etc.

Definitivamente, Sencha toma un gran riesgo en el golpe de timón que implica realizar todos estos cambios. Pero considerando la calidad del producto que proponen, es un costo sumamente accesible.

Actualización

Para los interesados, Sencha puso a disposición pública los videos y presentaciones de la SenchaCon, siendo ExtJS4 el principal tema de charla.

SenchaSencha no duerme, a la espera de la beta de ExtJS4 siguen exponiendo funcionalidad parcial del mismo a través de su blog oficial. Esta vez, Ed Spencer nos revela los cambios en el manejo de datos, con grandes novedades en cuanto al mappeado de entidades en el cliente.

Para empezar, luego de todo el refactor general que recibió, el data package se compone de 43 clases (sí, cuarenta y tres).
En principio se supone (según posteos en el foro oficial) que la lógica de los data stores no debería diferir en demasía con lo que ofrece Sencha Touch en la misma área.

Dentro de estas (por ahora) 43 clases, se destacan tres, Model, Store y Proxy. Como puede observarse en el gráfico siguiente, estas tres clases estan auxiliadas por clases específicas cuyo rol está acotado a un único propósito.

ExtJS Data Package

De los cambios, es sin duda el de mayor interés la introducción de la clase Model en el manejo de datos, donde ahora se va a poder manejar las entidades como tales sin necesidad de desparramar su definición (campos, url, validaciones, etc).

/*
 * Registarmos el modelo User
 */
Ext.regModel('User', {
    fields: ['id', 'name', 'age'],
    proxy: {
        type: 'rest',
        url : '/users',
        reader: {
            type: 'json',
            root: 'users'
        }
    }
});

/*
 * Creamos un store directamente
 * contra el modelo
 * Notese que se puede referenciar
 * el modelo registrado por su nombre
 */
new Ext.data.Store({
    model: 'User'
});

Otra ventaja que presenta el uso de modelos, es que permite manejar los registros de una manera más atómica e independiente, donde cada registro conoce como debe almacenarse, lo cual simplica MUCHO la inserción de registros desde el cliente.
La lógica y datos requeridos corren a cuenta del proxy asociado, abstrayendo al modelo de dicha responsabilidad. Aparentemente, además de los datasources tradicionales (en memoria y remoto o Ajax) se le suma el local storage definido en la especificación de HTML5.

// Se obtiene una referencia al modelo
var User = Ext.getModel('User');

// Se instancia un registro..
var ed = new User({
    name: 'Ed Spencer',
    age : 25
});

// Y se persiste...
ed.save({
    success: function(ed) {
        console.log("Saved Ed! His ID is "+ ed.getId());
    }
});

// De igual manera puede obtenerse un registro por id
User.load(123, {
    success: function(user) {
        console.log("Loaded user 123: " + user.get('name'));
    }
});

Otro punto fundamental en la implementación de la clase Model, es la capacidad de relacionar los modelos entre sí, permitendo manejar las coleccionas al mejor estilo MongoDB / CouchDB.
Estas relaciones, permiten manejar los request de datos recursivamente según lo definido en los modelos que contenga.

// Registramos un modelo
Ext.regModel('User', {
    fields: ['id', 'name'],
    hasMany: 'Posts'
});

Ext.regModel('Post', {
    fields: ['id', 'user_id', 'title', 'body'],
    belongsTo: 'User',
    hasMany: 'Comments'
});

Ext.regModel('Comment', {
    fields: ['id', 'post_id', 'name', 'message'],
    belongsTo: 'Post'
});

// Cargamos el usuario e iteramos las colecciones
User.load(123, {
    success: function(user) {
        console.log("User: " + user.get('name'));

        user.posts().each(function(post) {
            console.log("Comments for post: " + post.get('title'));

            post.comments().each(function(comment) {
                console.log(comment.get('message'));
            });
        });
    }
});

Sin duda alguna, el Data Package promete mucho, será cuestión de tiempo ver si la implementación de widgets (Grids y Forms) logra exprimir todo el potencial que presenta.

Leer más:

SenchaSegún una entrada en el blog oficial de Sencha, ExtJS4 está a la vuelta de la esquina con grandes novedades, siendo la que se anuncia en dicha entrada el nuevo sistema de clases.

Historicamente, ExtJS utilizó un esquema de clases basado en herencia simple (un objeto tiene un único padre) que se ajusta más a lenguajes oop típicos (Java y C# por nombrar algunos) que a JavaScript, donde la flexibilidad del lenguaje permite implementar soluciones mucho más potentes y sencillas.

Con ExtJS4 parece haber un gran giro de timón al respecto, en el que complementan la herencia simple con un sistema de mixins en el que las “clases” bases toman características de múltiples fuentes.

/*
 * Se define una composición de objetos, heredando directamente de
 * Sample.Person e implementando distintos mixins
 */
Ext.define('Sample.Musician', {
    extend: 'Sample.Person',

    mixins: {
        guitar: 'Sample.ability.CanPlayGuitar',
        compose: 'Sample.ability.CanComposeSongs',
        sing: 'Sample.ability.CanSing'
    }
});

Este tipo de implementaciones permiten al desarrollador generar sus propios componentes con la libertad de definirlo de acuerdo a sus necesidades y no a la aproximación de un objeto (como suele darse con la herencia simple).

Mixins en accion

Mixins en accion

Aprovechando esta nueva característica, se incluye un sistema de dependencias que cubre un gran vacío existente actualmente en ExtJS: la modularidad.
Hoy por hoy, ExtJS se sirve en un gran archivo concatenado al cual se le suman unas pocas dependencias externas que suelen ser plugins o archivos muy específicos (caso de los archivos locale). Con el nuevo sistema, se realizará la carga bajo demanda para los modulos requeridos (incluso recursivamente para los que requiera el modulo en cuestión).

// requerimos el archivo
Ext.require('Ext.Window', function() {
    // y asincronicamente realizamos la tarea
    new Ext.Window({
        title : 'Loaded Dynamically!',
        width : 200,
        height: 100
    }).show();
});

A estos cambios se le suma la no menos importante reducción significativa del markup de los widgets (que hoy por hoy puede alcanzar niveles de anidamiento alarmantes) lo cual impactará directamente en el rendimiento, permitiendo tener grillas de alta performance, uno de los puntos más flacos de ExtJS en relación a otras librerías (SlickGrid por ejemplo).

Leer más:

  • Buscar

  • Ultimos Twits

  • Por fecha

    • 2012 (11)
    • 2011 (63)
    • 2010 (13)
  • Tags

  • Documentacion Javascript

    JavaScript Reference, JavaScript Guide, JavaScript API, JS API, JS Guide, JS Reference, Learn JS, JS Documentation