Adobe creará un Photoshop Online

En esta era de las aplicaciones online, Adobe ha decidido crear una versión web de uno de sus programas más populares, el Adobe Photoshop.Según comentan en ZDNet, este movimiento sería el inicio de una estrategia para crear servicios online mantenidos con publicidad que complementen a sus productos existentes y aumenten el alcance de la empresa en el mercado.

Por supuesto, parte de la idea es lograr ser los primeros (y convertirse en estándares) en las distintas áreas abarcadas por los programas de Adobe, ante una enorme competencia de las grandes empresas como Google, Yahoo y Microsoft que no paran de lanzar nuevas aplicaciones online; pero siempre remarcando que estos servicios son versiones simplificadas de sus productos.

Soy Programador

Un poco de Humor para todos aquellos que les gusta desarrollar y para todos aquellos que tienen un gran Humor,Aunque esta en ingles me pareció muy gracioso.Espero que les guste.

Aunque sea una imagen me parece que es nuestra realidad .

iframe o AJAX?

Básicamente los problemas que tienen que enfrentar los proyectos web, son los mismos para todos los proyectos, frente a una aplicación Windows. El manejo de variables en la aplicación (sesión, cache, viewstate, ..), falta de formularios de dialogo, compartir variables entre ventanas, entre otros temas que son conocidos. Uno de los temas es el “refresco de pantalla”, o postback al servidor, y que va de cara con el usuario final. Que pasa si tienes combos dependientes que se cargan unos a otros, por cada uno se estaría haciendo un postback, son controles pequeños que a veces no merece la pena hacer un refresco de toda la página desde la vista del usuario final, en un gridView o listas de datos podrían tolerar, pero cambiar un combo?, no a muchos usuarios finales les gusta. Si van a dejar sus appWindows por aplicaciones Web, tiene que ser algo mejor no?

Ahora en cuanto al manejo de refresco de pantalla, desde hace años se viene implementando tecnologías para evitar estos refrescos.En este post vamos a resumir una comparación entre iframe y ajax, usando las implementaciones básicas y pre-construidas, no haciendo cosas marcianas.

• Ajax, es multihilo, en el sentido que pueden haber procesando varios pedidos a la vez.
• Iframe, tiene soporte del historial para su navegación, es decir que puedes retrodecer a tu vista anterior, en cambio en ajax, no. Aunque con ASP.NET AJAX hay una alternativa para lograr esto, pero es un control de terceros.
• Iframe, tener cross-site scripting, aunque depende si tu tienes control sobre ambos dominios, como se menciona en el artículo original.
• Ajax, maneja estado, con ajax podemos mostrar un indicador de progreso del pedido actual y que el usuario final no vea esa pantalla blanca de parpadeo, que no le dice nada.

Y aunque con Iframe puedes mejorar la experiencia del usuario durante de la navegación, las páginas cuerpo seguirán haciendo postback, es decir puedes conversar tu menú y head, pero si haces un postback en la página cuerpo, igual verás el refresco de la pantalla aunque sólo de esa frame. Ahora, hablando de ASP.NET AJAX, nosotros con el UpdatePanel podemos hacer mejor las cosas, tampoco vamos a colocar un iframe por cada control que tengamos, pero con el UpdatePanel si podemos hacer eso y sólo usarlo donde lo necesitemos, además que podemos mostrar un indicador del estado del pedido al usuario, usando el control UpdateProgress.

Pero como dice el autor en su artículo, todo depende del escenario, no pretendan implementar sólo una opción en todos sus escenarios. Por ejemplo Google Maps usa iframes, mientras que Google suggest usa AJAX.

Corríjanme si me equivoco, pero otra cosa a tener en cuenta es que el elemento iframe no es valido en el xhtml 1.1, no directamente, por que vi que había en un foro un post de un iframe válido para xhtml 1.1.

Artículos relacionados:

• AJAX: XMLHttpRequest Vs. iFrames
• XMLHttpRequest Vs. iFrames
• PHPClasses 2.0 Beta, AJAX XMLHttpRequest x IFrame
• PHPClasses.org Chooses iFrames over Ajax?
• No es AJAX todo lo que reluce
• Iframes vs. Frames
• Ventajas e inconvenientes del uso de frames

ASP.NET AJAX, haciendo historia

ASP.NET Ajax es un nuevo framework de Microsoft para crear aplicaciones web más sofisticadas aprovechando el “lado-cliente” y fue liberado en Enero pasado. Hay que tener en cuenta que ASP.NET 2.0 es un framework del lado-servidor, es decir, cada vez que se requería cierta funcionalidad de ASP.NET 2.0 se tenía que hacer un POST al servidor para ejecutar el código lo cual causaba un “refresh” de la pagina entera, algo que se intenta evitar, dependiendo del caso, con la introducción de este nuevo actor en el escenario del desarrollo web, ósea ASP.NET Ajax, con el principal beneficio ahora de no depender de un Browser en particular (digamos IE) sino que es cross-platform y cross-browser.
En lugar de comenzar a hablar de la arquitectura de ASP.NET Ajax y mostrar ejemplos de código, prefiero hablar de las cosas que conoci y utilice antes para hacer Aplicaciones Web del lado-cliente más ricas.
Por ejemplo, Remote Scripting (1998) se utilizaba script del lado cliente para comunicarse con un applet de java el cual mediante un socket enviaba una solicitud hacia un URL remoto que era una página ASP que representaba la capa-servidor de Remote Scripting, en este caso el valor de retorno era un string que era procesado en el cliente, haciendo una actualización dinámica del contenido mediante scripting.

Casi por la misma época se comenzó a utilizar Remote Data Services (RDS) que, al igual que Remote Scripting, tenia un componente cliente (proxy) y un componente servidor (stub) solo que todo esto estaba basado en COM sobre HTTP. Utilizando Script desde una pagina HTML podía conectarme al servidor y hacer consultas a la base de datos.
Recuerdo haber utilizado esto junto con los famosos (por aquella época) “Data Islands” que se creaban en base a un contenido XML y utilizando un Data Source Object (DSO) se podría presentar en una pagina contenido con distintos filtros u ordenamientos sin necesidad de hacer llamadas adicionales al servidor eliminando la “recarga” de la pagina.
Si les interesa saber detalles de cómo funcionaba todo esto puede ver Data Binding Architecture.

En la década del 2000 aparecerían los DHTML Behaviors. Usando un tipo especial de behavior, el Web Service DHTML Behavior (webservice.htc) se podía hacer una invocación a métodos remotos vía el protocolo SOAP (requerían de IE 5.0 o posterior)
Si desean ver un ejemplo de este Behavior haga click en Consuming a Web Service from an HTML Page.

Luego tendríamos al objeto XmlHttpRequest, este objeto fue desarrollado originalmente por Microsoft como parte de Outlook Web Access 2000, y ha estado disponible desde Internet Explorer 5.0, siendo accesible via JavaScript, VBScript y otros lenguajes soportados por navegadores IE. Se usa para transferir y manipular datos XML hacia y desde el navegador web, estableciéndose un canal de comunicación independiente entre el lado-cliente, de la pagina web, y el servidor.
Desde el 2002, otros navegadores comenzaron a tener sus propias implementaciones compatibles con el XmlHttpRequest, por ejemplo Mozilla, Safari, Opera, etc. El objeto XMLHttpRequest es una parte fundamental de la técnica de desarrollo web conocida como AJAX (Asynchronous JavaScript And XML) , y es usada en muchos sitios web para implementar aplicaciones dinámicas e interactivas como el servicio Gmail de Google, Meebo, Virtual Earth de Microsoft, y los mapas de MapQuest..
Finalmente el consorcio Web, entidad que norma los estándares internet, publico una especificación del objeto XmlHttpRequest para ayudar a mejorar y asegurar la inteoperabilidad del código en las diferentes plataformas Web.
Cuando salió ASP.NET 2.0, este vino con una API denominada ASP.NET Script Callback que proporcionaba la habilidad de ejecutar llamadas asíncronas sin dejar la pagina actual; sin embargo el modelo de programación no es muy completo para tareas complejas, además que el código no es muy fácil de leer y mantener para desarrolladores sin experiencia avanzada.
El equipo de producto de ASP.NET comienza, entonces, a trabajar en un framework como extensión de ASP.NET 2.0 que permita a los desarrolladores crear, de una manera más sencilla, aplicaciones Web interactivas tomando ventaja de las características del browser y el servidor, es así como comienza la historia de ASP.NET “Atlas”, hoy conocido como ASP.NET Ajax.

Unas de las cosas que me encantan de las tecnologías Microsoft es el siempre están a la vanguardia, innovando, muchas veces acusados de “copiar” ideas, aunque creo que en el caso del objeto XmlHttpRequest no pueden decir aquello. Yo lo veo de otro modo, lo más importante es como todo eso contribuye a lograr soluciones de valor para las empresas, reduciendo costos y llegando al mercado más rápidamente.