Desarrollosweb.net » desarrollo web

Internet Explorer 8 – Suscripción a Contenidos con Web Slices

Javier Caride — Mon, 09 Mar 2009 13:31:45 +0000

Hasta ahora, cuando una persona se quería subscribir al contenido de una página tenía como opción principal la sindicación a un feed RSS. Este tipo de subscripción requiere que ciertos contenidos (a los que el usuario se quiere subscribir) se tengan que duplicar en un fichero especial definido en XML.

Los Web Slices, (introducidos por Microsoft en su nuevo navegador Internet Explorer 8.0) son, sin embargo, “trozos” de una web a los que un usuario se puede subscribir directamente sin necesidad de especificar un fichero especial.
Los puntos clave de los Web Slices:

Se desarrollan en HTML, de hecho forman parte del contenido de nuestra web. Para indicar al navegador qué partes de nuestra web son Web Slices, tenemos que hacer uso de ciertas clases CSS.
El propio Web Slice puede indicar al navegador cada cuanto se actualiza, aunque el tiempo mínimo que se puede indicar es de 15 minutos.

Mini-tutorial de desarrollo.

Introducción.

Los Web Slices están basados en el formato hAtom [http://microformats.org], al que se le han añadido ciertas propiedades. Está desarrollado completamente en HTML, por lo que el contenido al que un usuario se puede subscribir, como se dijo anteriormente, forma parte del contenido de nuestra página.

Esto permite, por ejemplo, que podamos permitir que un usuario se subscriba directamente a un listado de noticias de nuestro portal únicamente haciendo click en cierto área (que definimos nosotros previamente).
Básicamente lo que hace Internet Explorer 8.0 para descubrir los Web Slices de una web es recorrer todo el código HTML buscando aquellos elementos que pertenecen a la clase CSS hslice, están identificados una propiedad id única y tienen por lo menos un elemento cuya clase CSS es entry-title.

Descubrimiento y subscripción de slices.

Cuando un usuario pasa el puntero del ratón por encima de estos elementos, se remarcan con un recuadro, a la vez que se muestra un icono específico que se ha diseñado para este formato de subscripción.

Además el navegador, mostrará todos los Web Slices detectados para la página actual desplegando un menú que se encuentra en la barra de tareas del navegador.

Si el usuario se subscribe a uno de estos contenidos, se añadirá a la barra superior.

Además, si el Web Slice tiene un elemento marcado como entry-content, este se mostrará cuando el usuario haga click en la barra superior sobre el título del contenido subscrito. Además no hace falta que el usuario esté visitando la web del contenido, como se puede ver a continuación.

Hay que puntualizar una cosa, el título mostrado en la barra superior será la concatenación de todos los elementos entry-title que tenga el Web Slice, es decir, podemos formar el título de la subscripción con diferentes trozos del contenido.

El código de un Web Slice básico es muy sencillo, como se puede ver.


Hello world web slice!

This is my first web slice, remember my first web slice don't ask me too much questions 

This slice will be updated every thirty minutes.


This is the content that IE8 will show in the taskbar

Actualización de contenido.

Los usuarios que estén subscritos a un Web Slice serán avisados de las actualizaciones de los contenidos. Para ello el navegador visitará periódicamente la página web donde se encuentra el contenido. Por esta razón es muy importante que los web-slices mantengan siempre el mismo id.

Si la web no ha indicado un intervalo de actualización por defecto toma el de 24 horas. Para indicar un tiempo distinto de actualización se utiliza un elemento HTML cuya clase CSS es ttl (time to live) y cuyo contenido es numérico.

This slice will be updated every 60.

Aunque también tenemos otra opción que es indicar el tiempo en el campo title de un elemento abbr.

This slice will be updated every thirty minutes.

Otra forma de indicar cuando un contenido ha caducado es utilizando un elemento de la clase CSS endtime con un valor title indicando un timestamp en el formato:

YYYY-MM-DDThh:mm:ss[Z|(+|-)hh:mm]

Caducará a las 20:00 del día 7 de marzo de 2009

Debido a que por defecto el navegador vuelve a visitar la página que contiene el Slice y la pide entera, esto puede sobrecargar nuestros sites. Para evitar esta situación se puede indicar una URL alternativa que sólo devuelva el trozo de HTML del Web Slice.

Para ello se utiliza un elemento enlace que tenga las siguientes propiedades:

De esta forma, el navegador en vez de descargarse todo el contenido de nuestra web sólo pedirá el trozo HTML necesario al feeder.

Visualización.

Como se dijo anteriormente, todo aquellos elementos que pertenezcan a la clase entry-content, se mostrarán concatenados cuando el usuario pulse sobre el título del contenido subscrito en la barra superior de IE8.

Lo que hace el navegador es mostrar el contenido del elemento de la clase hslice dentro de una etiqueta BODY. Además de poder indicar cuál es la URL de actualización de un contenido, podemos indicar también qué URL nos devuelve el contenido de visualización.

De esta forma cuando el usuario pinche sobre el contenido subscrito se mostrará el contenido indicada por este elemento, en lugar del original de la página.

Es posible mezclar la URL alternativa para actualización de contenido y la URL alternativa de visualización. Para que esto funcione en el Web Slice principal se debe indicar únicamente la URL de actualización:

Y el feed que devuelve la actualización (en este caso slidefeed.php) debe devolver la información necesaria para mostrar la información.


Hello world web slice!


This is the content that IE8 will show in the taskbar

Navegación.

Cuando el usuario pre-visualiza el contenido del Slice, tiene la posibilidad de ir a la web original de donde. Para ello IE8 provee un botón:

Es posible indicar que se vaya a una página distinta de la original, para ello hay que utilizar un elemento como el que mostramos a continuación:

Referencias.

Ext JS – Primera conferencia Anual y presentación de Ext JS 3.0

Javier Caride — Fri, 06 Mar 2009 09:28:04 +0000

Jack Slocum y su equipo anuncian la celebración de la primera conferencia de Ext JS que se celebrará del 14 al 16 de Abril en Orlando, Florida, concretamente en el hotel Ritz-Carlton Grande Lakes.

La conferencia pretende ser un punto de encuentro entre todos los usuarios de Ext JS, aunque también se aprovechará para hablar de las novedades que el equipo de Ext JS nos tiene preparadas: Ext JS 3.0, Ext GWT 2.0 y Ext Core 1.0.

El precio de la subscripción es de 250$ y si decides hacer noche en el hotel los organizadores han conseguido pactar un precio de 149$ la noche.

La conferencia se ha dividido en 24 sesiones en las que se tratarán diversos temas: novedades en los frameworks, optimización de rendimiento, buenas prácticas en el código, etc. pasando incluso por una sesión dedicada a javascript básico y temas Web 2.0 en general.

Parece ser que Ext JS 3.0 viene cargado de novedades y no sólo estamos hablando de nuevos widgets, sino funcionalidades pensadas a mejorar la estructuración del código y facilitar la integración con servicios de datos.

Os mantendremos informados. De momento podéis consultar más información en los siguientes enlaces:

Aptana Cloud, una nueva forma de hosting

Javier Caride — Thu, 05 Mar 2009 17:43:09 +0000

Como podemos ver en la web de Aptana, a través de la última versión de su IDE podemos acceder a una nueva forma de entender el hosting de aplicaciones web basada en Cloud Computing. Lo realmente nuevo de la solución aportada por Aptana, es que todos los parámetros y configuración de la instancia se pueden manejar desde el propio IDE, así como la subida a producción, la sincronización de ficheros y el repositorio de desarrollo.

Lo interesante de la solución propuesta por Aptana (como ya comenté al hablar de Cloud Computing) es que el precio es realmente bajo y asequible. Para aplicaciones que consuman pocos recursos o como máquina de desarrollo podemos utilizar una instancia en la “nube” de Aptana desde 0,04$ (menos de 1 euro diario).

Como una imagen (en este caso un video) vale más que 1000 palabras, aquí podéis ver dos videos (en inglés) que muestran de una forma muy rápida cómo publicar aplicaciones web con muy pocos clicks.

Introducción a Aptana Cloud

Desarrollo con PHP, Aptana Studio y Aptana Cloud

Más información en:

Factores relevantes de SEO (Search Engine Optimization) en una página Web, o como hacer páginas “Google friendly”

Javier Caride — Wed, 04 Mar 2009 13:12:31 +0000

Son muchos y muy extensos los factores que influyen en el indexado correcto de una página web, uno de ellos (y muy importante es el tiempo). Con esto queremos decir que es muy difícil que Google (o cualquier otro buscador) le dé importancia a tu web si hace apenas unos meses que ha echado a andar.

Además, cuanto más tiempo haya pasado más contenidos habrás generado, lo cual es otro punto muy importante a tener en cuenta: más contenidos, más posibilidades de que te indexen. El paso del tiempo también influirá en cuanta gente habrá visitado tu página, y con ello el número de enlaces que estarán apuntando a ella. Pero en este documento vamos a ir más allá del factor tiempo, que por sí solo no va a hacer que tu página sea mejor indexada o más visitada.

1. Cuida la cantidad de texto en una página.

Una página que tenga poco texto a los ojos de un buscador será un mero listado. Es por ello que hay que prestar atención a la cantidad de información que se publica. Los buscadores le dan más peso a las páginas que tienen una gran cantidad de contenido informativo. El número de palabras de cada página en tu web deberá rondar entre 500 y 3000.

2. El número de palabras clave (keywords) también importa.

¿Cuándo estás buscando cierto contenido en un libro por donde sueles empezar a buscar? Normalmente buscas en el índice en qué página se cita cierta palabra que para ti es clave. Pues en internet pasa exactamente lo mismo. En cada página, artículo, etc. Hay que seleccionar cuidadosamente las palabras que identifican la temática de tu texto. Una vez identificadas hay que intentar repetirlas y usarlas el mayor número de veces… eso sí, siempre intentando que el sentido del texto se pierda.

Obviamente la longitud del texto influye en cuantas veces podemos usarlas (esto se llama densidad), aunque se recomienda que por lo menos se usen tres o cuatro veces dentro del texto.

Los buscadores suelen penalizar que se construyan frases sólo con palabras clave y le dan más importancia a encontrarlas sueltas por todo el texto. Pero como siempre existe una excepción a esta regla: la repetición de frases construidas por palabras clave en el mismo orden a lo largo del texto, potenciando su significado utilizando las palabras clave por separado en otras áreas del texto.

Por ejemplo, si hemos hecho un artículo que habla de ” crear grids con el framework ExtJS” y hemos decidido que las palabras clave son “extjs”, “grids” y “framework”, podemos usar la frase “Los grids mediante extjs framework” y repetirla varias veces en nuestro texto (siempre con cabeza y moderación), a la vez que se van “nombrando” las palabras claves de forma suelta por el texto.

3. La densidad de palabras clave y su localización

La densidad de palabras clave mide la frecuencia de aparición de éstas respecto al total de palabras del texto, expresándose normalmente en porcentaje. Es una herramienta que se puede usar para identificar palabras clave “a posteriori”, es decir una vez hayamos terminado de escribir nuestro texto.

Es importante, como siempre, encontrar un equilibrio en el uso de las palabras clave: si la densidad es baja, el robot del buscador no le dará importancia, mientras que si la densidad es demasiado alta, los sistemas “anti-engaños” de los buscadores pueden saltar y penalizar nuestra página.

Se suele decir que la densidad óptima de una palabra clave debe estar entre el 5% y el 7%. Además de esto, cuanto más cerca del comienzo del documento esté una palabra clave o una frase de palabras clave, más significado o peso tendrá esta para el motor de búsqueda. Y ya no digamos si resaltamos esas palabras (por ejemplo con una negrita o una cursiva). Eso sí, no conviene resaltarlas cada vez que aparezcan, pues puede ser contraproducente. La lógica indica que se resalten la primera vez que se nombran, o bien cuando existan muchos párrafos por el medio sin la palabra resaltada.

Otro factor importante, es utilizar palabras clave en el texto de los enlaces que hagan referencia a otras páginas o secciones de nuestro site, pues potencian la importancia de la página globalmente. Ya por finalizar con el tema de las palabras clave, aunque parece que últimamente los buscadores no prestan atención a la etiqueta META ‘keywords’, sí que conviene introducir en ella el valor de las palabras clave.

4. Formatear el texto también ayuda

Los motores de búsqueda, aunque parezca que sólo buscan palabras, prestan especial atención al texto cuando está remarcado. Aunque en sistemas como wordrpess los editores de noticias, no llegan a tocar el código HTML, los diseñadores de las plantillas sí que tienen en cuenta estas recomendaciones:

Uso de las palabras clave en las cabeceras. Las cabeceras son texto remarcado con el tag de HTML “H”. Los tags “h1” y “h2” son los más efectivos, modificando su apariencia mediante los CSS.
Remarcar palabras clave con “negrita” (tag “strong” de HTML mejor que tag “b”). Se remarcará la palabra clave o la frase clave específicamente.

5. La etiqueta de título </strong></p> <p>Sin lugar a duda el tag <TITLE> es de los más importantes para los buscadores, siendo prácticamente fundamental su uso para optimizar una página. Esta etiqueta, por lo tanto, vale para algo más que para mostrar el nombre de nuestra web en la ventana del navegador.

Como se dijo antes (al hablar de las palabras clave), el título debe contener el mayor número de palabras clave porque además es utilizado habitualmente como parte del texto que presentan los buscadores al mostrar los resultados.
Además de incluir el mayor número de palabras clave, debe ser atractivo para el usuario y hacer que se sientan atraídos por visitar nuestra web. Aunque no es una regla escrita, se recomienda que la longitud esté entre los 60 caracteres y los 85 (se dice que el valor óptimo son 65 caracteres para Google), aunque tampoco debemos obsesionarnos con ello.

6. No dejes “desnudas” a las imágenes

Toda imagen en HTML tiene un atributo opcional “ALT” o “alternative text” al que se le puede asociar un texto. Por ejemplo en Wordpres, cuando asociamos una imagen, se nos da la posibilidad de introducirlo.

Este tag es importante porque en caso de que la imagen no se cargue por alguna razón, el navegador mostrará ese texto en su lugar. Además los motores de búsqueda como Google, indexan las imágenes por este valor.

7. Describe lo que estás publicando…

Existe un campo META (de METATags o METAetiquetas) que es utilizado para describir el contenido de una página. Aunque su influencia en temas de SEO no es directa, sí que importa. La mayoría de motores de búsqueda muestran la información de este campo en los resultados de búsqueda si la etiqueta existe y contiene información relativa al texto de la página y de las palabras de búsqueda.

En wordrpess (si está instalado el plugin “All in one SEO Pack” se puede editar este campo independientemente para cada post (al igual que el título y las palabras clave).

La estructura del site no sólo es útil para nuestros ojos

Aunque pueda parecer que la estructura del site sólo sea de importancia para el diseño o la facilidad de navegación, lo cierto es que los buscadores han avanzado tanto que son sensibles incluso a cómo esté distribuida la información en una página.

1. Número de páginas

Cuantas más páginas con contenido interesante existan en una web más visibles serán a los “ojos” de un buscador. Esto, que aunque parezca una verdad de Perogrullo, es un tema que a veces se olvida. Además de la cantidad y la calidad, los buscadores tienen en cuenta que los contenidos se generen constantemente y se actualicen (por eso mismo los blogs bien actualizados están alcanzando puestos tan altos en los buscadores)

2 El menú no solo es para comer…

Todo sitio web debe tener un menú de navegación bien estructurado desde el que se enlace con todas las páginas importantes del site. Además es una buena práctica utilizar palabras clave en este menú para darle relevancia a la página.

3. Seo y la portada principal del Site

Es buena idea optimizar la página principal del Site para conseguir la mayor combinación de palabras clave relacionadas con el contenido del site, de esta forma la página será la mejor posicionada en los resultados que apunten a nuestra web.

En un blog (como wordpress) puede ser difícil ya siempre se están mostrando las entradas más recientes, y no sería muy útil tener una entrada fija diseñada para albergar las palabras clave. Para ello tenemos plugins como la “nube de etiquetas” que muestran en la página principal una lista con un resumen de todas las palabras clave con las que se han etiquetado los contenidos, o la lista de posts más destacados.

4. Intercambiar enlaces

Muchos buscadores miden la importancia de una página por la cantidad de enlaces que apuntan a ella. Esto lleva muchas veces a una mala utilización de esta característica de los buscadores y hay gente que se dedica a intentar colocar el link a su página en cientos o miles de webs sin importarle la temática o la posición, sin saber que Google (y Yahoo, y MSN) penalizan aquellos enlaces que son “dudosos” (ya sea por su calidad o características)

Así pues, es importante tener algo menos de enlaces, pero de calidad y páginas serias.

Hasta en SEO se pueden cometer errores

1. Imágenes con texto

Hasta ahora no hay buscadores que hagan la tarea de OCR (reconocimiento óptico de caracteres), de forma que todo aquel texto que pongamos dentro de una web, embebido dentro de una imagen, será invisible a “ojos” del buscador.
Debemos evitar a toda costa utilizar imágenes para los elementos del menú de la web, así como para nuestros artículos (si necesitamos copiar texto de otra web, es mejor copiar el texto que plantar una captura de pantall).

Asimismo se debe evitar crear enlaces cuyo elemento descriptivo se una imagen y no un texto. Todo link asociado a una imagen tendrá menor relevancia que aquel asociado a un texto y por lo tanto que pueda ser indexado.

2. Evita scripts en la navegación

Hay que evitar que la navegación por tu web funcione a través de scripts (por ejemplo menús activados por javascript, java o flash) pues dificultan la navegación a través de la web a los robots de los buscadores. Lo mejor es que los enlaces sean eso… enlaces con su etiqueta y su texto descriptivo.

3. Parámetros en URL

Aunque esto importa más a los programadores de la web que a los editores de información, hora de generar URLs (direcciones) a nuestros contenidos hay que evitar que se generen con parámetros extraños o confusos.
Por ejemplo la dirección:

http://www.desarrollosweb.net/gestorContenidos/seccion.php?IDSeccion=6&tag=tecnologia&fecha=20090321&tema=microcamaras

se indexa mucho peor que otra que sea

http://www.desarrollosweb.net/seccion/tecnologia/20090321/microcamaras

Si os fijáis, para el buscador la segunda url es mucho más descriptiva, pues a través de ella sabe que está en la sección tecnología, de la web www.desarrollosweb.net y que el 21 de marzo de 2009 se publicó un contenido sobre microcámaras.

4. Redirecciones

Otro tema que le toca a los programadores, pero que es importante que lo sepan todos, el tema de las redirecciones. Una redirección es el acto de redirigir una URL (dirección) a otra distinta.

Esto se suele hacer cuando se cambia la dirección de un contenido, se borra, etc. Es algo que hay que evitar a toda costa y si no hay más remedio que hacerlo, lo mejor es informar al buscador con un código “301” que le indica que la página se ha redirigido para siempre a una nueva dirección. De esta forma, la próxima vez que el buscador vuelva a nuestra página irá directamente a la URL nueva.

5. No ocultes nada… que se acaba viendo

Otro error que viene heredado del pasado. Hace unos años (cuando los buscadores estaban menos evolucionados) era muy fácil posicionar una web en primer lugar insertando en el código HTML de la página contenidos que no se mostraban en un navegador (la gente no podía leer esa información), pero sí que era visible a los motores de búsqueda.

Lo que se hacía normalmente era introducir cientos o miles de palabras clave no relevantes con el texto dentro de una etiqueta oculta, de forma que siempre aparecieses en los primeros resultados de las búsquedas.
Actualmente esta técnica está prohibida y si la usas te arriesgas a que Google o cualquier otro buscador banee tu página y no vuelva a visitarte (ni indexarte) nunca. Es más, llegarás a perder todo el rankin que has conseguido.

Un tema relacionado con este es la práctica de crear enlaces asociados a píxeles transparentes que son invisibles a los usuarios y cuya finalidad es buscar que los robots de los motores de búsqueda los indexen.

Cookbook ExtJS: Creando nuestros propios validadores

Javier Caride — Thu, 11 Dec 2008 12:39:39 +0000

Después de un puente largo, retomamos los artículos con trucos de ExtJS. En ExtJS tenemos la opción de crear nuestros propios validadores de datos para los campos de los formularios, lo que es útil si tenemos validaciones que se repiten a lo largo de nuestra aplicación.

Muchos estaréis pensando que eso también lo podemos hacer usando una función que llamemos dentro de un handler (lo cual es cierto), pero extendiendo los validadores de ExtJS conseguimos que nuestras reglas se integren automáticamente con los mecanismos de validación de formularios que trae “de serie” ExtJS

Vamos a crear una función de validación que chequee el valor de dos campos de forma que sólo uno de ellos tenga valor mayor que cero. Para ello lo primero que hacemos es añadir a la configuración de los campos del formulario una etiqueta propia ‘exclusionPair’ (que nos indicará el id del otro campo que excluye el valor del actual) e indicamos que queremos usar nuestro validador

{ fieldLabel : 'Haber', xtype: 'numberfield', id: 'frm_mov_haber', name : 'mov_haber', // el campo exclusionPair indica cual es el id del otro campo que excluye a este // es un parametro de configuracion que nos hemos inventado exclusionPair: 'frm_mov_deber', vtype: 'exclusionNotZero', // función de validación que queremos usar allowBlank:false, width : 175 },{ fieldLabel : 'Deber', xtype: 'numberfield', id: 'frm_mov_deber', name : 'mov_deber', // el campo exclusionPair indica cual es el id del otro campo que excluye a este // es un parametro de configuracion que nos hemos inventado exclusionPair: 'frm_mov_haber', vtype: 'exclusionNotZero', // función de validación que queremos usar allowBlank:false, width : 175 }

La forma de crear un validador es muy sencilla, lo único que hay que tener en cuenta es que tenemos que devolver un true cuando la validación sea correcta y un false si no ha pasado la validación

/** * Extendemos los validadores de ExtJS que están definidos en Ext.form.VTypes * **/ Ext.apply(Ext.form.VTypes, { /** * Definimos un nuevo validador: exclusionNotZero * * Valida un par de campos numéricos para que no puedan tener valor positivo los dos ni * valor cero los dos. * **/ exclusionNotZero: function(val, field) { /* * Si hay valor en el campo exclusionPair, es que tenemos que hacer la validación */ if (field.exclusionPair) { // Nos quedamos con la instancia del objeto indicado en exclusionPair var pair = Ext.getCmp(field.exclusionPair); // Nos quedamos con el valor del campo var pairValue = pair.getValue(); if ((pairValue > 0) && (val > 0)) { /** * Si los dos tienen un valor positivo, la regla de validación no se pasa * marcamos el campo como no válido y un mensaje */ field.markInvalid('Un movimiento no puede tener a la vez haber y deber'); return false; } else if ((pairValue == 0) && (val == 0)){ /** * Si los dos tienen un valor cero, la regla de validación no se pasa * marcamos el campo como no válido y un mensaje */ field.markInvalid('Un movimiento no puede tener haber y deber a cero'); return false; } else { /** * Si llegamos aquí es que la regla se ha pasado. Como anteriormente un campo * pudo haberse marcado como no válido, los desmarcamos por si acaso */ field.clearInvalid(); pair.clearInvalid(); return true; } } /** * El campo no tiene valor en exclusionPair, devolvemos true para que se valide el campo */ return true; } });

Cookbook ExtJS: Cargar un registro de un GridPanel en un FormPanel

Javier Caride — Wed, 03 Dec 2008 09:40:14 +0000

¿Como hacemos para cargar los datos de un registro de un grid en un formulario? Bien, hay diversas opciones (siempre a gusto del programador) así que aquí vamos a explicar una de ellas: asociar el evento ‘rowdblclick’ (doble click en una fila) a un handler que cargue el formulario con los datos del registro.

GestorCuentas.movimientosGrid.on('rowdblclick',function( grid, row, evt) { var movRecord = GestorCuentas.movimientosDataStore.getAt(row); GestorCuentas.movForm.getForm().load({ url : 'cargaMovimiento.php', method: 'POST', params: { mov_id: movRecord.data.mov_id }, waitMsg : 'Espere por favor' }); });

En el API de ExtJS podemos comprobar que cuando asignamos una función al evento ‘rowdbclick’ vamos a recibir tres parámetros: el grid que ha generado el evento, el índice del registro dentro del store y un objeto con datos adicionales del evento

Para quedarnos con el registro, sólo tenemos que solicitarle al store del grid que nos devuelva aquel cuyo índice hemos recibido por parámetro

var movRecord = GestorCuentas.movimientosDataStore.getAt(row);

Ahora en movRecord tendremos el registro y podremos acceder a sus datos para quedarnos con el identificador del registro. Fijáos que en la definición del record del grid hemos incluído la Primary Key del registro en base de datos, aunque no lo estemos mostrando en el propio grid

Fijáos que el formulario que vamos a cargar tiene asignado un reader, de forma que podemos llamar al método load() del mismo para que automáticamente cargue los datos. Obviamente hay que indicarle que registro se va a cargar por lo que le pasamos como parámetro el mov_id del registro que hemos pedido al store

La instancia del formulario se la pedimos al FormPanel mediante el método getForm(). Esto nos devuelve un objeto Ext.form.BasicForm. Este método tiene un método load() al que le pasamos la configuración necesaria para hacer la carga

GestorCuentas.movForm.getForm().load({ url : 'cargaMovimiento.php', method: 'POST', params: { // OJO, los datos del registro están en movRecord.data y no directamente en movRecord como podría pensarse mov_id: movRecord.data.mov_id }, waitMsg : 'Espere por favor' });

ExtJS CookBook: Código base

Javier Caride — Wed, 03 Dec 2008 09:16:17 +0000

Voy a iniciar una serie de artículos a los que voy a denominar ‘ExtJS Cookbook’, en los que iré explicando pequeñas acciones o trucos de ExtJS pero que por ser muy comunes merecen un poco de atención

La primera parte de esta serie de artículos se van a basar en el código de una miniaplicación para gestión de un rudimentario libro de cuentas y que tenéis disponible para evaluar

Este ejemplo muestra cómo hacer varias cosas: cargar datos desde PHP en Extjs, cargar los datos de un FormPanel desde un GridPanel, filtrar un GridPanel desde un formulario externo, cómo obtener los datos de los campos de un FormPanel, etc.
Espero que los artículos que publique estos días os sean de utilidad

Fichero 1: Código Javascript de la miniaplicación

/* * Definimos nuestros propios validadores de datos * para los formularios */ Ext.apply(Ext.form.VTypes, { daterange : function(val, field) { var date = field.parseDate(val); if(!date){ return; } if (field.startDateField && (!this.dateRangeMax || (date.getTime() != this.dateRangeMax.getTime()))) { var start = Ext.getCmp(field.startDateField); start.setMaxValue(date); start.validate(); this.dateRangeMax = date; } else if (field.endDateField && (!this.dateRangeMin || (date.getTime() != this.dateRangeMin.getTime()))) { var end = Ext.getCmp(field.endDateField); end.setMinValue(date); end.validate(); this.dateRangeMin = date; } return true; }, /** * Definimos un nuevo validador: exclusionNotZero * * Valida un par de campos numéricos para que no puedan tener valor positivo los dos ni * valor cero los dos. * **/ exclusionNotZero: function(val, field) { if (field.exclusionPair) { var pair = Ext.getCmp(field.exclusionPair); var pairValue = pair.getValue(); if ((pairValue > 0) && (val > 0)) { field.markInvalid('Un movimiento no puede tener a la vez haber y deber'); return false; } else if ((pairValue == 0) && (val == 0)){ field.markInvalid('Un movimiento no puede tener haber y deber a cero'); return false; } else { field.clearInvalid(); pair.clearInvalid(); return true; } } return true; } }); Ext.onReady(function() { /* * Creamos un espacio de nombres */ Ext.namespace('GestorCuentas'); /* * Definimos el registro para un movimiento */ GestorCuentas.movimientoRecord = new Ext.data.Record.create([ {name: 'mov_id', type: 'int'}, {name: 'mov_concepto', type: 'string'}, {name: 'mov_fecha', type: 'date', dateFormat: 'Y-m-d'}, {name: 'mov_deber', type: 'float'}, {name: 'mov_haber', type: 'float'} ]); /* * Creamos el reader para el Grid de movimientos */ GestorCuentas.movimientosGridReader = new Ext.data.JsonReader({ root: 'data', totalProperty: 'total', id: 'mov_id'}, GestorCuentas.movimientoRecord ); /* * Creamos el DataProxy para carga remota de los datos */ GestorCuentas.movimientosDataProxy = new Ext.data.HttpProxy({ url: 'cargaMovimientos.php', method: 'POST' }); GestorCuentas.movimientosDataStore = new Ext.data.Store({ id: 'movimientosDS', proxy: GestorCuentas.movimientosDataProxy, reader: GestorCuentas.movimientosGridReader }); /* * Creamos el modelo de columnas para el grid de movimientos de la cuenta */ GestorCuentas.movimientosColumnMode = new Ext.grid.ColumnModel( [{ header: 'Fecha', dataIndex: 'mov_fecha', width: 80, renderer: Ext.util.Format.dateRenderer('d/m/Y') },{ header: 'Concepto', dataIndex: 'mov_concepto', width: 200 },{ header: 'Haber', dataIndex: 'mov_haber', width: 90 },{ header: 'Deber', dataIndex: 'mov_deber', width: 90 }] ); /* * Creamos el reader para el formulario de alta/modificación de movimientos */ GestorCuentas.movimientosFormReader = new Ext.data.JsonReader({ root : 'data', successProperty : 'success', totalProperty: 'total', id: 'mov_id' },GestorCuentas.movimientoRecord ); /* * Creamos el grid de movimientos */ GestorCuentas.movimientosGrid = new Ext.grid.GridPanel({ id : 'mov-movimientos-grid', store : GestorCuentas.movimientosDataStore, cm : GestorCuentas.movimientosColumnMode, enableColLock : false, width : 750, height : 550, bbar : new Ext.PagingToolbar({ pageSize: 20, store: GestorCuentas.movimientosDataStore, displayInfo: true }), selModel : new Ext.grid.RowSelectionModel({singleSelect:false}) }); /* * Creamos el formulario para filtrar el grid */ GestorCuentas.filterForm = new Ext.FormPanel({ id: 'form-filtro', region: 'north', split: false, frame: true, height: 100, width: 800, items: [{ xtype: 'datefield', width: 200, fieldLabel: 'Desde', name: 'startdt', id: 'startdt', vtype: 'daterange', endDateField: 'enddt' // id of the end date field },{ xtype: 'datefield', width: 200, fieldLabel: 'Hasta', name: 'enddt', id: 'enddt', vtype: 'daterange', startDateField: 'startdt' // id of the start date field }] }); /* * Añadimos el botón para borrar el filtro */ GestorCuentas.filterForm.addButton({ text : 'Borrar filtro', disabled : false, handler : function() { GestorCuentas.filterForm.getForm().reset(); GestorCuentas.movimientosDataStore.baseParams = { dateStart: '', dateEnd: '' }; GestorCuentas.movimientosDataStore.load({params: {start:0,limit:20}}); } }); /* * Añadimos el botón para filtrar */ GestorCuentas.filterForm.addButton({ text : 'Filtrar', disabled : false, handler : function() { var startDate = GestorCuentas.filterForm.findById('startdt').getValue(); var endDate = GestorCuentas.filterForm.findById('enddt').getValue(); GestorCuentas.movimientosDataStore.baseParams = { dateStart: startDate.dateFormat('Y-m-d'), dateEnd: endDate.dateFormat('Y-m-d') }; GestorCuentas.movimientosDataStore.load({params: {start:0,limit:20}}); } }); /* * Creamos el formulario de alta/modificación de movimientos */ GestorCuentas.movForm = new Ext.FormPanel({ id: 'form-movimientos', region: 'west', split: false, collapsible: true, frame: true, width: 300, minWidth: 300, height: 500, waitMsgTarget: true, reader: GestorCuentas.movimientosFormReader, items: [{ fieldLabel : 'Haber', xtype: 'numberfield', id: 'frm_mov_haber', name : 'mov_haber', exclusionPair: 'frm_mov_deber', vtype: 'exclusionNotZero', allowBlank:false, width : 175 },{ fieldLabel : 'Deber', xtype: 'numberfield', id: 'frm_mov_deber', name : 'mov_deber', exclusionPair: 'frm_mov_haber', vtype: 'exclusionNotZero', allowBlank:false, width : 175 }, { fieldLabel : 'Concepto', id: 'frm_mov_concepto', name : 'mov_concepto', allowBlank:false, xtype: 'textarea', width : 175, height: 225 }, { fieldLabel : 'Fecha', id: 'frm_mov_fecha', name : 'mov_fecha', allowBlank:false, xtype: 'datefield', renderer: Ext.util.Format.dateRenderer('d/m/Y'), width : 175 }, { id: 'frm_mov_id', name : 'mov_id', xtype: 'hidden' }] }); /* * Añadimos el botón para borrar el formulario */ GestorCuentas.movForm.addButton({ text : 'Borrar formulario', disabled : false, handler : function() { GestorCuentas.movForm.getForm().reset(); } }); /* * Añadimos el botón para guardar los datos del formulario */ GestorCuentas.movForm.addButton({ text : 'Guardar', disabled : false, handler : function() { GestorCuentas.movForm.getForm().submit({ url : 'salvaMovimientos.php', waitMsg : 'Salvando datos...', failure: function (form, action) { Ext.MessageBox.show({ title: 'Error al salvar los datos', msg: 'Error al salvar los datos.', buttons: Ext.MessageBox.OK, icon: Ext.MessageBox.ERROR }); }, success: function (form, request) { Ext.MessageBox.show({ title: 'Datos salvados correctamente', msg: 'Datos salvados correctamente', buttons: Ext.MessageBox.OK, icon: Ext.MessageBox.INFO }); responseData = Ext.util.JSON.decode(request.response.responseText); GestorCuentas.movForm.getForm().reset(); GestorCuentas.movimientosDataStore.load({params: {start:0,limit:20}}); } }); } }); /* * Añadimos el evento doble click en una fila para editar el registro correspondiente */ GestorCuentas.movimientosGrid.on('rowdblclick',function( grid, row, evt) { var movRecord = GestorCuentas.movimientosDataStore.getAt(row); GestorCuentas.movForm.getForm().load({ url : 'cargaMovimiento.php', method: 'POST', params: { mov_id: movRecord.data.mov_id }, waitMsg : 'Espere por favor' }); }); /* * Creamos la ventana */ GestorCuentas.contentWindow = new Ext.Window({ id: 'libro-cuentas', title:'Gestor Libro de Cuentas', width:860, height:600, iconCls: 'icon-grid', shim:false, animCollapse:false, constrainHeader:true, layout: 'border', renderTo: document.body, items:[GestorCuentas.filterForm, GestorCuentas.movForm, { id: 'col-grid-movimientos', xtype: 'panel', region: 'center', width: 560, layout: 'fit', items:[GestorCuentas.movimientosGrid] } ] }); /* * Mostramos ventana, la centramos y cargamos los datos iniciales en el grid */ GestorCuentas.contentWindow.show(); GestorCuentas.contentWindow.center(); GestorCuentas.movimientosDataStore.load({params: {start:0,limit:20}}); });

Fichero 2: PHP de carga de datos del grid

require_once 'Zend/Loader.php'; Zend_Loader::registerAutoload(); require_once 'Config/ConfigCuentas.php'; $db->setFetchMode(Zend_Db::FETCH_OBJ); if (!empty($_POST['dateStart']) && !empty($_POST['dateEnd'])) { $filterClause = "WHERE (mov_fecha >= '".$_POST['dateStart']."' AND mov_fecha <= '".$_POST['dateEnd']."')"; } else { $filterClause = ' '; } if (!empty($_POST['limit']) && !empty($_POST['start'])) { $limit = $_POST['limit']; $start = $_POST['start']; $limitClause = "LIMIT $start,$limit"; } else { $limitClause = ' '; } $query = "SELECT * FROM mov_movimientos $filterClause ORDER BY mov_fecha ASC $limitClause"; $result = $db->fetchAssoc($query); $resultados = array(); foreach ($result as $record) { $resultados[] = $record; } $retValue = array ( 'total' => count($result), 'data' => $resultados ); echo json_encode($retValue);

Fichero 3: PHP de carga de datos del formulario

require_once 'Zend/Loader.php'; Zend_Loader::registerAutoload(); require_once 'Config/ConfigCuentas.php'; $query = "SELECT * FROM mov_movimientos WHERE mov_id=" . $_POST['mov_id']; $db->setFetchMode(Zend_Db::FETCH_OBJ); $result = $db->fetchAssoc($query); $record = $result[$_POST['mov_id']]; $resultados = array(); $retValue = array ( 'total' => count($result), 'success'=>true, 'data' => array ( array( 'mov_id' => $_POST['mov_id'], 'mov_concepto' => $record['mov_concepto'], 'mov_haber' => $record['mov_haber'], 'mov_deber' => $record['mov_deber'], 'mov_fecha' => $record['mov_fecha'] ) ) ); echo json_encode($retValue);

Fichero 4: PHP de guardado de datos desde el formulario

require_once 'Zend/Loader.php'; Zend_Loader::registerAutoload(); require_once 'Config/ConfigCuentas.php'; if (is_null($_POST['mov_id']) || empty($_POST['mov_id'])) { $query = "INSERT INTO mov_movimientos(mov_fecha,mov_concepto,mov_haber,mov_deber) " ."VALUES(STR_TO_DATE('". $_POST['mov_fecha'] ."', '%d/%m/%Y'),'". $_POST['mov_concepto'] ."',".$_POST['mov_haber'].",".$_POST['mov_deber'].")"; } else { $query = "UPDATE mov_movimientos SET " ."mov_fecha = STR_TO_DATE('". $_POST['mov_fecha'] ."', '%d/%m/%Y')," ."mov_concepto = '" . $_POST['mov_concepto'] ."'," ."mov_haber = " . $_POST['mov_haber'] . "," ."mov_deber = " . $_POST['mov_deber'] . " " ."WHERE mov_id = " . $_POST['mov_id']; } $db->setFetchMode(Zend_Db::FETCH_OBJ); $result = $db->query($query); $lastInsert = $db->lastInsertId(); $resultados = array(); $retValue = array ( 'total' => count($result), 'success'=>true, 'data' => array ( array( 'mov_id' => $mov_id ) ) ); echo json_encode($retValue);

Depurando código con FirePHP y Zend Framework, o como decir adiós a los var_dump()

Javier Caride — Mon, 01 Dec 2008 11:02:34 +0000

Todos los que llevamos tiempo desarrollando en PHP sabemos que una de las tareas más tediosas es la depuración de nuestros scritps, y mucho más si estos están alimentando la respuesta de una llamada AJAX que tiene que devolver los datos en un cierto formato (JSON por ejemplo). Esta tarea se puede hacer más “agradable” si disponemos de un IDE con depuración integrada, como puede ser Zend Studio, o recientemente Eclipse con el módulo PDT

A pesar de la comodidad de tener el depurador integrado en el entorno de desarrollo, muchas veces se hace un poco engorroso tener que iniciar una sesión de depuración cada vez que quieres saber qué datos están pasando por tus variables

Pues bien, para facilitar la vida a los desarrolladores tenemos disponible un nuevo complemento para firefox: FirePHP. Este componente nos permite depurar directamente nuestros scripts PHP en la consola del firebug

La herramienta se basa en enviar unas ciertas cabeceras HTTP desde nuestros scripts PHP y que son capturadas por el plugin. De esta forma, la salida de nuestros scripts no se ve alterada (perfecto para llamadas AJAX que devuelvan un XML o un JSON) y ganamos rapidez en la depuración

FirePHP está ganando popularidad rápidamente entre los desarrolladores y de hecho muchos frameworks como Zend Framework o Symphony están incorporando en su API llamadas para depurar con esta herramienta

Si no estamos usando ninguno de estos frameworks, el equipo de desarrollo de FirePHP nos ofrece una pequeña librería en PHP5 que podemos integrar fácilmente en nuestros scripts

Lo primero que tenemos que hacer es instalar la extensión FirePHP en nuestro Firefox. Luego descargamos FirePHPCore, descomprimimos el contenido en el directorio donde estemos almacenando las librerías que usamos y ya sólo nos queda hacer las llamadas pertinentes tal y como se nos explica en este tutorial

Si estamos usando Zend Framework y su Modelo Vista Controlador (MVC) también podemos integrar FirePHPCore de forma fácil, si por un casual no nos gustase el API que nos ofrece el propio framework

Primero registramos el logger en el bootstrap.php de nuestra aplicación:

//Incluímos la librería require_once('FirePHPCore/FirePHP.class.php'); // Instanciamos el logger y lo registramos $firebugLogger = FirePHP::getInstance(true); Zend_Registry::set('firebugLogger',$firebugLogger);

Luego en cualquier parte de nuestro código podemos invocar al logger, como por ejemplo en una acción de un controlador:

public function indexAction() { // Obtenemos la instancia del logger previamente registrada // en el bootstrap.php $fbLogger = Zend_Registry::get('firebugLogger'); // Mensajes de log $fbLogger->log('Mensaje'); $fbLogger->info('Mensaje nivel INFO'); $fbLogger->warn('Mensaje nivel WARNING'); $fbLogger->error('Mensaje niverl ERROR'); // Mensaje de log con etiqueta adicional $fbLogger->log('Mensaje','Etiqueta Opcional'); // Podemos mostrar una tabla de datos $table = array(); $table[] = array('Columna 1','Columna 2'); $table[] = array('1:1','1:2'); $table[] = array('2:1','2:2'); $table[] = array('3:1','3:2'); $fbLogger->table('Tabla de datos', $table); // or FB:: // También podemos mostrar información de traza $fbLogger->trace('Trace Label'); }

Aquí podemos ver cómo queda la salida en la consola del Firebug:

Introducción a formularios en ExtJS: Ext.FormPanel

Javier Caride — Fri, 21 Nov 2008 11:47:17 +0000

Definiendo un formulario

Realmente la definición de un formulario que haga su carga de datos y guardado mediante Ajax, no dista mucho de la definición de un grid.

Lo primero que hacemos es definir el registro que contendrá nuestros datos. Como se puede ver en este ejemplo hemos utilizado la misma definición de registro.

var categoriesRecord = new Ext.data.Record.create([ {name: 'cad_id', type: 'int'}, {name: 'cad_name', type: 'string'}, {name: 'cad_description', type: 'string'} ]);

Para la carga de datos y respuestas del servidor, definimos también un reader (al igual que en los grids). Para este ejemplo vamos a seguir utilizando la codificación JSON, aunque podríamos haber elegido un reader XML

var categoriesFormReader = new Ext.data.JsonReader( { root : 'data', successProperty : 'success', totalProperty: 'total', id: 'cad_id' },categoriesRecord );

Como vemos, su definición es prácticamente igual que en el caso del reader del grid, salvo que en esta ocasión hay que definir una propiedad ‘successProperty’ en la respuesta JSON que nos indique si ha tenido éxito o no la operación

Otra novedad respecto al grid, es que podemos indicar a un form desde el servidor si hubo algún error en algún campo. Esto lo podemos utilizar para hacer verificacion de campos en servidor (comprobar duplicados, caracteres no permitidos, etc.). Para ello se define una nueva clase que hereda de JsonReader: JsonErrorReader

Ext.form.JsonErrorReader = function() { Ext.form.JsonErrorReader.superclass.constructor.call(this, { root : 'data', successProperty : 'success', totalProperty: 'total' }, [ {name: 'id'}, {name: 'msg'} ]); };

Podemos ver que en este caso, en la definición del reader se cambia el registro por otro nuevo con sólo dos campos: ‘id’ y ‘msg’. En ‘id’ vendrá el identificador del campo en el que hay un error y en ‘msg’ vendrá el error para ese campo. Es importante que activemos los mensajes superpuestos mediante la línea Ext.QuickTips.init();

La definición del form es sencilla. Como en cualquier otro panel, en la propiedad ‘items’ vamos a introducir el array con todos los componentes del formulario, en este campos (texto, áreas de texto, combos, radios, etc.)

var formCategories = new Ext.FormPanel({ frame : true, width : 624, height: 346, waitMsgTarget : true, reader: categoriesFormReader, errorReader: new Ext.form.JsonErrorReader(), items : [{ fieldLabel : 'Categoría', xtype: 'textfield', name : 'cad_name', allowBlank:false, width : 430 }, { fieldLabel : 'Descripción', name : 'cad_description', allowBlank:false, xtype: 'textarea', width : 430, height: 225 }, { fieldLabel : 'Fecha', name : 'cad_date', allowBlank:false, xtype: 'datefield', renderer: Ext.util.Format.dateRenderer('d/m/Y'), width : 430 }, { name : 'cad_id', xtype: 'hidden' }], });

Acto seguido, vamos a añadir un botón. Esta vez en vez de indicarlo en el array de configuración, vamos a utilizar el método addButton y vamos a añadirle un poco de funcionalidad

var submitFormCategories = formCategories.addButton({ text : 'Guardar', disabled : false, handler : function() { formCategories.getForm().submit({ url : 'formSaver.php', waitMsg : 'Salvando datos...', failure: function (form, action) { Ext.MessageBox.show({ title: 'Error al salvar los datos', msg: 'Error al salvar los datos.', buttons: Ext.MessageBox.OK, icon: Ext.MessageBox.ERROR }); }, success: function (form, request) { Ext.MessageBox.show({ title: 'Datos salvados correctamente', msg: 'Datos salvados correctamente', buttons: Ext.MessageBox.OK, icon: Ext.MessageBox.INFO }); responseData = Ext.util.JSON.decode(request.response.responseText); formCategories.getForm().load({ url : 'formLoader.php', method: 'GET', params: { cat_id: responseData.cat_id }, waitMsg : 'Espere por favor' }); } }); } });

En el handler vemos que realizamos una llamda a la función formCategories.getForm().submit(), a la cual le pasamos un array de configuración. Esta llamada lo que hace es llamar al envío del formulario. Éste se configura pasándole una función para el manejo de error, una función para el manejo de una operación correcta y la URL de actualización.

El código todo unido quedaría de la siguiente forma

Ext.onReady(function() { Ext.QuickTips.init(); /* * Creamos el registro de datos */ var categoriesRecord = new Ext.data.Record.create([ {name: 'cad_id', type: 'int'}, {name: 'cad_name', type: 'string'}, {name: 'cad_date', type: 'date', dateFormat: 'Y-m-d'}, {name: 'cad_description', type: 'string'} ]); var categoriesFormReader = new Ext.data.JsonReader( { root : 'data', successProperty : 'success', totalProperty: 'total', id: 'cad_id' },categoriesRecord ); Ext.form.JsonErrorReader = function() { Ext.form.JsonErrorReader.superclass.constructor.call(this, { root : 'data', successProperty : 'success', totalProperty: 'total' }, [ {name: 'id'}, {name: 'msg'} ]); }; Ext.extend(Ext.form.JsonErrorReader, Ext.data.JsonReader); var formCategories = new Ext.FormPanel({ frame : true, width : 624, height: 346, waitMsgTarget : true, reader: categoriesFormReader, errorReader: new Ext.form.JsonErrorReader(), items : [{ fieldLabel : 'Categoría', xtype: 'textfield', name : 'cad_name', allowBlank:false, width : 430 }, { fieldLabel : 'Descripción', name : 'cad_description', allowBlank:false, xtype: 'textarea', width : 430, height: 225 }, { fieldLabel : 'Fecha', name : 'cad_date', allowBlank:false, xtype: 'datefield', renderer: Ext.util.Format.dateRenderer('d/m/Y'), width : 430 }, { name : 'cad_id', xtype: 'hidden' }], }); var submitFormCategories = formCategories.addButton({ text : 'Guardar', disabled : false, handler : function() { formCategories.getForm().submit({ url : 'formSaver.php', waitMsg : 'Salvando datos...', failure: function (form, action) { Ext.MessageBox.show({ title: 'Error al salvar los datos', msg: 'Error al salvar los datos.', buttons: Ext.MessageBox.OK, icon: Ext.MessageBox.ERROR }); }, success: function (form, request) { Ext.MessageBox.show({ title: 'Datos salvados correctamente', msg: 'Datos salvados correctamente', buttons: Ext.MessageBox.OK, icon: Ext.MessageBox.INFO }); responseData = Ext.util.JSON.decode(request.response.responseText); formCategories.getForm().load({ url : 'formLoader.php', method: 'GET', params: { cat_id: responseData.cat_id }, waitMsg : 'Espere por favor' }); } }); } }); var windowForm = new Ext.Window({ closable: true, resizable: true, modal: false, border: true, plain: true, closeAction: 'hide', title: 'Layout Tab', width: 640, height: 380, renderTo: 'divRender', items: [formCategories] }); formCategories.getForm().load({ url : 'formLoader.php', method: 'GET', params: { cat_id: 1 }, waitMsg : 'Espere por favor' }); windowForm.show(); });

Introduciendo un combo como campo

El tratamiento de un combo requiere un poco más de trabajo. En este caso vamos a introducir el combo en el formulario como un objeto independiente.

var categoriesComboWebs = new Ext.form.ComboBox({ fieldLabel: 'Web', hiddenName: 'cad_web', // Este campo es importante, sin él no funciona el combo store: new Ext.data.SimpleStore({ fields: ['cad_web', 'cad_web_text'], data : websData, id: 0 }), valueField: 'cad_web', displayField: 'cad_web_text', typeAhead: true, mode: 'local', triggerAction: 'all', emptyText: 'Seleccione una web...', selectOnFocus: true, width: 430 });

En este caso hemos hecho que el combo sea local, y que los datos los saque de un Array. Para ello, hemos definido el store del mismo como un Ext.data.SimpleStore. En la propiedad data, hemos indicado cual es la variable javascript que contiene los valores a utilizar, y debe contener valores de la siguiente forma:

var websData = [ ['1','http://www.3megapixels.com'], ['2','http://www.desarrollosweb.net'], ['3','http://www.axena.org'], ['4','http://www.javiercaride.es'] ];

Una propiedad importante, para que cuando carguemos los datos se seleccione bien el elemento del combo correspondiente y que además se envíe al servidor la variable correcta, es ‘hiddenName’. Debe estar inicializada al valor del registro que contiene la información, en este caso cad_web

Introducción a los Grids en ExtJS

Javier Caride — Tue, 18 Nov 2008 12:27:05 +0000

En ExtJS tenemos básicamente dos tipos de grids, los que únicamente son para listar información (los llamaremos Grids básicos) y los grids editables, que permiten editar la información que se lista dentro de ellos.

Grid básico

En los grids tenemos que distinguir 3 partes importantes:

El store de datos

El modelo de datos de las columnas

La definición del grid en sí

El store de datos, es el objeto que se encarga de almacenar los datos que se van a mostrar en el grid. Básicamete se tratan de arrays de datos, pero su particularidad es que pueden leer los datos desde diversas fuentes:

Estáticas: ficheros XML o variables de tipo array

Dinámicas: servicios de datos XML o JSON

En la definición de un store tenemos que tener en cuenta dos aspectos importantes: el formato de los datos, que nos va a indicar qué tipo de reader necesitamos configurar y si el origen de dato es remoto, configurar el proxy de lectura de datos

El modelo de datos de las columnas nos define qué datos se van a mostrar en el grid, con qué formato, y de donde se extraen los datos. Hay que tener en cuenta que aunque en un registro se lean muchos campos, podemos elegir cuales mostrar y cuales no.

Pasos para configurar un grid

Primero definimos el formato de cada registro, aquí configuramos cuantos campos hay y de que tipo

/* * Creamos el registro de datos */ var categoriesRecord = new Ext.data.Record.create([ {name: 'cad_id', type: 'int'}, {name: 'cad_name', type: 'string'}, {name: 'cad_date', type: 'date', dateFormat: 'Y-m-d'}, {name: 'cad_description', type: 'string'} ]);

Después, configuramos el lector de datos. Como se dijo antes, el lector de datos será diferente dependiendo del formato de los datos que obtengamos. En este caso estamos definiendo que los datos nos vendrán codificados en JSON

/* * Creamos el reader de datos */ var categoriesGridReader = new Ext.data.JsonReader({ root: 'data', totalProperty: 'total', id: 'cad_id'}, categoriesRecord );

La configuración del reader es fácil de entender:

Mediante el campo root, indicamos la etiqueta bajo la que llegarán los datos, en este caso ‘data’

El campo totalProperty nos indica en qué etiqueta nos llega el número total de registros

El campo id, nos indica en qué campo nos llega la identificación del registro

Una vez tenemos configurado el registro y el reader, definimos el proxy de datos (para una carga remota de los mismos).

/* * Creamos el proxy para lectura remota de datos */ var categoriesDataProxy = new Ext.data.HttpProxy({ url: 'scripts/categoriesService.php', // Servicio web method: 'POST' // Método de envío });

En este caso, vemos que la carga la hacemos a través de un script php.El cual nos debe devolver un JSON como el siguiente:

{ "total":3, "data":[ { "cad_id":1, "cad_name":"Categoría 1", "cad_description":"Descripción de la primera categoría", "cad_date": "2008-10-01" },{ "cad_id":2, "cad_name":"Categoría 2", "cad_description":"Descripción de la segunda categoría", "cad_date": "2008-10-11" },{ "cad_id":3, "cad_name":"Categoría 3", "cad_description":"Descripción de la tercera categoría", "cad_date": "2008-10-20" },{ "cad_id":4, "cad_name":"Categoría 4", "cad_description":"Descripción de la cuarta categoría", "cad_date": "2008-10-21" }, ] }

Para ello, el php de prueba tiene este contenido

$retValue = array( 'total' => 4, 'data' => array( array( 'cad_id' => 1, 'cad_name' => 'Categoría 1', 'cad_description' => 'Descripción de la primera categoría', 'cad_date' => '2008-10-01' ), array( 'cad_id' => 2, 'cad_name' => 'Categoría 2', 'cad_description' => 'Descripción de la segunda categoría', 'cad_date' => '2008-10-11' ), array( 'cad_id' => 3, 'cad_name' => 'Categoría 3', 'cad_description' => 'Descripción de la tercera categoría', 'cad_date' => '2008-10-20' ), array( 'cad_id' => 4, 'cad_name' => 'Categoría 4', 'cad_description' => 'Descripción de la cuarta categoría', 'cad_date' => '2008-10-21' ) ) ); echo json_encode($retValue);

En el caso de scripts php, primero hay que crear en un array la estructura que queramos devolver y después codificar mediante al función json_encode (PHP5), o bien (en PHP4) utilizar la librería de codificación JSON que provee PEAR

Hay que tener en cuenta una cosa JSON, trabaja únicamente en UTF-8, por lo que si los datos los extraemos por ejemplo de una base de datos configurada en ISO-8859-1, HAY QUE CONVERTIRLOS A UTF-8, obligatoriamente.

Ahora ya tenemos todos los elementos necesarios para configurar el store del grid:

/* * Creamos el datastore donde se van a almacenar los datos de la tabla */ var categoriesDataStore = new Ext.data.Store({ id: 'categoriesDS', //Indicamos de donde se va a leer los datos, en este caso un servicio web proxy: categoriesDataProxy, // Parámetros base que se enviarán al script baseParams: { language: "es_ES" }, // Indicamos el reader, es decir el procesador de los datos reader: categoriesGridReader });

Ya por último, antes de definir el grid en sí, definimos cuales van a ser nuestras columnas, su tipo, ancho, etc.

var categoriesColumnMode = new Ext.grid.ColumnModel( [{ header: '#', dataIndex: 'cad_id', width: 50, hidden: false },{ header: 'Categoría', dataIndex: 'cad_name', width: 150 },{ header: 'Descripción', dataIndex: 'cad_description', width: 300 },{ header: 'Fecha', dataIndex: 'cad_date', width: 90, renderer: Ext.util.Format.dateRenderer('d/m/Y') }] );

Ahora ya tenemos todos los elementos necesarios para configurar el grid:

var categoriesGrid = new Ext.grid.GridPanel({ id: 'cat_categoriesGrid', store: categoriesDataStore, cm: categoriesColumnMode, enableColLock:false, selModel: new Ext.grid.RowSelectionModel({singleSelect:false}) });

Sólo nos falta poner todo dentro de un bloque Ext.onReady y definir una ventana para poder visualizar el grid.

Grid editable

Además de los grids básicos, ExtJS permite definir grids en los que se puedan editar valores. Para convertir un grid no editable a uno editable, tenemos que hacer cambios en dos lugares: en el ColumnModel y en la definición del grid En el Column mode, hay que incluir una etiqueta ‘editor’ en aquellas columnas que queramos hacer editables. En esta etiqueta los que se pone es la definición de un campo editable cuyo objeto puede ser cualquiera de los que hay disponibles para los formularios (cajas de texto, combos, fechas, tiempo…)

var categoriesColumnMode = new Ext.grid.ColumnModel( [{ header: '#', dataIndex: 'cad_id', width: 50, hidden: false },{ header: 'Categoría', dataIndex: 'cad_name', width: 150, editor: new Ext.form.TextField({}) },{ header: 'Descripción', dataIndex: 'cad_description', width: 300, editor: new Ext.form.TextField({}) },{ header: 'Fecha', dataIndex: 'cad_date', width: 90, renderer: Ext.util.Format.dateRenderer('d/m/Y'), editor: new Ext.form.DateField({}) }] );

La modificación del grid es “más fácil”. En este caso sólo hay que heredar de otra clase distinta: EditorGridPanel

var categoriesGrid = new Ext.grid.EditorGridPanel({ id: 'cat_categoriesGrid', store: categoriesDataStore, cm: categoriesColumnMode, enableColLock:false, selModel: new Ext.grid.RowSelectionModel({singleSelect:false}) });

Al ejecutar el ejemplo, podemos ver que al hacer doble click en cualquiera de los campos editables, se nos permite cambiar el valor del campo y que dicho cambio queda marcado en la esquina superior izquierda con un pequeño icono rojo

Tratando los cambios en un grid editable

De nada nos sirve tener un grid editable si no tratamos los datos, pues todos los cambios que se hagan en un grid editable son cambios en el store local.

ExtJS no ofrece ningún mecanismo para automatizar el guardado de datos, dejando a elección del programador la elección del método. Por ejemplo, podemos hacer actualizaciones campo a campo, capturando el evento de cambio de una celda, o bien podemos enviar todos los cambios de una vez mediante la acción en algún botón o componente

Qué método utilizar queda a elección del desarrollador según las circunstancias en las que se encuentre. En este caso vamos a explicar cómo se haría un envío de todos los cambios. Para ello vamos a coger el ejemplo anterior y primeramente añadir un botón de actualización de cambio situado en una barra de herramientas superior

var categoriesGridTopbar = new Ext.Toolbar({ id: 'categoriesGridTopbarId', items: [ '->', { xtype:'button', text:'Guardar Cambios', id: 'portadas_ToolbarTop_btn0', handler:categoriesGridTopbarHnd, type:'button' } ] });

Como se puede ver, se a asignado un handler al botón, que será el que tenderá la petición de guardado de cambios y que contendrá toda la lógica de actualización

En el handler, lo que hemos hecho es crear una llamada Ajax que envíe al servidor todos los cambios, para ello se pide al store un array con todos los registros que han cambiado, se recorre y se almacena en un array los datos necesarios para enviar. Este array se codifica en JSON y se envía como una variable POST normal. Después es tarea del script php (o Java, o lo que sea) de tratar el array de cambios y realizar las actualizaciones pertinentes.

var failureAjaxFn = function(response, request) { Ext.Msg.show({ title: 'Error', msg: 'Cambios no guardados. Status:' + response.status, buttons: Ext.Msg.OK, animEl: 'elId', icon: Ext.MessageBox.ERROR }); } var successAjaxFn = function(response, request) { /* * En response.responseText tenemos la respuesta del script, en este caso * la salida del script PHP es JSON con lo que tenemos que decodificarlo */ var jsonData = Ext.util.JSON.decode(response.responseText); if (true == jsonData.success) { Ext.Msg.show({ title: 'Operación completada', msg: jsonData.message, buttons: Ext.Msg.OK, animEl: 'elId', icon: Ext.MessageBox.INFO }); /* * PASO IMPORTANTE * Para indicar al store que los cambios se han realizado correctamente * y eliminar los indicadores de que hay cambios pendientes de guardar * hay que llamar */ categoriesDataStore.commitChanges(); } else { Ext.Msg.show({ title: 'Error', msg: jsonData.message, buttons: Ext.Msg.OK, animEl: 'elId', icon: Ext.MessageBox.ERROR }); } } var categoriesGridTopbarHnd = function (e,o) { /* * Pedimos al store que nos devuelva los registros modificados */ var modifiedRecords = categoriesDataStore.getModifiedRecords() if (modifiedRecords.length > 0) { /* * Creamos un array con los datos de los registros que han cambiado */ var changes = new Array(); for (var i=0; i < modifiedRecords.length; i++){ changes.push(modifiedRecords[i].data); } /* * Codificamos los cambios en JSON */ changes = Ext.util.JSON.encode(changes); Ext.Ajax.request({ url: 'salvarDatos.php', method: 'POST', success: successAjaxFn, failure: failureAjaxFn, timeout: 30000, params: { operation: 'update', changes: changes } }); } }

Grids paginados

Uno de las barras de herramientas más utilizadas con los grids es la de paginación. Su utilización es
bastante sencilla. Primero creamos la barra de paginación:

var categoriesPagingBar = new Ext.PagingToolbar({ pageSize: 10, store: categoriesDataStore, displayInfo: true });

Su uso es sencillo, sólo tenemos que indicar cual es el store, y el tamaño de página. Después de definirlo
se lo asociamos al grid, para lo que sólo tenemos que indicar en la configuración
lo siguiente “bbar: categoriesPagingBar”:

var categoriesGrid = new Ext.grid.EditorGridPanel({ id: 'cat_categoriesGrid', store: categoriesDataStore, cm: categoriesColumnMode, enableColLock:false, tbar: categoriesGridTopbar, bbar: categoriesPagingBar, selModel: new Ext.grid.RowSelectionModel({singleSelect:false}) });

Después en la carga inicial de datos, indicamos que queremos cargar la primera página de resultados
y el número de ellos

categoriesDataStore.load({params: {start: 0, limit: 10}});

Y después de esto ya no nos tenemos que preocupar de nada más, pues cada vez que hagamos click en los botones el store nos enviará dos variables nuevas: start y limit, al estilo de las paginaciones clásicas