E4X, Javascript y XML

noviembre 13, 2010

Hace un tiempo, acceder a documentos XML era perfectamnete posible, pero había que pasar por APIs que quizás no eran todo lo sencillas que deberían ser.

Las dos principales APIs que nos servían para procesar un documento XML eran DOM y SAX. Los nombres describían la forma de acceder al documento, mientras que en DOM se cargaba todo el documento en memoria, y podiamos acceder de una forma más sencilla, en SAX registrabamos una serie de “callbacks” a los que se nos iba llamando segun se procesaba el documento.

Sin duda DOM era mas sencilla desde el punto de vista del uso, pero menos eficiente, si nuestro documento era muy grande, necesitabamos tenerlo completamente en memoria. Por su lado SAX era más eficiente, pero la forma de desarrollar con él era bastante incomoda, ya que teniamos que separar nuestro código en multiples funciones de callback y nosotros teniamos que ser responsables de mantener el estado entre las diferentes llamadas.

Sin duda, hoy en día XML es el lenguaje de intercambio de datos más extendido (ya veremos en unos pocos años si esto sigue siendo así). Y sobre todo teniendo en cuenta que en el entorno del navegador, usar XML suele (o solía) ser común para intercambiar datos usando AJAX.

Debido a todo esto, poco a poco los lenguajes han ido incorporando mecanismos cada vez más comodos para procesar los documentos XML, como por ejemplo en Java JAXP . En este caso vamos a hablar sobre E4X, o la extensión de ECMAScript para el procesado de documentos XML.

Tratar un documento XML con esta extensión es sumamente sencillo, de hecho, el propio código habla por si mismo.

var library = <library postalcode="28000">
<books>
<book id="1">
  <title>Book Title 1</title>
  <author>Author of Book 1</author>
</book>
<book id="2">
  <title>Book Title 2</title>
  <author>Other Author of Book 2</author>
</book>
</books>
<magazines>
<magazine id="1">
<title>Magazine title 1</title>
</magazine>
</magazines>
</library>

alert(library.books.book[0].title); // Book Title 1
alert(library.books.book.(@id == "2").author); // Other Author of Book 2

Como veis, el procesado de un documento XML se simplifica de una manera dramática. Al mapear un documento XML a un objeto, su forma de acceso es practicamente similar a como lo haríamos con dicha estructura de datos.

La sintaxis de acceso al documento nos recuerda en cierta manera a XPath, pudiendo hacer cosas como:

alert(library.books..*.length()) 
	// El operador .. accede a todos los hijos.
alert(library.magazines.magazine[0].@id) 
	// Usando el operador @ accedemos a los atributos
alert(library.books.book.(@id == "2").author); 
	// Podemos filtrar por el valor de los atributos

Además de ayudar a procesar un documento, tambien tenemos facilidad para generar XML, si “encerramos” una expresion entre {}, se sustituirá por su valor, o incluso usando el operador +, añadiremos nuevos elementos al documento.

var b = "book"
var xmlDoc = <{b}><title>The Title</title></{b}>
alert(xmlDoc.toXMLString())

library.books.book += <book id="3"><title>....</book>

Después de ver todo lo que E4X puede hacer por nosotros, ahora contaremos la parte mala :).

Actúalmente, solo esta soportado en productos de Mozilla, esto es, Firefox, Thunderbird o Rhino, además de ActionScript, pero no se puede utilizar en Chrome, Safari o Internet Explorer. Y, ¿Por qué sucede esto?, pues básicamente por que los desarrolladores de los navegadores no consideran que sea necesaria esta implementación, ya que consideran que el acceso estandar usando DOM en Javascript es lo suficientemente versatil como para no necesitar nada más. Además, librerías como JQuery tienen extensiones para manejar documentos XML.

En cualquier caso, al ser un estandar nos garantizamos que si algun día deciden incorporar E4X en los navegadores actúalmente no soportados, funcionará de forma identica a la que lo hace ahora mismo en Firefox o incluso en ActionScript.


Más vale tarde que nunca. Extensiones en Safari.

junio 14, 2010

Pese a que toda la atención del WWDC se la ha llevado el nuevo iPhone, entre el barullo del nuevo teléfono de Apple se ha lanzado una nueva versión del navegador por defecto del OSX, estamos hablando de Safari 5.

Una de las grandes novedades del Safari 5 es que incorpora la posibilidad de ejecutar extensiones, de la misma manera que hace Firefox desde hace mucho tiempo, o mas recientemente Chrome, de hecho, el concepto utilizado es muy similar al usado en el navegador de Google.

Además de para OSX, Safari 5 también esta disponible para Windows, y a diferencia de las versiones anteriores y, basado en mis escasas pruebas, parece que es cuanto menos usable. La buena noticia es que las extensiones son totalmente funcionales también en el sistema operativo de Microsoft.

Hablando ya de las extensiones de Safari, existen varios tipos. Si hablamos de modificar o añadir elementos a la interfaz gráfica de Safari, podemos tener nuevos botones, nuevas barras o nuevos elementos que se añadirán al menú contextual. Aparte de estos elementos, podremos tener extensiones que modifiquen la propia web que estamos visitando, como el típico bloqueador de anuncios o de contenidos Flash

Desde el punto de vista técnico, las extensiones estan programadas usando las típicas técnologias web; HTML5, CSS3 y Javascript

Entrando un poco mas en detalle, típicamente las extensiones estarán formadas por una página HTML que se cargará al incio de la extensión. Esta página la usaremos para colocar las inicializaciones del resto de componentes, así como los eventos que responderán a los elementos gráficos de la propia extension.

Además de esta pagina web, tendremos según los requisitos de esta extension, un conjunto de HTML y CSS que controlarán el aspecto gráfico de nuestra extensión. Por ejemplo, si queremos hacer una barra que muestre algun tipo de información, dicha información estará descrita por un fichero HTML con su correspondiente hoja de estilo, imágenes e iconos.

Si, por otro lado, queremos que nuestra extensión modifique el contenido de la web, necesitaremos tener un conjunto de scripts programados usando Javascript, con el que grácias a la API que nos proporciona el navegador (ofrecida en Javascript tambíen), podremos acceder e incluso modificar el propio contenido de la web que se esta mostrando en el navegador.

Si queremos ponernos manos a la obra, el propio Safari tiene un editor para crear las extensiones. No esperar encontraros un editor de HTML ni nada parecido, en lo que nos ayudará sera en crear la estructura o el “paquete” en el que podremos meter los contenidos de las propias extensiones. Con el Extension builder podremos crear los botones, barras o scripts de las que hemos hablado anteriormente.

Para activarlo, necesitamos ir al menú de preferencias de Safari, y activar el menu de Desarrollador, que por defecto esta desactivado. Una vez activado dicho menú, podremos acceder al Extension builder

El último elemento que necesitamos para crear la extensión es un certificado de desarrollador. Sin este cerficado no podremos ni siquiera instalar una extensión en nuestro navegador. Como vemos, el concepto es muy similar al seguido con el iPhone.

La principal diferencia, es que formar parte del programa de desarrolladores de extensiones de Safari es totalmente gratis. Lo único que tenemos hacer es ir a la web de desarrolladores de apple, http://developer.apple.com y darnos de alta.

Después de rellenar los datos oportunos sólo tendremos que instalar el certificado en el llavero de Mac, o en el almacen de certificados de Windows, para que el Extension Builder lo detecte y nos deje instalar y empaquetar nuestra extensión


Incorporar Modelos ManyToMany al Backend en Django

diciembre 10, 2009

Uno de los beneficios de usar django para crear nuestra aplicación web es que como por arte de mágia, todo el backoffice de nuestra aplicación se generará ante nuestros ojos sin tirar ni una linea de código.

Parafraseando a Uderzo y Goscinny, ¿Ni una sola linea?, No, alguna, cual aldea Gala indestructible, habrá que tirar, pero ni mucho menos comparable a lo que sería hacerlo desde cero.

Hasta hace poco, si en nuestro modelo exitía una relación Muchos a Muchos, la edición desde la interfaz de administración no era todo lo intuitiva que esperaríamos, pero en la última versión de django este aspecto esta solucionado, proporcionandonos una flexibilidad absoluta.

Supongamos un modelo de un sencillo bloc de notas, inicialmente tendremos dos entidades, una que será las notas y otra que serán los tags que asociamos a dichas notas. La relación entre los tags y las notas es de Muchos a Muchos, el código de dichos modelos sería algo como:

class Note(models.Model):
  title = models.CharField(max_length=200)
  pub_date = models.DateTimeField('date created')
  body = models.TextField()
  tags = models.ManyToManyField('Tag', related_name='notes')

  def __unicode__(self):
    return self.title</div>

class Tag(models.Model):
  name = models.CharField(max_length=100)

  def __unicode__(self):
    return self.name

Por defecto, django nos genera una interfaz de administración que podemos ver si entramos a la aplicación “admin” una vez lanzado el servidor. Si usamos el servidor de desarrollo, la URL habitual es http://localhost:8000/admin/

Como deciamos anteriormente, en las versiones anteriores de django, solo podíamos editar (y personalizar usando Inlines por ejemplo) los elementos de la clase asociada donde se definía la relacion ManyToMany. En nuestro caso, solo podriamos asociar y añadir tags desde la gestión de notas, pero no viceversa. Al ser una relación bidireccional, como vemos esto no es muy útil.

Para personalizar las interfaces de administración debemos editar el fichero admin.py que esta dentro de nuestro proyecto.

Si queremos que la lista de objetos de la clase asociada aparezca de forma linear, podemos crear un objeto derivado de algun sabor de Inline, como por ejemplo TabularInline. La novedad en la nueva versión de django es que a la clase que modela la relación ManyToMany posee un atributo que representa la asociación.

Este atributo se conoce como through, en versiones anteriores, ese parámetro nos servía para indicar un modelo extendido asociado a la relación muchos a muchos, a la hora de declarar la propia relación en el modelo.

Así si usamos las siguientes clases:

class TagNoteInline(admin.TabularInline):
  model = Note.tags.through

class TagAdmin(admin.ModelAdmin):
  inlines = [
    TagNoteInline,
  ]

class NoteAdmin(admin.ModelAdmin):
  inlines = [
    TagNoteInline,
  ]
  exlude = ('tags',)

admin.site.register(Note, NoteAdmin)
admin.site.register(Tag, TagAdmin)

Podremos editar en ambas interfaces la clase correspondiente asociada.

Para finalizar, si no has entendido nada 😉 quizás te interese el maravilloso tutorial que esta en la propia web del django y concretamente la relacionada con la parte de administración: http://docs.djangoproject.com/en/dev/intro/tutorial02/#intro-tutorial02

Navegadores y futuro de las aplicaciones web

diciembre 3, 2009

Poco a poco nos estamos dando cuenta que el futuro de las aplicaciones apuntan a “la nube”. Google ha apostado por ello con cosas como GMail, Wave o el reciente Chrome OS. Como elemento imprescindible en esta migración, estan los navegadores, los “vehiculos” hacia la nube. Pero, ¿están preparados los navegadores para esta migración?

Cuando la web empezo a ser web, nadie se podía plantear que de aquel lenguaje de marcado derivado del SGML como era el HTML se podría crear todo una plataforma de desarrollo de aplicaciones. Para que esto fuera posible se incorporó un lenguaje que dotara de dinamismo a las, por aquel entonces novedosas, paginas webs. Estamos hablando de ECMAScript, mas conocido con el “desafortunado” nombre Javascript. Desafortunado por su parecido con Java, del que no tiene nada que ver.

Indudablemente se podría hablar mucho de Javascript, como por ejemplo de las primeras implementaciones en los navegadores, de JScript, de su caprichosa sintaxis, etc., pero este, no es el objetivo de esta entrada 😉

Javascript ha sido uno de los grandes “culpables” de que hoy contemplemos como futuro las nuevas aplicaciones web, sin embargo, también ha sido el culpable de muchos quebraderos de cabeza para los desarrolladores de navegadores. Dichos navegadores llevan intentando optimizar el motor que se encarga de interpretar el Javascript desde hace mucho tiempo, sin embargo el desarrollo de dichas aplicaciones ha acelerado mas rápido que la esperada optimización.

Google juega uno de los papeles mas importantes en esta evolución y es muy consciente que a día de hoy, Javascript es un “problema” desde el punto de vista del rendimiento. Uno de los pilares de la presentacion de Chrome fué precisamente un nuevo motor opensource de javascript, el V8. Sin embargo, actúalmente parece que el problema sigue latente.

Además de la nueva implementación de google existen multitud de motores de Javascript, como Rhino de la fundación Mozilla, JavaScriptCore que implementa Safari o Carakan en Opera, pero a vista de los resultados actuales parece que mas de uno sigue sufriendo cuando debe ejecutar una aplicación compleja.

Para darse cuenta de todo esto, solo hace falta escoger un navegador y ponerse a dar vueltas por la aplicación web de moda, Google Wave. Si bien es cierto que la propia aplicación esta en una fase muy previa a considerarse estable, es cierto que el problema también se presenta en otros casos similares como por ejemplo Google Maps, aunque es cierto que de una manera mucho menos acusada. En el caso de Google Wave el problema es tan grave que deja el navegador totalmente inusable, en el caso de navegadores “monoproceso” como firefox, la unica solucion es “matar” al propio navegador.

Para probarlo en nuestras carnes, solo hace falta introducir una busqueda que incluya waves publicos, como por ejemplo introducciendo el texto “rpg with:public” y empezar a navegar por los waves. Rápidamente obtendremos resultados como los de las siguientes imágenes.

Firefox en linux ejecutando wave

Safari en OSX ejecutando wave

Chrome en Windows ejecutando wave

Por tanto a la pregunta del inicio del post, yo de momento tengo que decir, no, los navegadores aún no estan preparados para un salto total a la nube. Y si además introducimos en la ecuación los navegadores de dispositivos menos potentes como smartphones y versiones “light” de chrome o safari, aún la situacion se complica mas.


Aplicaciones Web como “verdaderas aplicaciones”. ¿Alguien dijo Chrome OS?

noviembre 13, 2009

wave header

Hoy en día todos usamos numerosas apliaciones web, en ciertos casos incluso han desplazado a las aplicaciones tradicionales.

Quizás la primera aplicación web que nos viene a la mente es GMail, en muchos ocasiones es el unico cliente de correo que utilizamos.

La forma de acceder a estas aplicaciones es mediante el navegador, sin duda una de sus grandes ventajas es el hecho de que pueden accederse desde cualquier lado sin embargo, el navegador es un “concepto” que no acaba de encajar con “aplicación”. Conceptualmente, el navegador no se asocia al hecho de alojar aplicaciones.

Cuando estamos manejando una aplicacion como Gmail o Google Wave, hay varias cosas de un navegador que no acaban de encajar, por ejemplo,

  • No necesitamos la barra de direcciones, no vamos a cambiar de página en el contexto de la aplicación
  • No necesitamos los controles del navegador, como por ejemplo para navegar por la historia, ya que dentro de una aplicación, no se vuelve hacia atras usando dichos controles.
  • No necesitamos las extensiones habituales del navegador, y de hecho prescindir de esto aligerará la memoria ocupada por la aplicación, que en el caso de ciertas aplicaciones ya es bastante.
  • En el caso de que la aplicación quiera enviar alguna notificación, como por ejemplo un mensaje nuevo recibido en GMail, será el navegador el encargado de enviar dicha notificación. Si tenemos en cuenta que una sesion actual en un navegador tiene muchas pestañas, la posibilidad de notificar directamente por parte de la aplicación web se complica.
  • La aplicación no aparece al mismo nivel que el resto de aplicaciones del sistema. Como ejemplo pongamos que queremos cambiar del Editor de Textos al gestor de correo, antes deberiamos pasar primero por el propio navegador. Cosa que es bastante incomodo.

Como vemos, las aplicaciones web piden a gritos salir del navegador y convertirse en aplicaciones “de ley” en nuestro escritorio.

Existen diversas alternativas para “extraer” estas aplicaciones del navegador y convertirlas en una mas de nuestro sistema operativo.

Una alternativa es Prism. Prism es un proyecto de mozilla, que como es evidente usa el motor de renderizado del firefox para crear mostrar la página web. El resultado que obtenemos de usar prism es un programa como otro cualquiera y que al ejecutarlo accederemos a la aplicación quitando todas las decoraciones del navegador.

Si usamos mac, tenemos Fluid, cuyo objetivo es similar.

Y como no, la estrella de toda esta iniciativa de aplicaciones web, google tiene su propia alternativa para crear aplicaciones reales a partir de sus similares en web.

Usando Chrome, podemos separar las webs como aplicaciones mediante la opción de menu llamada: “Crear accesos directos a aplicaciones…”. Usando esta opción las aplicaciones tendrán su propia entidad en el escritorio, apareciendo como cualquier otra en la barra de tareas, o como acceso directo junto al resto de aplicaciones del sistema. Además, cuando lancemos las aplicaciones desde este entorno, se eliminaran los elementos que antes mencionábamos como accesorios.

Wave en Chrome

Seguramente y como mencionaba en el titulo de la entrada, muy pronto estaremos hablando de este concepto mucho mas en serio, puesto que, sacando la bola de cristal del cajón, viendo las últimos movimientos de google, mucho me temo que la idea sobre la que se basa Chrome OS, puede ir por estos derroteros.


Un cambio necesario. HTML 5.

septiembre 22, 2009
Estamos viendo nacer uno de los cambios más importantes de los últimos años, la próxima versión de uno de los lenguajes más usados en la actualidad, el HTML 5, está ultimando sus detalles finales.
El actual estándar (4.01) data de 1999 (aunque la última revisión fue en 2001), en estos casi 10 años, han pasado muchísimas cosas en lo que se refiere a las páginas web, la evolución del lenguaje que se responsabiliza de mostrar los contenidos al usuario necesitaba un cambio para adaptarse a estos nuevos tiempos.
Pese a que durante este tiempo el estándar HTML no se ha movido, lo cierto es que han surgido muchas tecnologías que ayudaban a paliar esta inmovilidad, como pueden ser los CSS, o incluso el mismo Flash.
Con cosas como Flash, se han cubierto las necesidades que las nuevas tecnologías demandaban.
Para entender la película al completo, falta incorporar a los actores principales, los navegadores, las aplicaciones que son los encargados de mostrar el HTML y todo su contenido adicional.
Aunque originalmente, los navegadores mostraban contenido bastante estático, hoy en día son plataformas lanzadoras de aplicaciones, como vemos, los movimientos de las grandes empresas se dirigen a encapsular cada vez mas aplicaciones en el navegador, ejemplos los hay en gran número, gmail, google docs, office online, flickr, solo son unos pocos casos.
El futuro de la web pasar por la implementación de los nuevos estándares en los navegadores.
A diferencia de las anteriores revisiones de HTML, la evolución que se va a publicar va a ser de gran importancia ya que el uso de la web hace 10 años no tiene nada que ver con el que se realiza hoy en día. Si pensamos para que usábamos un navegador hace 10 años y lo comparamos con el uso que le damos actualmente nos daremos cuenta que poco tiene que ver. Según que trabajo, es posible que la única aplicación que ejecutemos durante un día de trabajo sea un navegador.
Uno de los cambios más importantes que incorpora HTML5 es que expone una API que permite manipular directamente elementos de la página, por ejemplo, se ha incorporado el elemento canvas con el podrá pintar gráficos 2D de forma directa, sin tener que usar “trucos” de javascript o elementos externos como flash o applets java.
Derivado de las nuevas APIs, esta otro gran cambio, en HTML5 es la incorporación de elementos multimedia de forma nativa, mediante el uso del tag audio o video, podremos incrustar en nuestras webs videos sin tener que recurrir a ningún plugin, solo necesitaremos un navegador compatible.
Con esta nueva versión de HTML 5 también se ha incorporado la posibilidad de acceder a aplicaciones web estando offline, lo que ya nos proporcionaba Google Gears, va a estar incluido dentro del navegador. Como veíamos la penetración de las aplicaciones web en nuestro uso diario ha influido de forma determinante en la incorporación de estas necesidades.
Aparte de estos cambios, la nueva versión ha revisado numerosos elementos del lenguaje, por ejemplo han eliminado tags como <font> o <center> forzándolos a moverlos a la css con el fin de separar realmente la presentación del contenido.
Como comentábamos antes, la parte más importante del papel son los navegadores, y son los que tienen que materializar los cambios que impone el estándar, por ejemplo debido a la inclusión de los contenidos audiovisuales de forma nativa, los navegadores van a tener que incluir una gestión de contenidos multimedia  que antes no necesitaban incorporar, ya que se encargaban de ellos otros elementos como los plugins.
En el momento de escribir esta entrada hay varios navegadores con soporte preliminar de HTML 5. Firefox 3.5, Chrome v3, Safari 4 y Opera 10.
Un buen punto de entrada puede ser la versión de HTML 5 de youtube: http://www.youtube.com/html5 . Si entramos en esta web con uno de los navegadores anteriores podremos ver el video sin necesidad de instalar ningún plugin.

Safari HTML5

Estamos viendo nacer uno de los cambios más importantes de los últimos años, la próxima versión de uno de los lenguajes más usados en la actualidad, el HTML 5, está ultimando sus detalles finales.

El actual estándar (4.01) data de 1999 (aunque la última revisión fue en 2001), en estos casi 10 años, han pasado muchísimas cosas en lo que se refiere a las páginas web, la evolución del lenguaje que se responsabiliza de mostrar los contenidos al usuario necesitaba un cambio para adaptarse a estos nuevos tiempos.

Pese a que durante este tiempo el estándar HTML no se ha movido, lo cierto es que han surgido muchas tecnologías que ayudaban a paliar esta inmovilidad, como pueden ser los CSS, o incluso el mismo Flash.

Con cosas como Flash, se han cubierto las necesidades que las nuevas tecnologías demandaban.

Para entender la película al completo, falta incorporar a los actores principales, los navegadores, las aplicaciones que son los encargados de mostrar el HTML y todo su contenido adicional.

Aunque originalmente, los navegadores mostraban contenido bastante estático, hoy en día son plataformas lanzadoras de aplicaciones, como vemos, los movimientos de las grandes empresas se dirigen a encapsular cada vez mas aplicaciones en el navegador, ejemplos los hay en gran número, gmail, google docs, office online, flickr, solo son unos pocos casos.

El futuro de la web pasar por la implementación de los nuevos estándares en los navegadores.

A diferencia de las anteriores revisiones de HTML, la evolución que se va a publicar va a ser de gran importancia ya que el uso de la web hace 10 años no tiene nada que ver con el que se realiza hoy en día. Si pensamos para que usábamos un navegador hace 10 años y lo comparamos con el uso que le damos actualmente nos daremos cuenta que poco tiene que ver. Según que trabajo, es posible que la única aplicación que ejecutemos durante un día de trabajo sea un navegador.

Uno de los cambios más importantes que incorpora HTML5 es que expone una API que permite manipular directamente elementos de la página, por ejemplo, se ha incorporado el elemento canvas con el podrá pintar gráficos 2D de forma directa, sin tener que usar “trucos” de javascript o elementos externos como flash o applets java.

Derivado de las nuevas APIs, esta otro gran cambio, en HTML5 es la incorporación de elementos multimedia de forma nativa, mediante el uso del tag audio o video, podremos incrustar en nuestras webs videos sin tener que recurrir a ningún plugin, solo necesitaremos un navegador compatible.

Con esta nueva versión de HTML 5 también se ha incorporado la posibilidad de acceder a aplicaciones web estando offline, lo que ya nos proporcionaba Google Gears, va a estar incluido dentro del navegador. Como veíamos la penetración de las aplicaciones web en nuestro uso diario ha influido de forma determinante en la incorporación de estas necesidades.

Aparte de estos cambios, la nueva versión ha revisado numerosos elementos del lenguaje, por ejemplo han eliminado tags como <font> o <center> forzándolos a moverlos a la css con el fin de separar realmente la presentación del contenido.

Como comentábamos antes, la parte más importante del papel son los navegadores, y son los que tienen que materializar los cambios que impone el estándar, por ejemplo debido a la inclusión de los contenidos audiovisuales de forma nativa, los navegadores van a tener que incluir una gestión de contenidos multimedia que antes no necesitaban incorporar, ya que se encargaban de ellos otros elementos como los plugins.

En el momento de escribir esta entrada hay varios navegadores con soporte preliminar de HTML 5. Firefox 3.5, Chrome v3, Safari 4 y Opera 10.

Un buen punto de entrada puede ser la versión de HTML 5 de youtube: http://www.youtube.com/html5 . Si entramos en esta web con uno de los navegadores anteriores podremos ver el video sin necesidad de instalar ningún plugin.


Introducción a Django

junio 15, 2009

Django DemoEn el anterior post hablamos en general de los frameworks de desarrollo rápido que habían surgido recientemente. Concretamente nos vamos a centrar en Django por los motivos que comentamos anteriormente.

Django surgió en una redacción de noticias donde requerían una herramienta flexible que les permitiera realizar cambios de una forma ágil. Básicamente el framework nos va a permitir crear aplicaciones basadas en el modelo MVC, que usen operaciones de CRUD ( Create, read, update and delete) o como lo conocemos en español el típico Altas, Bajas Modificaciones y Consultas.

¿De que forma nos va a ayudar?
Principalmente creando toda la lógica de la gestión de nuestras clases con la base de datos.
Además de proporcionarnos toda la API para la gestión de los datos, Django nos va a proporcionar dos cosas adicionales:

  • Una interfaz web genérica auto-generada para gestionar los datos
  • Una API para construir webs que gestionen estos datos.

Durante las sucesivas entradas veremos a ver si realmente el framework nos va a ayudar a crear nuestra aplicación, particularmente en mi contacto con este tipo de frameworks si te adaptas bien a la filosofía del framework nos va a ayudar bastante en la creación de nuestra aplicación.

En este primer post vamos a ver la instalación del framework y después crearemos el esqueleto de nuestro primer proyecto.

A la hora de instalarlo tenemos varias alternativas, si usamos una distribución que incluya django como paquete solo tendremos que instarlo, ahora mismo estoy escribiendo desde Ubuntu 9.04 y solo he tenido que ejecutar apt-get install python-django.
Si nuestra distribución no esta soportada directamente o bien usamos OS X o Windows, debemos bajarnos la ultima versión del sitio web de django ( http://www.djangoproject.com/download/ ) y ejecutar setup.py install con privilegios de administrador.

Una vez que lo tenemos instalado el primer paso es ejecutar el script que va a crear el esqueleto de nuestra aplicación:

$ django-admin startproject pruebadjango

Con esta orden se nos creara un nuevo directorio llamado pruebadjango con los siguientes ficheros relevantes:

  • manage.py: Script que nos va a permitir realizar las diferentes labores de administración sobre la aplicación como gestionar el servidor web embebido que tiene django o la relación con la base de datos
  • settings.py: Fichero que contiene los parámetros de configuración de nuestra aplicacion, como por ejemplo los datos de conexión a la base de datos
  • urls.py: Fichero donde se especifican los mapeos entre las URLs y los paquetes que van a gestionar esa URL, para los que hemos usado Java y sus aplicaciones web, seria una especie de web.xml

Como buen impaciente ;), lo primero que haremos sera ejecutar el servidor, aunque no tiene nada que mostrar, al menos nos confirmará que vamos por el buen camino.

Para ejecutar el servidor debemos escribir:

$ python manage.py runserver

Y si navegamos con el browser a la direccion http://127.0.0.1:8000/ veremos la imagen dela captura, lo que confirmará que tenemos instalado django correctamente y creado nuestro esqueleto que nos va a servir como base en futuras entregas.

Hablando del servidor, una de mis inquietudes con estos frameworks y que aun no ha sido del todo resuelta es como se comportan en entornos donde la exigencia es grande. Aplicaciones web basadas en java reposan en servidores de aplicaciones muy potentes que nos garantizan un buen rendimiento. En este aspecto Grails con Groovy tiene algo ganado, al fin y al cabo es java, y puede aprovecharse de todo lo que apoya a Java. En el caso de frameworks como el que nos ocupa, la fiabilidad viene por Apache y el mod_python. En el ejemplo que hemos propuesto usamos el servidor web embebido en django, sin embargo este servidor solo vale para entornos de desarrollo, a la hora de cambiar a produccion usaremos Apache.