MessageBox en ASP.net. Porque no me funciona?

Esta es una de las preguntas que se ven mas a diario en los foros y grupos de noticias.

Porque no me funciona el MessageBox en ASP.net, si en una aplicación Windows si lo hace?

Este es un error de concepto en el que se puede caer fácilmente, mas, cuando se trabaja con un IDE como Visual Studio .Net 2003/2005, donde presenta una interfaz "similar" para desarrollar aplicaciones Webs, como aplicaciones Windows.

El problema esta en que debemos entender, antes de desarrollar una aplicación Web (por mas que el IDE sea muy poderoso, y el lenguaje de prestaciones extras), como funcionan las paginas Webs con contenido dinámico.

Entonces, pensemos en el funcionamiento de la web como si fueran dos personas, a las cuales la divide una pared. Una persona (el servidor), posee una cesta, y recursos (pueden ser frutas 🙂 ), de su lado. Del otro lado, la otra persona (el cliente), requiere de esos recursos que el servidor puede enviarles.

Entonces, imaginemos una situación donde el cliente (persona de un lado de la pared), le pide al servidor uno de sus recursos. El cliente le envía al servidor (de alguna forma, carta formal, avioncito de papel, etc.) por arriba de la pared la lista de cosas que quiere. Una vez el, digamos, avión de papel cruza la pared, el cliente se sienta y espera. A todo esto, el servidor, del otro lado de la muralla, estaba sentado sin hacer mucho, esperando. El avión cae en sus manos, lee que una persona, del otro lado, requiere una fruta. Como las frutas están en un árbol, entonces, el servidor se para, corta la fruta, la lava, la adorna :), la coloca en una canasta, y la arroja al otro lado de la pared. Finalmente, el servidor se sienta nuevamente y espera. El cliente, obtiene su pedido, y lo consume.

El punto de esta analogía, es que debemos entender que, entre cliente y servidor no existe conocimiento mutuo. Además, cuando uno estaba confeccionando el mensaje, el otro simplemente estaba sentado sin saber que pasaba del otro lado del muro. Finalmente, cuando el servidor termino su acción, volvió a su estado de reposo, y quedo a la espera de otra petición.

Las paginas webs trabajan, en consecuencia, de forma similar. Pensemos en un cliente (computadora), que requiere de un servidor (otra computadora), una pagina web. En este momento, el servidor simplemente busca el recursos, lo procesa, y le envía el resultado al cliente. Una vez este resultado fue entregado, el servidor se desentiende por completo del cliente. A tal punto que el servidor simplemente no tiene idea de lo que el cliente hace con este resultado.

Por este motivo, es común (por si no lo sabían), que cada vez que realizamos una acción en una pagina web (apretar un botón, seleccionar un link, etc.), la página sufra de un evento de "flash", que provoca que la pagina se recargue por completo. En esta acción, el cliente, vuelve a confeccionar un pedido y se lo envía al servidor, para que este, nuevamente, lo procese y retorne los resultados esperados.

Y que tiene que ver todo esto con mi MessageBox?

Bueno, la respuesta es muy simple. Como el servidor, una vez finalizado el procesado de los datos, y enviado estos al cliente, simplemente pierde control del código. Es mas, como no existe un control directo sobre las acciones a realizar en el cliente, este no podría, por ejemplo, capturar la acción que el usuario (en el cliente), hubiera hecho sobre la ventana del mensaje. De esta manera, el tratar de arrojar un mensaje con código ASP.net, a lo sumo, este debería asomarse (verse), en el lado de la pared del servidor, ya que este lado es el lado en el cual este (el servidor), tiene jurisdicción.

Lo que se suele hacer, para solventar este problema, es que justamente, el cliente, sea el que muestre el mensaje, y en base a las acciones realizadas por el usuario, confeccionar un nuevo "avión de papel", para enviárselo al servidor.

Otras técnicas mas avanzadas usan implementaciones de A.J.A.X. para evitar, por ejemplo, el parpadeo de la pagina. Pero no nos confundamos, aun (por mas implementaciones que hagamos) se sigue confeccionando un mensaje para ser enviado al servidor y que este reaccione con una respuesta.

Y, posiblemente, hasta que no cambie el protocolo por el cual se sostiene el web, esta situación siga siendo inmutable.


EVA

El 21 y 22 de Octubre estaré en Buenos Aires asistiendo a la EVA (www.adva.com.ar/eva)
 
Este ciclo de conferencias está dedicada a aquellos desarrolladores que están o quieren entrar en el mundo del desarrollo de video juegos.
 
Así que si alguno va, nos vemos allá.

Y después se preguntan porque…

Eso digo. Después se alarman porque el nivel de los profesionales en informática es malo, si ni siquiera las universidades tienen el nivel necesario para transmitir conocimientos de verdad.

Hoy (hace minutos), me llega un correo (SPAM), de una universidad on line. La cual, efectivamente funciona. No es necesariamente de esas que compras el diploma por Internet. Y veo muy felizmente un diplomado específico para el área de sistemas.

Horror el mío cuando entro a ver la descripción del mismo. No voy a comentar lo que pienso, pero si ellos tienen la capacidad de dar un diplomado y NI SIQUIERA saben los conceptos mínimos de lo que están hablando. No quiero saber que clase de personas saldrán después de tomar este (http://www.uvirtual.org/web/)

Debo decir que les mande un correo con mi indignación, no suelo hacer eso, simplemente les doy "palo y la bolsa", pero en este caso, primero quise advertirles.

Así que, para que quede registro histórico de este acto, copio y pego lo que vi (Por si lo modifican)

[Cito] …  Gestión de Aplicaciones Web abarca de manera práctica los lineamientos esenciales para poder implementar sitios Web profesionales de alta tecnología, teniendo como herramienta de desarrollo el Dreamweaver. Asimismo, se introduce y profundiza … aplicaciones Web y contenidos profesionales con los lenguajes script … utilizados en el mundo entero: PHP y ASP.NET.

Este programa tiene la característica innovadora de complementar los conocimientos de los lenguajes script antes mencionados con la tecnología AJAX (actualmente es la tecnología mas avanzada para la implementación de aplicaciones Web, desarrollada por GOOGLE), que es una técnica … Éstas se ejecutan en el cliente, es decir, en el navegador del usuario, y mantiene comunicación con el servidor en segundo plano. [Fin Cita]

Yo no se que más decir. 


Google Mail… cumple con lo que promete?

Sin querer politizar el tema, pero hace unos días (desde que empecé a notar el problema) el servicio de Google Mail no se esta comportando como debiera.

Correos electrónicos que no llegan a destino. Esto fácilmente comprobable cuando amigos, e incluso, yo, he enviado correos a la cuenta de google y estos no llegan.

Será que el dicho, lo barato (gratis en este caso) cuesta caro, esta empezando a hacer efecto?

Esperemos que esto haya sido solo momentáneo, porque si no….


Un poco de noticias… o no?

Posiblemente muchos de ustedes ya habrán visto tantas de las nuevas cosas que Microsoft esta lanzando con su nuevo FrameWork.net.
Entre estas, una que me llama mucho la atención; "LinQ"
Si, si. Esta bien, el concepto no es del todo nuevo, pero que lindo se lo ve (http://msdn.microsoft.com/data/ref/linq/)En breve (o sea, cuando pueda finalmente instalarlo, porque hasta ahora solo he tenido problemas con la instalación), empezaremos a hacer pruebas. Vale recalcar que la documentación es simple y clara. Pero sin probarlo, sin meter las manos adentro, es difícil de decir que uno sabe realmente del tema.

Y otra de las tantas cosas que están viendo la luz, puedo decir con mucha alegría que, por fin, algo para aquellos que vienen siguiendo el desarrollo de juegos desde hace años. Si, reconozco que no soy un desarrollador de juegos experto, y que tampoco he lanzado nada al mercado, pero bueno, un que otro PacMan he hecho. Pero, volviendo al tema, realmente hay que ver el Game Studio Express (No se porque esta manía de los express, me hace pensar en café). Este producto promete mucho, tanto por su capacidad (Desarrollo de juegos tanto para PC como XBOX), hasta por la modalidad de distribución (GRATIS, hasta donde se sabe) (http://msdn.microsoft.com/directx/XNA/default.aspx)

Una vez mas, por cuestiones de hardware (aunque este si lo instale), no pude hacer nada, porque no tengo una tarjeta de video como la gente. Creo que llego la hora de invertir un poco en fierros para no perderse de estos productos.


Tercera emisión y con regalo…

El sábado pasado (7/10/2006), como todos (los que leen este blog) saben, realizamos la tercera emisión del micro radial sobre tecnologías de la computación en la FM 107.3 (Río Tercero).

Esta vez, quería involucrar mucho mas a las personas que nos escuchan, así que decidí entregar a los organizadores, un libro. Libro obtenido de mi biblioteca (pequeña por cierto). Lamentablemente el único que tenia de tecnología genérica (Windows para usuarios finales).

Digo que es una lastima, debido a que no tengo otros libros disponibles para un publico sin conocimientos de desarrollo o de administración de sistemas.

En todo caso, grande fue la sorpresa cuando los teléfonos sonaron durante el programa, y hasta dos horas después de la finalización del mismo, de personas interesadas en participar del concurso.

Espero que la ganadora, lo este disfrutando, así como yo lo hice en su momento.


.Net y el codigo abierto

Recuero que cuando desarrollaba paginas webs en ASP 3.0, una pregunta común era la de: – Como puedo proteger el código fuente de mis páginas para que no sea "copiable?

El procedimiento era básico y simple. Con solo crear un DLL que compile la funcionalidad de nuestras paginas, nos asegurábamos que el código, especialmente la lógica de negocios, no pudiera ser modificada y/o copiada (en su código), sin nuestra autorización. 

Con la aparición de .Net, un el nuevo modelo de no registro de componentes (entre otros), muchos se confundieron, y aun se confunden, pensando que el DLL (incluso el EXE) creado por .Net es incopiable, su código fuente claro esta.

Esto, posiblemente por motivos similares al planteado anteriormente con las paginas ASP 3.0, y que, como la extensión DLL es igual a la de un Assembly, por descarte se cree que funciona de la misma forma. 

Lamentablemente, esto no es así. Microsoft, con .Net ha roto la barrera que lo tenía como el "hijo del diablo", como muchos lo llamaban, al liberar el código fuente de todas las aplicaciones que se crean con .Net. Digo "hijo del diablo" porque hasta este punto, muchos usaban a Microsoft como el ejemplo del capitalismo extremo y el egoísmo absoluto, en lo que a desarrollo de software se trataba.

Para entender esto, debemos ver que pasa después que compilamos nuestras aplicaciones. 

.Net, o los distintos compiladores de los lenguajes que trabajan con .Net, compilan el código fuente en un lenguaje intermedio, o sea, un lenguaje que no es, ni código fuente, no código de maquina (hablo como hace 15 años atrás), o sea, que no es ni nuestro código, ni un código que solo entienda Windows.

Como pueden imaginar, esto nos otorga un par de ventajas, por un lado, el código intermedio (IL, o para Microsoft, MSIL), es el mismo sin importar el lenguaje en el cual haya sido escrito. O sea, si trabajamos con VB.net, así como C#, el IL resultante es igual (o similar para algunos). Esto garantiza que sin importar el lenguaje, el resultado sea básicamente el mismo. Y por otro lado, al no ser un código encasillado en un sistema operativo, este puede ser ejecuta en mas de un sistema operativo sin problemas. Claro, siempre y cuando tengamos el motor de .Net para ese S.O. (Señores de Java, sin comentarios) 

Un ejemplo de este IL, lo pueden ver en la publicación de Generics (Mas abajo)

Entonces, sin perder el foco, el IL, entre sus características, que ya nombramos, esta la de que, sin importar el lenguaje, el resultado es el mismo, por lo que es posible afirmar que IL creado en un lenguaje, podría ser pasado a otro lenguaje. Justamente, el motor de .Net, para ejecutar una aplicación (.net), interpreta el IL, lo compila en su versión definitiva, esto es, código de maquina, y lo ejecuta. Pero, este proceso de Código Fuente, a IL, a Código de Maquina, puede ser fácilmente revertido. O sea, si tenemos un IL, lo podemos pasar a código fuente sin más. 

Para esto, pueden ver Net Reflector (http://www.aisto.com/roeder/dotnet/), el cual sirve para esto, o usar la herramienta ILDSAM, del FrameWork.net para ver el IL.

No es mi idea hacerle publicidad a Net Reflector, pero para darles una idea, este puede "traducir" IL a código fuente, como por ejemplo: VB.net, C#, J#, Delphi, etc. 

Y para que entendamos mas el asunto de código abierto, vale acotar que hasta el FrameWork (librería de clases y esas yerbas), también es accesible y visualizable en el lenguaje que mas les guste.

Entonces, como hacemos para proteger el código? No pensaran que, para aquellos que quieren seguir protegiendo sus IDEAS (mejor no digo mas, porque se arma grande…), puedan seguir haciéndolo. 

Existen herramientas que sirven para "marear", tanto al lector humano de código IL (si, con un poco de dolor de cabeza, uno, puede entender el IL), como a los lectores por software, y que no puedan descifrar el código.

Esta técnica/herramienta es la ofuscación, que del ingles y aplicado a .Net, se llama DotFuscation. No voy a entrar en detalle sobre como trabaja, para eso pueden leerlo por ustedes mismos en http://www.preemptive.com/products/dotfuscator/ 

Debemos aclarar que Visual Studio.net viene con una versión simple de esta herramienta, para aquellos que quieran empezar a usarla.

Quería tocar este tema debido a que aun existen empresas, y personas que creen que su código fuente esta seguro. No porque sea obligación proteger el código (no quiero tirarme arriba a los de open source), si no, porque existen personas que creen que así debería ser, y por consiguiente, están desparramando código fuente muy seguros de que no es así.