En esta ocasión quiero hablar de un efecto quizá poco conocido pero importante del modo en que procesa el código JavaScript. En JavaScript existen variables globales, las cuales tienen sus ventajas en un lenguaje como este, pero también están llenas de peligros, y variables locales, cuyo ámbito se circunscribe exclusivamente a las funciones en las que se declaran. Podemos utilizar una variable global desde dentro de una función cualquiera, ya que están accesibles desde cualquier lugar de la página, por ejemplo: //Variable global var name = "Jose"; function HelloWorld(){   alert(name); } HelloWorld(); Al hacer esto saltará el mensaje con el nombre que hay en la variable. Bastante obvio. Bien, pero ¿qué pasa si definimos una variable con el mismo nombre dentro de la función?: //Variable global var name = "Jose"; function HelloWorld(){   //Variable local   var name = "P... [Más]

Esta época, entre otras muchas otras cosas, estoy trabajando en un nuevo libro de JavaScript que verá la luz en los próximos meses. Uno de los capítulos se centra en la depuración de código JavaScript usando las herramientas que ofrecen de serie los navegadores. Entre éstas, una muy interesante es el “Profiler”, disponible tanto en Chrome como en Internet Explorer, y en Firefox a través de Firebug. El profiler tiene varias sub-herramientas, como el analizador de tiempos de ejecución que nos permite obtener información detallada y estadísticas sobre los tiempos de ejecución de nuestra página, y sobre sus consumos de memoria, identificando así posibles cuellos de botella, funciones poco optimizadas, etc... E incluso bugs en el motor de renderizado de las páginas (Se han dado casos). En el libro me estoy centrando en las herramientas de desarrollo de Google Chrome, y... [Más]

En septiembre de 2009 Krasis Press lanzó al mercado mi libro “Tecnologías ASP.NET 4.0 (Saltando desde la versión 2.0)”. Fue un libro que se adelantaba en varios meses a la futura versión de la plataforma y el entorno de desarrollo. En el momento de escribirlo, en Julio de 2009, las últimas noticias sobre el lanzamiento del producto apuntaban a Octubre de 2009, y que muy pocos cambios iban a aparecer en la versión final. Por ello, a pocos meses vista de esa versión definitiva, aún con la Beta 1 de la plataforma, nos decidimos a lanzarlo al mercado. Trabajar con las Betas de Microsoft tiene muchas ventajas, pues te permite estar al cabo de la calle y adelantarte al mercado en las tecnologías que vendrán. Pero también tiene algunos inconvenientes, entre ellos que puede haber cambios de última hora que echen a perder el tiempo invertido. Al final, la versión definitiva de .NET 4.0 se fue retrasando y apareció el 12 de Abril de 2010. Este mayor ciclo de vida para las versiones previas del ... [Más]

Un efecto bastante indeseable en una página web es que los usuarios puedan enviar al servidor [Más]

NOTA: este post está escrito hace muchos años y está totalmente obsoleto. En la [Más]

En mi anterior post hablé sobre el concepto de clausuras en Java_Script (JS a partir de ahora [Más]

JavaScript es un lenguaje de programación que, a pesar de los años que tiene, cada vez [Más]

Los temporizadores (Timer) de las extensiones de AJAX para ASP.NET son muy útiles. Nos permiten ejecutar una determinada tarea cada cierto tiempo, provocando postbacks de la página  (tanto completos, como parciales) en intervalos regulares. Un único Timer colocado en la página puede conseguir que se refresquen todos los UpdatePanels disponibles o cada uno de manera individual. Lo habitual es colocarlos en la página y olvidarnos de ellos. Pero ¿qué pasa si queremos poder pararlos y activarlos a voluntad? La cosa tiene más complicación de la que parece a simple vista. Lo primero que se nos ocurre a cualquiera es que, dado que tiene una propiedad Enabled para activarlo y desactivarlo bastará con establecerla en False para conseguir el efecto deseado. Si lo hacemos desde un postback asíncrono enviado desde dentro de un UpdatePanel, ni se notará en la página, ¿no?. Lo malo de esta idea es que, simplemente, no funciona. El motivo es que en un refresco parcial de página, aunque s... [Más]

En mis tres anteriores post me centré en JSONP, la solución soportada actualmente por cualquier navegador para hacer llamadas a servicios JSON ubicados en dominios diferentes al actual (ver índice al final de este post). Ahora, tras quince dís sin tiempo para nada (con Codecamp y TTT para Microsoft por el medio), por fin saco un par de horitas para escribir esta últma parte de la serie, dedicada a los estándares. Las limitaciones del objeto XmlHttpRequest a la hora de hacer peticiones desde el navegador a páginas y recursos ubicados en otros dominios son de sobra conocidas. Ello ha hecho que los programadores busquen atajos para conseguir esta funcionalidad y saltarse esta barrera. Hasta ahora hemos visto cómo JSONP nos permite conseguirlo gracias al uso de la etiqueta <script>, y cómo se le puede sacar partido en muchas ocasiones. No obstante esta técnica tiene bastantes limitaciones: · Sólo ... [Más]

En mis dos anteriores post (busca los enlaces al final de este post y leetelos antes si no lo has hecho) he estado hablando sobre la técnica de JSONP para consumo remoto de datos JSON entre dominios, algo a priori prohibido por el modelo de seguridad del navegador. Anteriormente comentaba que JSONP podría tener ciertos problemas de seguridad, y que para evitarlos en ASP.NET 3.5 se habían introducido cambios para paliarlos que rompían la compatibilidad con versiones anteriores. Voy a aclararlo ahora. El problema de seguridad tiene que ver con la obtención de acceso no autorizado a información privada que se comparte con JSON. Una de las técnicas habituales de securizar el acceso a los servicios, consiste en crear cookies encriptadas con una validez temporal limitada y asociadas a una sesión concreta. Esta técnica se utiliza de manera mayoritaria en los sitios Web actuales (como Facebook, Windows Live, o, como ya hemos visto, en la propia seguridad de ASP.NET). El problema de esta técn... [Más]