Que bueno fue poder haber asistido a la reunion del Grupo de Usuarios de Java de Costa Rica hoy en la Ulatina... aparte de que fuera una excelente oportunidad para conocer a otros desarrolladores en otras areas, fue excelente poder ver la exposicion de Ben Galbraith y de Dion Almaer.
Estos dos son de los mejores expositores que he visto en mi vida. Una claridad... tanto en los slides usados como en los ejemplos como en la interaccion entre ambos, el conocimiento que tienen... sin palabras!!! En cuanto al contenido de la presentacion bastante claro, empezando por una EXCELENTE introduccion a la necesidad de crear mejores experiencias de interactividad al usuario y como una interfaz no solo bonita, sino que cumpla con el objetivo del usuario puede marcar la diferencia (mostraron bastantes ejemplos). Ademas, fue impresionante ver el desarrollo que ha tenido AJAX y lo que esta pronto por salir... pude ver cosas que pense nunca poder ver en un browser sin correr una maquina virtual como el Flash Player o Java Virtual Machine. Igual... no cambio a Flex... aunque lo que vi fue bastante impresionante y esto ayuda a que todo se ponga mejor y haya mas competencias para brindar mejores experiencias a los usuarios.
Felicidades a Maricel la organizadora del grupo y su grupo de ayudantes... iniciativas de este tipo y otras que ya hay, son las que ocupamos para poder crecer como pais en conocimiento y tecnologia...
Por cierto, en la rifa del final me gane un excelente libro... Yaaayyy!!!
Mostrando entradas con la etiqueta AJAX. Mostrar todas las entradas
Mostrando entradas con la etiqueta AJAX. Mostrar todas las entradas
jueves, 23 de octubre de 2008
viernes, 14 de diciembre de 2007
Interaccion de Flex con datos externos
Empiezo este tema hablando lo negativo... Flex no tiene acceso directo a bases de datos.
Y la respuesta inicial de muchos:
Como???? Entonces de que me va a servir a mi o a mis clientes, si lo más importante de sus aplicaciones es la información, que generalmente se guarda en una Base de Datos??? Mejor me quedo con mi lenguaje web que me permite conectarme con la base de datos desde la misma página que esta cargando el usuario (por que para muchos esa es la mejor manera de hacerlo... )
Si Flex no tiene acceso directo a base de datos, como entonces puedo acceder a mi informacion?
Funcionalidad Flex
Flex fue hecho para funcionar como una interfaz de interacción de un usuario con un determinado sistema. Razón suficiente para preocuparse en brindarle al programador los recursos necesarios para realizar una experiencia totalmente distinta a la de sitios con el tradicional HTML.
Ahora, lógicamente que para interactuar con un sistema, se debe de tratar con datos. La datos es lo más importante en un sistema y de que sirve interactuar con alguien si no le responde a uno nada...? Se hace necesario el uso de un Backend que se encargue de manipular la informacion y transmitirla a la aplicación en Flex.
Ocupo programar en algún lenguaje especial para que funcion esto?
El acceso a datos desde Flex es totalmente independiente del lenguaje en que se programe en el backend. Puede hacerse en Java, Cold Fusion, PHP, Ruby, .NEt, lo que usted se imagine ya que provee varias maneras distintas de accesar la información.
Métodos Básicos
HTTPService: Permite acceder a la un archivo "hosteado" en un servidor. Se puede acceder a información en el mismo servidor o en otro. Esto permite realizar peticiones tipo REST a un servidor, ya que permite el envio de Parametros en el request, pero además permite la manipulación del resultado que esa página produzca... todo por medio de llamadas asincrónimas. Permite no solo la invocación a HTML plano, sino tambien a archivos generados dinámicamente en PHP, JSP, ASP, etc, devolviendo estos el resultado en la forma en que quieran y que el programador pueda interpretar más facilmente. Lo general es devolver el resultado en formato XML. El Actionscript 3 provee una forma muuuuuuy sencilla de manipular el XML (E4X), pero eso se merece otro post aparte
Ejemplo:
RemoteObject: Mi favorito....este es definitivamentelo que hizo que me enamorara del Flex. Es totalmente RPC (remote procedure calls). Funciona en palabras simples asi:
Se tiene un backend creado en X lenguaje, en servidor se tiene una configuración especial para ese lenguaje y el Flex a través de esa configuración puede acceder a los métodos de las clases definidas en la configuración, pasando objetos como parametros y recibiendo objetos como resultados (literalmente objetos, nada de XML ni eso). Esto a través del protocolo AMF, que lo que haces serializar los objetos y mandarlos sea al servidor o al cliente para su respectiva deserialiazación y manipulación. El AMF serializa estos objetos en formato binario, osea es mucho más rápido (mucho más y sino lo cree, corra este ejemplo de James Ward: http://www.jamesward.org/blazebench/) y los manda encapsulados y comprimidos en un metodo POST por http (no teniendo problemas con proxies ni firewalls). No tienen que ser solamente un objeto a la vez, puede enviar colecciones de objetos (Arrays, listas, etc)
Algo bueno es que acaba de ser abierto por Adobe, lo que permitirá que otras personas intenten mejorarlo o darle nuevas aplicaciones...
RemoteObject es asincronimo tambien y hay que manejar tambien el Resultado o la Falla como en el HTTP Service.
Inicialmente funcionaban solamente con Java y ColdFusion (adobe provee librerias para configurar los servicios) sin embargo ya existen las librerias necesarias para configurar en otros lenguajes, ejemplo PHP --> amfphp, Ruby --> rubyamf, WEBORB, AMF.NET --> .NET entre otros.
Ejemplo:
Suponga que tenga una aplicación que tiene un metodo para crear usuarios llamado creaUsuario y que recibe un parametro de tipo Usuario (una clase) con nombre, username y password.
En actionscript, define su clase llamada Usuario también, con las propiedades nombre, username y password, esta clase es un mapeo de la clase Usuario en el server.
Algo asi:
package com.sitio.clases
{
//RemoteClass especifica a que clase en el server va a asemejarse esta. Apunta al mismo folder donde se encuentra la clase pero en el server.
[RemoteClass (alias="com.sitio.clases.Usuario")]
public class Usuario
{
public var nombre:String;
public var username:String;
public var password:String;
}
}
En el MXML (o en Actionscript tambien) se definira el RemoteObject
<mx:remoteobject id="ro_usuario" destination="ServicioEnServidor" result="resultHandler(event)" fault="faultHandler(event)" showbusycursor="true">
</mx:remoteobject>
Esto es:
<mx:button label="Add Item" id="submit" click="enviarForm()"/>
El Script:
De verdad.. si está pensando en iniciar una aplicación en Flex con acceso a datos en el servidor, considere seriamente esta opción pues es mucho más facil que las demás...
WEBService: Permite acceder a información por medio de SOAP. Utiliza la especificación WSDL 1.1. Este método en realidad no lo he usado. Sin embargo está disponible y funciona igualmente con llamadas asincrónimas, haciendo que el programador maneje las funciones de resultado y de falla igual como el HTTP Service. Existen ya varias aplicaciones que utilizan de este medio, por ejemplo Yahoo ofrece varios de sus servicios para desarrolladores en Flex por medio de Web Services, como en los mapas o el clima: http://developer.yahoo.com/flash/astra-webapis/ (ellos "wrappean" los llamados a los servicios desde sus librerías)
Esto por ahora en cuanto a interaccion con datos...
Saludos
Y la respuesta inicial de muchos:
Como???? Entonces de que me va a servir a mi o a mis clientes, si lo más importante de sus aplicaciones es la información, que generalmente se guarda en una Base de Datos??? Mejor me quedo con mi lenguaje web que me permite conectarme con la base de datos desde la misma página que esta cargando el usuario (
Si Flex no tiene acceso directo a base de datos, como entonces puedo acceder a mi informacion?
Funcionalidad Flex
Flex fue hecho para funcionar como una interfaz de interacción de un usuario con un determinado sistema. Razón suficiente para preocuparse en brindarle al programador los recursos necesarios para realizar una experiencia totalmente distinta a la de sitios con el tradicional HTML.
Ahora, lógicamente que para interactuar con un sistema, se debe de tratar con datos. La datos es lo más importante en un sistema y de que sirve interactuar con alguien si no le responde a uno nada...? Se hace necesario el uso de un Backend que se encargue de manipular la informacion y transmitirla a la aplicación en Flex.
Ocupo programar en algún lenguaje especial para que funcion esto?
El acceso a datos desde Flex es totalmente independiente del lenguaje en que se programe en el backend. Puede hacerse en Java, Cold Fusion, PHP, Ruby, .NEt, lo que usted se imagine ya que provee varias maneras distintas de accesar la información.
Métodos Básicos
HTTPService: Permite acceder a la un archivo "hosteado" en un servidor. Se puede acceder a información en el mismo servidor o en otro. Esto permite realizar peticiones tipo REST a un servidor, ya que permite el envio de Parametros en el request, pero además permite la manipulación del resultado que esa página produzca... todo por medio de llamadas asincrónimas. Permite no solo la invocación a HTML plano, sino tambien a archivos generados dinámicamente en PHP, JSP, ASP, etc, devolviendo estos el resultado en la forma en que quieran y que el programador pueda interpretar más facilmente. Lo general es devolver el resultado en formato XML. El Actionscript 3 provee una forma muuuuuuy sencilla de manipular el XML (E4X), pero eso se merece otro post aparte
Ejemplo:
<mx:httpservice id="httpLogin" destination="http://127.0.0.1/login.php" result="resultHandler(event)" fault="faultHandler(event)">
</mx:httpservice>
Esto es:id ==> Nombre con que se manejara el servicio en el MXML y en el ActionscriptPrecaución: Al igual que con Ajax y con otras aplicaciones que se ejecutan en el cliente, el acceso a recursos que se encuentren en un servidor distinto al en que se descarga la aplicación flex, esta prohibido. Las reglas para acceso a recursos de un proveedor externo están restringidos por motivos de seguridad. Sin embargo una manera de evitar este problema, es utilizando un "proxy". Por ejemplo (un poco cavernicola...) tengo mi aplicacion flex en miserver.com que lee los feeds de un RSS localizado en CNN.com, puedo crear un archivo en mi servidor (el proxy) php, jsp, asp, o lo que quiera que se encargue de leer el contenido en CNN.com y se lo devuelva a mi flex...
destination ==> Direccion del recurso que se quiere accesar. Puede ser incluso un archivo XML directamente
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolver el script login.php (en este ejemplo)
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)
Todavía no hemos invocado a la pagina, solo tenemos la definicion del servicio... Esta definicion se puede hacer tambien por actionscript.
Continuamos con el ejemplo:
<mx:script>
<!--[CDATA[
//Funcion que invocara el servicio
public function invocarLogin():void {
//Uso de Token
var call:AsyncToken = MyService.send();
//Hasta aqui se hace la invocacion a la página
call.marker = "login";
}
//Manejo de resultado
private function resultHandler(event:ResultEvent):void {
var call:object = event.token
if (call.marker == "login") {
//manipular informacion a través de: event.result;
trace(event.result) //imprime el resultado enviao por la pagina
}
}
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void {
Alert.show(event.fault);
}
]]-->
</mx:script>
<mx:remoteobject id="ro_tasklist" destination="TasklistService" result="onROResult(event)" fault="onROFault(event)" showbusycursor="true">
</mx:remoteobject>
RemoteObject: Mi favorito....este es definitivamentelo que hizo que me enamorara del Flex. Es totalmente RPC (remote procedure calls). Funciona en palabras simples asi:
Se tiene un backend creado en X lenguaje, en servidor se tiene una configuración especial para ese lenguaje y el Flex a través de esa configuración puede acceder a los métodos de las clases definidas en la configuración, pasando objetos como parametros y recibiendo objetos como resultados (literalmente objetos, nada de XML ni eso). Esto a través del protocolo AMF, que lo que haces serializar los objetos y mandarlos sea al servidor o al cliente para su respectiva deserialiazación y manipulación. El AMF serializa estos objetos en formato binario, osea es mucho más rápido (mucho más y sino lo cree, corra este ejemplo de James Ward: http://www.jamesward.org/blazebench/) y los manda encapsulados y comprimidos en un metodo POST por http (no teniendo problemas con proxies ni firewalls). No tienen que ser solamente un objeto a la vez, puede enviar colecciones de objetos (Arrays, listas, etc)
Algo bueno es que acaba de ser abierto por Adobe, lo que permitirá que otras personas intenten mejorarlo o darle nuevas aplicaciones...
RemoteObject es asincronimo tambien y hay que manejar tambien el Resultado o la Falla como en el HTTP Service.
Inicialmente funcionaban solamente con Java y ColdFusion (adobe provee librerias para configurar los servicios) sin embargo ya existen las librerias necesarias para configurar en otros lenguajes, ejemplo PHP --> amfphp, Ruby --> rubyamf, WEBORB, AMF.NET --> .NET entre otros.
Ejemplo:
Suponga que tenga una aplicación que tiene un metodo para crear usuarios llamado creaUsuario y que recibe un parametro de tipo Usuario (una clase) con nombre, username y password.
En actionscript, define su clase llamada Usuario también, con las propiedades nombre, username y password, esta clase es un mapeo de la clase Usuario en el server.
Algo asi:
package com.sitio.clases
{
//RemoteClass especifica a que clase en el server va a asemejarse esta. Apunta al mismo folder donde se encuentra la clase pero en el server.
[RemoteClass (alias="com.sitio.clases.Usuario")]
public class Usuario
{
public var nombre:String;
public var username:String;
public var password:String;
}
}
En el MXML (o en Actionscript tambien) se definira el RemoteObject
<mx:remoteobject id="ro_usuario" destination="ServicioEnServidor" result="resultHandler(event)" fault="faultHandler(event)" showbusycursor="true">
</mx:remoteobject>
Esto es:
id ==> Nombre con que se manejara el servicio en el MXML y en el ActionscriptAdemás en su aplicacion tiene un boton, que cuando sera presionado invocara a una funcion que preprara el usuario e invocara el metodo en el server:
destination ==> Nombre del Servicio o Clase que se configuro en el servidor para ser accesado por el Flex
result ==> nombre de la función en actionscript que se encargara de manipular la información que devolvera el método
fault ==> nombre de la función en actionscript que se encargara en caso de que el llamado falle, de hacer lo que el programador desee (mostrar mensaje o lo que sea)
showBusyCursor ==> Muestra un cursor con un relojito, mientras se hace el request...mas estetico que otra cosa
Todavía no hemos invocado al metodo, solo tenemos la definicion del remote object... Esta definicion se puede hacer tambien por actionscript.
<mx:button label="Add Item" id="submit" click="enviarForm()"/>
El Script:
<mx:script>
<!--[CDATA[
//Funcion que invocara el servicio, ejecutada cuando se apreta boton
public function enviarForm():void {
//Creacion de un objeto en AS3 de tipo usuario, que sera transmitido al server
var usuario:User = new Usuario();
usuario.nombre = "Mi Nombre";
usuario.username = "username";
usuario.password = "password";
//Uso de Token
var call:AsyncToken = ro_usuario.creaUsuario(usuario);
//Hasta aqui se hace la invocacion al metodo, pasandose de parametro el usuario creado
call.marker = "crearusuario";
}
//Manejo de resultado
private function resultHandler(event:ResultEvent):void {
var call:object = event.token
if (call.marker == "crearusuario") {
//manipular informacion a través de: event.result;
trace(event.result) //imprime el resultado del metodo
}
}
//Manejo en caso de falla
private function faultHandler(event:FaultEvent):void {
Alert.show(event.fault);
}
]]-->
</mx:script>
De verdad.. si está pensando en iniciar una aplicación en Flex con acceso a datos en el servidor, considere seriamente esta opción pues es mucho más facil que las demás...
WEBService: Permite acceder a información por medio de SOAP. Utiliza la especificación WSDL 1.1. Este método en realidad no lo he usado. Sin embargo está disponible y funciona igualmente con llamadas asincrónimas, haciendo que el programador maneje las funciones de resultado y de falla igual como el HTTP Service. Existen ya varias aplicaciones que utilizan de este medio, por ejemplo Yahoo ofrece varios de sus servicios para desarrolladores en Flex por medio de Web Services, como en los mapas o el clima: http://developer.yahoo.com/flash/astra-webapis/ (ellos "wrappean" los llamados a los servicios desde sus librerías)
Esto por ahora en cuanto a interaccion con datos...
Saludos
domingo, 14 de octubre de 2007
Qué tan bueno es el Ajax...?
Como dijo Carlos Zumbado en la última reunión del Grupo de Usuarios de Flash en Costa Rica: "Ajax funciona excelentemente para limpiar baños y lavatorios... :-)"
Ya en lo serio, AJAX ha ganado mucha fama ultimamente y en lo personal pienso que debido a la gran cantidad de desarrolladores o diseñadores que por ver un nombre en una revista piensan que será la Panacea para todos sus proyectos.
Si bien es cierto se han desarrollado cosas muy interesantes como los mapas de Google, Google Suggest y mi favorito: Gmail que tienen sus interfaces completamente basadas en la funcionalidad que provee AJAX, no funcionan completamente bien con todos los browsers. Ejemplo de eso es la funcionalidad de Gmail en Safari, que es completamente reducida para los usuarios del browser de la Mac (o por lo menos en la mia...aunque usando Safari en Win tampoco funciona)
Veamos un poco del transfondo de AJAX: su nombre viene de Asynchronous JavaScript and XML y su mayor fortaleza es la de poder intercambiar informacion con un servidor desde un codigo en Javascript sin tener que refrescar la pagina y sin que el cliente se de cuenta, haciendo que la experiencia que viva el cliente sea en tiempo real. Todo esto por medio del objeto XMLHttpRequest que es el encargado de realizar el intercambio de informacion entre la aplicacion y el servidor y como dije anteriormente sin refrescar la página completamente.
El Ajax en sí no es ningún lenguaje de programación definido, sino una serie de tecnicas (como el llamado de XML dinamico, DHTML, etc) y que utiliza el "lenguaje" Javascript, que en lo personal no me agrada mucho por varias razones entre las que puedo citar que no es compilado sino interpretado, no es fuerte con los tipos de datos, no hay un estándar de definición como con otros lenguajes, etc.
Como programador en ambiente web he escuchado y he experimentado que muchas veces como cierto código de Javascript funciona bien para X browser, pero no funcione igual para Y browser. Y eso - que a mi gusto es la mayor debilidad de esta tecnología- es debido a que los distintos fabricantes de browsers no han podido ponerse de acuerdo y formalizar un API de objetos y funciones accesibles al programador, que esté estandarizado e implementado en todos los browsers y que faciliten al programador el desarrollo de codigos sin tener que preocuparse si funcionara en cada uno de los browsers o no.
Este mismo problema se presenta a la hora de trabajar con AJAX. Siempre se presentaran problemas de funcionamiento entre las distintas plataformas que obligan al programador
escribir mas lineas de codigo para validar el tipo de browser y revisar si un metodo existe o no existe para un browser especifico.
Parece que el equipo de trabajo de Google pasó por este problema y decidió hacerle la vida más facil, sobre todo a los programadores de JAVA. Lanzó hace unos varios meses un Toolkit con un API con métodos y controles o widgets, que ofrece a los desarrolladores familiarizados con Java, la escritura de algún codigo en java y posteriormente su traducción al javascript y la correcta validación para que corra en la mayoría de browsers. Desde clases de java, se hara la creación de los distintos widgets o controles y su respectiva interacción con el cliente. Tambien se harán el llamado a recursos del servidor, que en un principio serán logrados por RCP y que posteriormente serán traducidos por el mismo toolkit al javascript listo para ser usado.
Su integracion con los IDEs mas usados como Eclipse es sencilla y permite probar las aplicaciones de dos formas, desde el IDE o en desde un browser con un mecanismo que levanta la aplicacion como si fuera una verdadera aplicación web hosteada en un servidor web.
Lo mas interesante de todo, es que el Toolkit al final generará codigo javascript que podrá ser utilizado (según dicen) en cualquier browser, sin necesidad de que el desarrollador meta mano en ello ni se reviente la cabeza en buscar metodos que sean utilizables y aceptados por todos los browsers porque el toolkit lo hara automaticamente.
Para los no "javeros", existen muchos otras herramientas que facilitan el uso del Ajax sin necesidad de usar el Toolkit de Google y sin saber Java, entre ellos Backbase que por cierto ya he usado y ofrece algunas cosas interesantes.
Sin embargo queda en mi la duda de que tan bueno será todo esto... Las aplicaciones desarrolladas, especialmente por Google son fantásticas pero aún queda algo en mí que no me permite aceptar esta tendencia al 100%, porque aunque es muy útil (porque verdaderamente lo es...) no es tan fácil de desarrollar como se quisiera.
En cambio, hace unos meses ingrese al mundo del Flex de Adobe, y aunque no soy un experto como algunos que hay por aquí (y Dios sabe que quisiera llegar al nivel de ellos) lo poco que he visto y que he aprendido y utilizado ha hecho que me entren de nuevo las ganas de programar...
Ya estaba cansado de aplicaciones WEB planas, cansado de añadir y añadir capas y capas entre las aplicaciones, cansado de crear aplicaciones en el server o herramientas de desktop en el super rígido Swing y mucho más de las aplicaciones de líneas de comando.
Flex vino a traerme buenos recuerdos de mi época con Visual Basic 6.0, el manejo de eventos, añadir botones, imagenes a un formulario, integrar eventos con objetos, dibujar una pantalla en un papel y que la gente te diga si le gusta o no... Además cuenta con un gran lenguaje para programar en el, como lo es el Actionscript 3.0 que ya es un lenguaje robusto, bien orientado a objetos, con excelente manejo del XML, expresiones regulares y cuanta cosa uno se pueda imaginar en un lenguaje de verdad, este lo tiene. Además se integra excelente con el MXML (para diseño más fácil de la parte gráfica) y el Flex es open source, lo cual permite meterse hasta lo mas profundo del lenguaje, ver definiciones y hasta si se es muy bicho modificarlo...
Otras cosas que me gustan son: el IDE para desarrollo está basado en Eclipse, lo cual es un plus si se es un desarrollador en Java que ha utilizado el IDE ya que estas completamente familiarizado. También el llamado de procedimientos remotos, por medio de Remote Objects, Data Services, Web Services o Servicios tipo Rest. Esto último es demasiado útil, sobretodo si se desarrolla un backend en el lenguaje favorito (en mi caso Java, pero sirve con PHP, Cold Fusion y hasta .Net) y el front-end es una aplicación fresa y dinámica en Flex y sobre todo eso y para rematar, las aplicaciones corren sobre el Flash player, algo estandarizado, no andan varias versiones del player hechas por distintas empresas por ahi y que implementen ciertos métodos en unas y otros en otras. Es algo más estable y serio, además que la penetración del Flash Player es demasiado alta, casi en un 93% de las computadoras del mundo...
Pero a pesar de todo lo que el Flex pueda proveer o lo que AJAX pueda ofrecer, lo más importante para el desarrollo de un buen sitio web, no será el lenguaje en que se implemente (aunque definitivamente ayudará), sino el diseño(y no me refiero solo al diseño gráfico) que se haga previamente. Como dice Alan Cooper en su libro About Face 3.0, "diseñar un producto que vaya a cumplir con las metas del usuario final, ni más cosas ni menos cosas..." (palabras más, palabras menos)
Ya en lo serio, AJAX ha ganado mucha fama ultimamente y en lo personal pienso que debido a la gran cantidad de desarrolladores o diseñadores que por ver un nombre en una revista piensan que será la Panacea para todos sus proyectos.
Si bien es cierto se han desarrollado cosas muy interesantes como los mapas de Google, Google Suggest y mi favorito: Gmail que tienen sus interfaces completamente basadas en la funcionalidad que provee AJAX, no funcionan completamente bien con todos los browsers. Ejemplo de eso es la funcionalidad de Gmail en Safari, que es completamente reducida para los usuarios del browser de la Mac (o por lo menos en la mia...aunque usando Safari en Win tampoco funciona)
Veamos un poco del transfondo de AJAX: su nombre viene de Asynchronous JavaScript and XML y su mayor fortaleza es la de poder intercambiar informacion con un servidor desde un codigo en Javascript sin tener que refrescar la pagina y sin que el cliente se de cuenta, haciendo que la experiencia que viva el cliente sea en tiempo real. Todo esto por medio del objeto XMLHttpRequest que es el encargado de realizar el intercambio de informacion entre la aplicacion y el servidor y como dije anteriormente sin refrescar la página completamente.
El Ajax en sí no es ningún lenguaje de programación definido, sino una serie de tecnicas (como el llamado de XML dinamico, DHTML, etc) y que utiliza el "lenguaje" Javascript, que en lo personal no me agrada mucho por varias razones entre las que puedo citar que no es compilado sino interpretado, no es fuerte con los tipos de datos, no hay un estándar de definición como con otros lenguajes, etc.
Como programador en ambiente web he escuchado y he experimentado que muchas veces como cierto código de Javascript funciona bien para X browser, pero no funcione igual para Y browser. Y eso - que a mi gusto es la mayor debilidad de esta tecnología- es debido a que los distintos fabricantes de browsers no han podido ponerse de acuerdo y formalizar un API de objetos y funciones accesibles al programador, que esté estandarizado e implementado en todos los browsers y que faciliten al programador el desarrollo de codigos sin tener que preocuparse si funcionara en cada uno de los browsers o no.
Este mismo problema se presenta a la hora de trabajar con AJAX. Siempre se presentaran problemas de funcionamiento entre las distintas plataformas que obligan al programador
escribir mas lineas de codigo para validar el tipo de browser y revisar si un metodo existe o no existe para un browser especifico.
Parece que el equipo de trabajo de Google pasó por este problema y decidió hacerle la vida más facil, sobre todo a los programadores de JAVA. Lanzó hace unos varios meses un Toolkit con un API con métodos y controles o widgets, que ofrece a los desarrolladores familiarizados con Java, la escritura de algún codigo en java y posteriormente su traducción al javascript y la correcta validación para que corra en la mayoría de browsers. Desde clases de java, se hara la creación de los distintos widgets o controles y su respectiva interacción con el cliente. Tambien se harán el llamado a recursos del servidor, que en un principio serán logrados por RCP y que posteriormente serán traducidos por el mismo toolkit al javascript listo para ser usado.
Su integracion con los IDEs mas usados como Eclipse es sencilla y permite probar las aplicaciones de dos formas, desde el IDE o en desde un browser con un mecanismo que levanta la aplicacion como si fuera una verdadera aplicación web hosteada en un servidor web.
Lo mas interesante de todo, es que el Toolkit al final generará codigo javascript que podrá ser utilizado (según dicen) en cualquier browser, sin necesidad de que el desarrollador meta mano en ello ni se reviente la cabeza en buscar metodos que sean utilizables y aceptados por todos los browsers porque el toolkit lo hara automaticamente.
Para los no "javeros", existen muchos otras herramientas que facilitan el uso del Ajax sin necesidad de usar el Toolkit de Google y sin saber Java, entre ellos Backbase que por cierto ya he usado y ofrece algunas cosas interesantes.
Sin embargo queda en mi la duda de que tan bueno será todo esto... Las aplicaciones desarrolladas, especialmente por Google son fantásticas pero aún queda algo en mí que no me permite aceptar esta tendencia al 100%, porque aunque es muy útil (porque verdaderamente lo es...) no es tan fácil de desarrollar como se quisiera.
En cambio, hace unos meses ingrese al mundo del Flex de Adobe, y aunque no soy un experto como algunos que hay por aquí (y Dios sabe que quisiera llegar al nivel de ellos) lo poco que he visto y que he aprendido y utilizado ha hecho que me entren de nuevo las ganas de programar...
Ya estaba cansado de aplicaciones WEB planas, cansado de añadir y añadir capas y capas entre las aplicaciones, cansado de crear aplicaciones en el server o herramientas de desktop en el super rígido Swing y mucho más de las aplicaciones de líneas de comando.
Flex vino a traerme buenos recuerdos de mi época con Visual Basic 6.0, el manejo de eventos, añadir botones, imagenes a un formulario, integrar eventos con objetos, dibujar una pantalla en un papel y que la gente te diga si le gusta o no... Además cuenta con un gran lenguaje para programar en el, como lo es el Actionscript 3.0 que ya es un lenguaje robusto, bien orientado a objetos, con excelente manejo del XML, expresiones regulares y cuanta cosa uno se pueda imaginar en un lenguaje de verdad, este lo tiene. Además se integra excelente con el MXML (para diseño más fácil de la parte gráfica) y el Flex es open source, lo cual permite meterse hasta lo mas profundo del lenguaje, ver definiciones y hasta si se es muy bicho modificarlo...
Otras cosas que me gustan son: el IDE para desarrollo está basado en Eclipse, lo cual es un plus si se es un desarrollador en Java que ha utilizado el IDE ya que estas completamente familiarizado. También el llamado de procedimientos remotos, por medio de Remote Objects, Data Services, Web Services o Servicios tipo Rest. Esto último es demasiado útil, sobretodo si se desarrolla un backend en el lenguaje favorito (en mi caso Java, pero sirve con PHP, Cold Fusion y hasta .Net) y el front-end es una aplicación fresa y dinámica en Flex y sobre todo eso y para rematar, las aplicaciones corren sobre el Flash player, algo estandarizado, no andan varias versiones del player hechas por distintas empresas por ahi y que implementen ciertos métodos en unas y otros en otras. Es algo más estable y serio, además que la penetración del Flash Player es demasiado alta, casi en un 93% de las computadoras del mundo...
Pero a pesar de todo lo que el Flex pueda proveer o lo que AJAX pueda ofrecer, lo más importante para el desarrollo de un buen sitio web, no será el lenguaje en que se implemente (aunque definitivamente ayudará), sino el diseño(y no me refiero solo al diseño gráfico) que se haga previamente. Como dice Alan Cooper en su libro About Face 3.0, "diseñar un producto que vaya a cumplir con las metas del usuario final, ni más cosas ni menos cosas..." (palabras más, palabras menos)
Suscribirse a:
Entradas (Atom)
