albloguera

A día de hoy yo no tendría duda sobre cual opción elegir, opción que no tiene que ser mejor que la otra. Realmente, yo enfocaría el dilema mas bien desde el punto de vista de aplicación web AJAX (orientada al servicio), o aplicación web convencional (.net por supuesto), con sus postbacks (o callbacks) y sus Update Panels. (Debería de estar penalizado el uso del control Update Panel )

Ajax Control Toolkit

Esta opción nos deja en el ámbito de una aplicación web .Net tradicional con controles de servidor, por lo que seguramente tendremos el grueso de la aplicación en el servidor. Con esto no quiero decir que no sea posible tener lógica en cliente, pero si que resulta bastante engorroso trabajar con los controles del ajax control tolkit con javascript. Por otro lado no debemos olvidar que son controles de servidor, y que son muy fáciles de usar, pero que cuando se complica el desarrollo y la web,  no se por qué, pero el trabajo se complica.  Otro punto es el peso de las librerías, puf, te echan para atrás. Y un punto no menos importante, si por ejemplo tenemos que hacer una modificación de un Extender, digamos por ejemplo el AutoCcomplete, tendremos que generar un nuevo build y añadir la nueva referencia, y rezar por tener problemas de versiones a la hora de realizar el deploy en el servidor. A modo de anectdota, mencionar que un proyecto en el que estuve trabajando, en cual teniamos un Auto Complete Extender customizado,  tuvimos problemas de referencias cruzadas entre versiones de librerias,  y  con el timestamp del build generado del Extender con la fecha del servidor. Hora del Build X , hora del Servidor de despliegue X-6. Solución, cambiar la hora a la maquina de build y realizar un nuevo build con un timestamp de fecha menor que la hora del servidor web. 

Leer el artículo completo »

La mayoría de las veces cuando se define la arquitectura de una aplicación web solo se tiene en cuenta la parte servidor, como si el lado cliente no fuera importante o no existiera. Es verdad que en cliente disponemos de un lenguaje interpretado (no compilado), lo cual hace si cabe un poquito mas complicado el desarrollo,  al no disponer de las ventajas del pre compilado que nos ofrece Visual Studio. Además,  el ordenado del código debería ser un factor importante, ya que la tendencia es tener  un único fichero o script de código Javascritp, y esto siempre  comienza siendo unas pocas líneas para unas cuantas validaciones y va creciendo paulatinamente debido a la no planificación de la arquitectura en cliente o a nuevos requerimientos.

Atajar esto no es fácil, y el artículo no define ningún modelo de arquitectura, pero si unas cuantas pautas de buena conducta que nos ayuden a tener un condigo algo mas limpio y ordenado.

Leer el artículo completo »

Que divertido es Javascript, y como echaba de menos un proyecto como el de ahora, casi todo en cliente, pero a pelo sin esas maravillosas facilidades que aporta Silverlight...., bueno algunas si, haciendo uso de Framework de AJAX de Microsot. El contenido de este Post es el típico conocimiento que en mi caso nunca me acuerdo y tengo que echar manos de algun proyecto para recuperarlo. Nunca Mais

El código creo que no necesita explicación. Simplemente obtenemos los valores X e Y de elemento con Scroll que queremos persistir después del postback y lo guardamos, para posteriormente, volverlos a establecer. Para ello,   añadimos un manejador de eventos para antes y después del postback asíncrono, de manera que cada uno de ellos ejecute la función que le especificamos.