ExtJS – El sistema de clases

Empecemos aclarando que Javascript no posee el concepto de clase; la herencia se hace por prototipos, y una vez eso claro, veamos como lo aborda ExtJS, y seguiremos hablando de clases.

Por primera vez en su historia, Ext JS atravesó un enorme refactorización desde la base  para arriba con el nuevo sistema de clases. La nueva arquitectura está montada sobre clases escritas para  Ext JS 4.x, Es por eso que es importante conocerlas bien antes de empezar con la codificación..

Hemos escrito este manual para que  cualquier desarrollador que quiera crear nuevas clases  o ampliar las existentes en Ext JS 4.x. comprenda su funcionamiento y las extienda sin problemas. Lo hemos dividido en 4 secciones:

• «Resumen«, explica la necesidad de un sistema de clase robusta
• «Convenciones de nombres» analiza las mejores prácticas para nombrar las clases, métodos, propiedades, variables y archivos.
• «Trabajando» proporciona ejemplos de código paso a paso
•  «Errores de manipulación & depuración» da consejos útiles y trucos sobre cómo tratar con los errores

Resumen

Ext JS 4 cuenta  con más de 300 clases. Existe una enorme comunidad de desarrolladores, más de 200.000 hasta la fecha, procedentes de todo el mundo. En ese marco, es un gran desafío  proporcionar una arquitectura de código común que sea:

• familiar y sencillo de aprender
• sencilla de desarrollar, fácil de depurar, limpia para desplegar
• bien organizado, extensible y mantenible

JavaScript es un lenguaje sin clases, orientado al prototipo. Por lo tanto, su mejor característica es la flexibilidad. El mismo trabajo se puede hacer de muchas maneras distintas, en diferentes estilos de codificación y técnicas. Esa característica, sin embargo, viene con el costo de la imprevisibilidad. Sin una estructura unificada, el código JavaScript puede ser muy difícil de entender, mantener y reutilizar.

Por otro lado, la programación basada en clases, aún permanece como el modelo más popular de la OOP. Los lenguajes basados en clases generalmente implementan un tipado fuerte , proporcionan encapsulación y vienen con estándar de codificación, haciendo que, generalmente, los desarrolladores se adhieren a un amplio conjunto de principios, Así, el código escrito es más probable que sea previsible, extensible y escalable en el tiempo. Sin embargo, pierden la capacidad dinámica de  JavaScript.

Cada método tiene sus propios pros y contras, pero ¿podemos tener las partes buenas de ambos al mismo tiempo, mientras que oculta las partes malas? La respuesta es sí y podemos verlo en la forma en que se implementó la solución en Ext JS 4.

Convenciones de nombres

En nuestro código, debemos usar convenciones para nombrar los “namespaces”, las clases, las propiedades y los métodos. Todo ello hará que nuestro código sea mas legible y organizado

Clases

Los nombres de las clases solo pueden contener caracteres alfanuméricos. Es mejor no utilizar números, a menos que se deba hacer por terminología. No se deben usar guion bajo, comas, comillas ni ningún otro carácter  alfanumérico. Por ejemplo:

Application

En el máximo nivel , en los NameSpaces”   los nombres de clase deben utilizar la convención “CamelCased”; todos los demás, deben escribirse con minúsculas

Las clases no desarrolladas por Sencha no deberían utilizar nunca “Ext” como  “namespace” de primer nivel.

Los acrónimos también deben seguir las convenciones “CamelCased”. Por ejemplo:

• data.JsonProxy en lugar de Ext.data.JSONProxy
• util.HtmlParser en lugar de MyCompary.parser.HTMLParser
• server.Http en lugar de MyCompany.server.HTTP

Ficheros fuentes

Los nombres de las clases han de equivaler a rutas concretas a los ficheros que las contienen; eso hace que en cada fichero solo pueda haber una clase. Por ejemplo:

• util.Observableis almacenado en  path/to/src/Ext/util/Observable.js
• form.action.Submitis almacenado en path/to/src/Ext/form/action/Submit.js
• chart.axis.Numeric almacenado en  path/to/src/MyCompany/chart/axis/Numeric.js

path/to/src es la ruta al directorio de clases de su aplicación. Todas las clases deben estar bajo una misma raíz, clasificadas por “namespaces” para permitir un mejor desarrollo y un mantenimiento mas simple

Métodos y variables

Igual que en el caso de los nombres de clase, los nombres de métodos y variables solo deben contener caracteres alfanuméricos. Los número están permitidos aunque desaconsejados. No utilice ningún carácter no alfanumérico

Los nombres de los métodos y variables han de seguir la convención “CamelCased”, incluidos los acrónimos.

Ejemplos:

• Nombres de métodos correctos
  • encodeUsingMd5()
  • getHtml() en lugar de  getHTML()
  • getJsonResponse() en lugar de getJSONResponse()
  • parseXmlContent() en lugar de parseXMLContent()
• Nombres de variables correctos:
  • var isGoodName
  • var base64Encoder
  • var xmlReader
  • var httpServer

Propiedades

Los nombres a asignar a las propiedades de una clase han de seguir las mismas convenciones explicadas anteriormente a menos que sean Estáticos

Las propiedades estáticas de una clase (Static) se nombraran únicamente con mayúsculas. Por ejemplo:

• MessageBox.YES= «Yes»
• MessageBox.NO= «No»
• alien.Math.PI = «4.13»

Declaraciones

A partir de la versión de ExtJS 4, para definir una clase solo se requiere un método:

Ext.define(className, members, onClassCreated);

En donde:

• Classname: Nombre de la clase
• Members es un objeto que representa la colección de miembros de la clase como parejas de clave-valor
• onClassCreated es una función opcional que se puede añadir y será llamada cuando la clase y todas sus dependencias estén listas para su uso. Debido a la carga asíncrona que se realiza, este hecho, se ha de tener presente.

Ejemplo:

y cuando se quisiera utilizar la clase, se hará:

Queremos destacar en este punto la utilización de “Ext.create” en lugar del operador “new”. Hacemos esto por las posibilidades que tiene “Ext.create” de realizar la carga dinámica de las clases.

Configuración

También aparece una nueva propiedad “config” que se procesa antes de crear la clase

Dentro de las nuevas posibilidades, se generan métodos getters y setters para todas las propiedades que se hayan definido dentro de «config». y no se encuentre el código correspondiente, para dejar la clase totalmente encapsulada.

El método setter autogenerado, llama al método “aplicar” si esta definido, antes de establecer el valor.

Todas las clases que extiendan de Ext ya no necesitan llamar a “initConfig()”, aunque si que lo deberán  hacer si extienden desde Ext.Base

Todo esto lo puede ver en el siguiente ejemplo:

Lo utilizaríamos así:

Propiedades estáticas

Los miembros estáticos se deberán definir usando “configs” estáticos:

Depuración y gestión de errores

El Framework ExtJS dispone de algunas características muy útiles para la gestión de errores.

Aparte de utilizar los ficheros de scripts con la partícula “debug”, podemos incorporar a la salida de errores el método Ext.getDisplayName(), lo que nos facilitará información acerca de la clase que ha dado el error y la línea en la que ha ocurrido

Cuando se lanza un error en cualquier método de cualquier clase definida utilizando “Ext.define()” podremos ver la lista de clases y líneas por la que ha pasado (call stack), siempre que este utilizando un navegador basado en Webkit (Safari y Chrome)

Y hasta aquí este tema; aunque muchos conceptos pueden considerarse generales para cualquier lenguaje, tened en cuenta que la explicación se ha preparado para ExtJS, por lo que contiene comportamientos específicos de ese framework.

El próximo articulo, presentaremos el concepto de arquitectura MVC,y como la trata ExtJS.