miércoles, 30 de marzo de 2011

window.open

Para abrir una nueva ventana en javascript tenemos disponible el método open del objeto window.

window.open(url, [name], [features], [replace])

  • url es la localización de la página que queremos mostrar.
  • name es el nombre que damos a la ventana o uno de los nombres predefinidos.
  • features en una lista de elementos separados por comas que permiten personalizar tanto la apariencia como el comportamiento de la nueva ventana.
  • replace especifica si la url que pasamos al método crea una nueva entrada en el historial o reemplaza la actual entrada. Este parámetro sólo tiene efecto si url es cargada en la misma ventana.

Un primer ejemplo sería el siguiente:

var win = window.open("http://www.google.es");

var win = window.open("http://www.google.es",”google”);

 

Aunque ambos ejemplos son sencillos, tengo que comentar que sólo Safari abrió una nueva ventana, el resto (IE, Firefox, Chrome y Opera) abrieron una nueva pestaña.

Respecto al parámetro url no hay mucho que decir (salvo que es opcional y este caso sirve para obtener una referencia a una ventana ya abierta por su nombre, es decir, window.open(“”, “miVentana”) devuelve una referencia a una ventana abierta previamente con el nombre “miVentana”). Sin embargo para el parámetro name podemos, bien dar un nombre concreto, bien un nombre predeterminado o bien no especificar ninguno. Cabe aclarar que este nombre no tiene nada que ver con el título de la página. Los nombres predeterminados válidos son:

  • _blank
    • Nueva ventana. Valor predeterminado.
  • _parent
    • La nueva ventana se carga en la ventana padre del actual frame y en caso de no estar trabajando con frames, es igual que _self.
  • _self
    • Nueva ventana en la ventana actual.
  • _top
    • La nueva ventana reemplaza todos los frames que hubiera en la actual ventana, aunque en caso de no estar trabajando con frames es igual que _self.

Si damos un nombre a la página, este nombre nos puede servir para varios propósitos:

  • Ser destino de navegación de enlaces o formularios, a través del atributo target.
  • Abrir nuevas ventanas en una misma ventana. Es decir, 2 o más open con el mismo nombre crearán sólo 1 ventana donde se reemplazará la localización a través del parámetro url.

En cuanto al parámetro features y aunque el enlace del msdn o también de mozilla ofrezca muchos más atributos, pienso que son sólo relevantes los siguientes (he puesto en negrita los valores predeterminados):

  • fullscreen = { yes | no | 1 | 0 }.
  • height = número
  • left = número
  • location = { yes | no | 1 | 0 }, se refiere a la barra de navegación.
  • menubar = { yes | no | 1 | 0 }, se refiere a la barra de menús.
  • resizable = { yes | no | 1 | 0 }.
  • scrollbars = { yes | no | 1 | 0 }.
  • status = { yes | no | 1 | 0 }, se refiere a la barra de estado.
  • toolbar = { yes | no | 1 | 0 }, se refiere a la barra de comandos.
  • top = número
  • width = número

El formato del parámetro features es “clave=valor,clave=valor,…”

El método open devuelve una referencia a la nueva ventana creada (que podría ser null si hubo algún problema durante su creación) que servirá posteriormente para poder acceder las propiedades y métodos de la nueva ventana desde la ventana que la abrió.

Otras propiedades relativas al manejo de ventanas son:

  • Propiedad opener, sólo disponible en una ventana abierta con window.open. Devuelve una referencia a la ventana que abrió la actual ventana.
  • Propiedad closed, indica si la ventana ha sido cerrada (esto sirve tanto desde la ventana padre a la ventaja hija – a través de la referencia que devolvió window.open – como desde la ventaja hija a ventana padre – a través de window.opener)
  • Propiedad name, devuelve el nombre de la ventana.

Aunque antes lo mencionamos de pasada, excepto Safari, el resto de navegadores abrieron una nueva ventana en una pestaña, así que ¿Cómo podemos abrir una nueva ventana en una ventana en vez de en una pestaña? http://stackoverflow.com/questions/726761/javascript-open-in-a-new-window-not-tab A mí personalmente la solución que me ha funcionado ha sido especificar height y width en el parámetro features.

Otra práctica que podría resultarnos útil es abrir una nueva ventana y desde esta nueva ventana (la ventana hija) llamar a código de la ventana padre. Para ello debemos detectar si todavía esta abierta la ventana padre y además saber el nombre de una función definida en la ventana padre:

if (!window.opener || window.opener.closed) {

   window.close();

   return;

}

window.opener.funcionDefinidaEnVentanaPadre();

window.close();

 

La verdad es que este post podría ser mucho más extenso y detallado, pero yo creo que con este anticipo cualquiera ya puede enfrentarse al manejo de ventanas en un navegador.

Un saludo!

martes, 29 de marzo de 2011

Script CallBack o “devoluciones de llamada de script”

Este post lo tenía pendiente desde hace mucho porque la característica de Callbacks de cliente en ASP.NET es una característica que yo personalmente no he usado nunca y a decir verdad, creo está en desuso.

En cualquier caso, resulta interesante para completar el circuito de las distintas posibilidades que tenemos en un cliente para ejecutar código en el servidor: ASP.NET AJAX, WebServices y PageMethods, jQuery y ahora… Script Callbacks.

Vaya por delante que no soy ningún experto en Script Callbacks pero voy a intentarlo que es lo principal.

Aunque empiece la casa por el tejado, vamos a ver las principales diferencias que existen entre ASP.NET AJAX (estoy hablando de UpdatePanel), WebServices o PageMethods (que para el caso son lo mismo) y Script Callbacks.

Si agrupamos estos conceptos por su propósito, encontramos los siguientes cometidos:

  • Un UpdatePanel persigue la actualización parcial de una página.
  • Un WebService permite la ejecución de código de servidor desde el cliente y también puede utilizarse para una actualización parcial de la página.
  • Un Script CallBack permite de igual modo, ejecución de código de servidor desde el cliente y también una actualización parcial de la página.

Yo no sé tú, pero yo después de leer lo anterior me he quedado igual… la verdad es que es importante matizar las diferencias.

Un UpdatePanel permite el renderizado de controles de servidor ASP.NET en su interior. Esto es que no hay problema en que la parte de la página que vamos a actualizar incluya controles de servidor ASP.NET. Incluso éstos podrían requerir cierta inicialización de código javascript para crear un componente de cliente asociado. Un ejemplo claro es la colección de controles de ASP.NET AJAX Control Toolkit. A cambio de esta potencia tenemos los siguientes inconvenientes:

Se realiza un postback completo de la página (aunque sea asíncrono y el usuario no perciba el envío del formulario).

Se envía y posteriormente actualiza el ViewState.

Si no se tiene cuidado con el UpdatePanel, podemos llegar a penalizar el rendimiento de nuestra aplicación cuando nuestro principal objetivo era justo el contrario. Mira esta entrada porque podría interesarte.

Se ejecuta todo el ciclo de vida de la página en el servidor (cuidado con código “fijo” – sin verificar IsPostBack o similar - en eventos como Page_Load o Page_PreRender). A mí ahora mismo me sirve especialmente saber que control inició el postback para condicionalmente saltarme ciertas partes del código de eventos como Page_Load o Page_PreRender. Como saber qué control realizó el postback está muy bien explicado aquí

Por otro lado, un WebService es lo más óptimo que podemos utilizar si nuestra intención es ejecutar código en el servidor o devolver HTML sencillo. El envío de datos es mínimo y la respuesta también. Lo importante aquí es comprender que un WebService envía datos simples (texto, json, etc.) y recibe datos simples de nuevo (texto, json, etc.). En este contexto la página .aspx no interviene en el proceso y por ello no hay eventos ni ciclo de vida que valga, es, insisto, lo más óptimo en lo relativo al rendimiento, tanto del servidor como de la red..

Por otro lado, un WebService (o PageMethod) no llega a donde llega el UpdatePanel. Con esto quiero decir que si queremos utilizar un WebService para actualizar el contenido de nuestra página, el resultado devuelto va a ser siempre texto y entonces controles que requieran inicialización en el cliente a través de javascript serán inviables de devolver. De hecho, lo más “especial” que se puede hacer en un WebService en lo relativo a la actualización de la página es renderizar un control en un Stream que después devolveremos al cliente, es decir, devolvemos el resultado de renderizar, pero cualquier otra operación de registro necesaria en cliente llevada a cabo por el control no será ejecutada en nuestra página, y a día de hoy y con la cantidad de controles de servidor ASP.NET que requieren de javascript asociado, comienza a no ser una alternativa viable… Hombre! Para devolver la hora sí, pero poco más… aunque no sé yo porque jQuery y jQuery UI hace maravillas… pero esa es otro historia!

De todas formas, si quieres saber más de servicios web visita estas entradas.

Para renderizar un control de servidor en un servicio web la idea es crear una nueva página, Dim page As New Page, después carga el control con page.LoadControl y después ejecutar la página pero devolver el resultado a una stream que será el texto que finalmente devolvamos en el servicio web. Todo esto lo puedes encontrar en los siguientes enlaces:

http://stackoverflow.com/questions/976524/issues-rendering-usercontrol-using-server-execute-in-an-asmx-web-service

http://encosia.com/2008/02/05/boost-aspnet-performance-with-deferred-content-loading/

http://weblogs.asp.net/sanjeevagarwal/archive/2008/07/22/Dynamically-create-ASP.NET-user-control-using-ASP.NET-Ajax-and-Web-Service.aspx

Mi conclusión final es que depende del tipo de control de servidor ASP.NET que quieras devolver un servicio web te puede o no valer.

Como decía al comienzo del post, a día de hoy yo me muevo con estas soluciones pero últimamente (y porque estoy utilizando la suite de controles de Telerik) estoy viendo que existe una tercera opción que es Script Callbacks.

A primera vista es una solución intermedia que no sé si hoy sigue siendo válida (porque creo que Script Callback fue la primera aproximación que ASP.NET dio al problema de ejecutar código en el servidor) pero aun así tiene sus puntos fuertes que aún hoy lo hacen especial.

Un Script Callback permite llamar a un método de una página desde cliente y lo más importante es que este método no tiene que ser Shared (como es requisito para un PageMethod).

Un Script Callback lanza el ciclo de vida de la página… pero no todo (la verdad es que es de locos!). Los eventos Page_PreRender, Page_PreRenderComplete y Page_SaveStateComplete no se ejecutan, así que también podemos decir que un Script CallBack no actualiza el ViewState (aunque sí lo envía y carga en la página para que funcionen correctamente los eventos Init y Load).

Un Script Callback finalmente se parece mucho a un WebService en que simplemente recibe texto a través de una función de javascript, y es responsabilidad del programador actualizar la página o hacer lo que crea oportuno con este resultado. Esto indica que el anterior problema expuesto para un WebService y un control de servidor ASP.NET que utilice AJAX sigue vigente para Script CallBack.

Después de esto, no se a ti, pero a mi… ni frio ni calor (quizás poder ejecutar un método de instancia de la página sea algo positivo, pero poco más…)

Sin más, vamos a ver un ejemplo de Script Callback y que sé tú mismo quién decida si te resulta o no de utilidad.

Primero el código de servidor:

Partial Class _Default

    Inherits System.Web.UI.Page

    Implements ICallbackEventHandler

 

    Private fecha As String

 

    Public Function GetCallbackResult() As String Implements System.Web.UI.ICallbackEventHandler.GetCallbackResult

        ' Método encargado de devolver el resultado como texto obtenido por la ejecución del método RaiseCallbackEvent.

        Return fecha

    End Function

 

    Public Sub RaiseCallbackEvent(eventArgument As String) Implements System.Web.UI.ICallbackEventHandler.RaiseCallbackEvent

        ' Método que será llamado desde cliente.

        ' Método que se encarga de realizar todas las operaciones oportunas.

        fecha = System.DateTime.Now.ToString

    End Sub

 

    Protected Sub Page_Load(sender As Object, e As System.EventArgs) Handles Me.Load

        ' Este código conecta el cliente con el servidor.

 

        ' WebForm_DoCallback('__Page',arg,retornoLlamadaAsincrona,context,null,false)

        Dim referencia As String = ClientScript.GetCallbackEventReference(Me, "arg", "retornoLlamadaAsincrona", "context")

 

        ' function llamadaAsincrona(arg,context){WebForm_DoCallback('__Page', arg,arrancarLlamadaAsincrona,context,null,false);}

        Dim llamada As String = "function llamadaAsincrona(arg, context)" & "{" & referencia & ";}"

 

        Page.ClientScript.RegisterClientScriptBlock(Me.GetType(), "key_1", llamada, True)

    End Sub

End Class

 

Y ahora el código de cliente:

    <div>

        <input type="button" value="Llamar" onclick="arrancarLlamadaAsincrona();" />

        <asp:Label ID="lblFecha" runat="server"></asp:Label>

    </div>

    <script type="text/javascript">

        function arrancarLlamadaAsincrona() {

            /*

El parámetro "argumento" será recibido en el servidor en el evento

Public Sub RaiseCallbackEvent(eventArgument As String) Implements System.Web.UI.ICallbackEventHandler.RaiseCallbackEvent

*/

 

            /*

Por otro lado el parámetro "contexto" será devuelto en la función de callback de javascript como segundo parámetro */

            llamadaAsincrona("argumento", "contexto");

        }

 

        function retornoLlamadaAsincrona(fecha, contexto) {

            $get("<%=lblFecha.ClientID %>").innerText = fecha;

        }

    </script>

 

A mí personalmente me parece una “jartá” de código… pero bueno, ahí está.

 

Un saludo!

lunes, 28 de marzo de 2011

Publicando Sql Server CE 4.0 en un hosting compartido

En un post anterior introducimos SQL Server CE 4.0 y su nueva y excitante característica de soportar entornos de hosting compartidos con ASP.NET.

En este anterior post, todas las pruebas ocurrían en un entorno local correctamente configurado y donde había pocas posibilidades de encontrar problemas durante el despliegue de nuestra primera aplicación ASP.NET con SQL Server CE.4.0. De hecho, la referencia al ensamblado System.Data.SqlServerCe era desde el GAC, pero claro, en un hosting no puedo esperar que esté instalado SqlServerCe así que tiene que haber alguna forma de solucionarlo.

Siendo así, ha llegado el momento de probar su valía e intentar desplegar un “Hola Mundo” en un entorno de hosting compartido donde (y como es costumbre) no seremos bienvenidos los desarrolladores de ASP.NET.

La aplicación de prueba simplemente contendrá una base de datos con una sola tabla y unos pocos registros y una página por defecto donde mostraremos estos registros en un GridView… suficiente para ilustrar que… Sí, amigos! Hay vida para Sql Server CE 4.0 en un hosting compartido!

Los pasos a seguir son:

1.       Quitar la referencia a System.SqlServer.Ce de GAC.

2.       Copiar en el directorio \bin todo el contenido de la carpeta C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Private.

Ahora podremos comprobar que en local todo vuelve a funcionar correctamente y que los ensamblados necesarios para ejecutar SQL Server CE ya no están tirando del GAC sino de la copia privada que tenemos en el directorio \bin (por cierto, si el proyecto no es .NET Framework 4.0 tendrás que quitar el ensamblado System.Data.SqlServerCe.Entity.dll, con lo que intuyo que si quieres utilizar EF con SQL Server CE 4.0 tu proyecto tiene que ser obligatoriamente .NET Framework 4.0, pero bueno, ese no es mi caso…).

clip_image002

Solucionado este primer error y algo expectantes por el resultado, hacemos la primera subida a nuestro hosting y observamos lo resultados…

El primer error que me encuentro es el siguiente:

clip_image004

Por intuición y viendo en la pila de llamadas un nombre de método LoadNativesBinaries intuyo que el nivel de acceso a la carpeta \bin no es el adecuado, así que concedo el permiso “Modificación” a la cuenta apropiada del worker process de ASP.NET. La verdad es que esto no sé si es porque algo hago mal o porque es así, pero tampoco me importa en exceso, la verdad.

Después de haber modificado los permisos de la carpeta \bin, ahora obtengo este otro error:

clip_image006

Este error es bastante más descriptivo y está claro que hay problemas accediendo al fichero EJEMPLO.sdf (esto es la base de datos Sql Server Ce), así que ahora concedo el permiso “Escribir” a la carpeta App_Code para la identidad del usuario de ASP.NET, y felizmente ahora sí puedo ver mi página con acceso a Sql Server Ce, ejecutándose con éxito en un entorno de hosting compartido.

clip_image007

Si además estás utilizando EF, te dejo estos enlaces porque es necesario realizar algunos cambios en el web.config.

http://social.msdn.microsoft.com/Forums/en-US/sqlce/thread/3822a7ca-c9a0-4c51-92b8-64d4b7d2dd43/

http://stackoverflow.com/questions/3223359/cant-get-sql-server-compact-3-5-4-to-work-with-asp-net-mvc-2

Y para terminar, si estás utilizando System.Data.Common tendrás que hacer ciertos cambios en tu fichero web.config. Puedes visitar este otro post donde lo explico.

Un saludo!.

sábado, 19 de marzo de 2011

SQL Server CE 4.0

Este post me hace especial ilusión porque puede suponer que el trabajo y despliegue de aplicaciones con bases de datos en proyectos pequeños se simplifique sobre manera. Es decir, a día de hoy, no hay ningún problema en utilizar Sql Server Express para desarrollos pequeños o incluso medianos, pero… porque siempre hay un pero… la cosa se complica cuando queremos distribuir nuestra aplicación a cualquier usuario o incluso en un hosting compartido (esta situación me quita mucho más el sueño). Puesto que Sql Server Express requiere de una instalación y administración previa, las posibilidades en un hosting pasan porque soportar la posibilidad de pagar por una base de datos Sql Server Express (que ironía, Sql Server Exprees es gratuito pero después te cobran por ello en el hosting) o si no estás condenado a adquirir un VPS (Servidor privador virtual) en el que tú haces y deshaces pero al precio de tener que haber desechado un hosting compartido a favor de tu propio servidor virtual, que lógicamente es más caro y además tú eres responsable de toda su administración.

En esta línea, y para que el despliegue de una aplicación ASP.NET con acceso a datos se simplifique, han trabajado duramente los chicos de ASP.NET (Ups!, cualquiera diría que los conozco, pero la frase ha quedado chula, ¿eh?). Por ello, ahora podremos utilizar Sql Server CE 4.0 en detrimento de Sql Server Express, o mejor dicho, podremos comenzar con Sql Server CE 4.0 y si le programa lo requiere debido a su volumen, migrar fácilmente a Sql Server Express (ciertamente si mi sitio web ya es visitado por cientos o miles de usuarios, comenzaría a entender que debo pagar por mi base de datos o bien contratar un VPS). También es verdad que siempre está la alternativa de SqlLite, pero nunca me ha dado por probarlo.

Para ver en acción SqlLite http://www.mikeduncan.com/sqlite-on-dotnet-in-3-mins/ y un proveedor de ADO.NET para SqlLite se puede encontrar en http://sqlite.phxsoftware.com/

A continuación te dejo unos enlaces de obligada lectura (siempre y cuando te interese este post, claro). Los primeros son de Scott Guthrie (director general de la división de desarrollo de Microsoft, con lo que si no hacemos casos a este tío, apaga y vámonos!) y el último de Gonzalo Perez (quién leo habitualmente en geeks.ms y la verdad es que en temas de ASP.NET, jQuery, etc. tiene muy buena pinta). Ya por último otro post con un buen resumen de Sql Server Compact 4.0.

http://weblogs.asp.net/scottgu/archive/2010/06/30/new-embedded-database-support-with-asp-net.aspx

http://weblogs.asp.net/scottgu/archive/2011/01/11/vs-2010-sp1-and-sql-ce.aspx

http://geeks.ms/blogs/gperez/archive/2011/03/15/sql-server-ce-4-0-y-el-por-que-deber-237-a-interesarnos.aspx

http://blogs.msdn.com/b/sqlservercompact/archive/2010/07/07/introducing-sql-server-compact-4-0-the-next-gen-embedded-database-from-microsoft.aspx

A grandes rasgos, las principales características de SQL Server CE 4.0 (verás que siempre remarco 4.0, pero es que versiones previas de este producto no podían trabajar en con múltiples conexiones concurrentes, así que directamente para mí no existían esas otras versiones previas).

·         Gratuito y sin ninguna restricción de licencias.

·         No necesita instalación ni administración ni cuenta de usuario con privilegios.

·         Funciona con ADO.NET y Entity Framework.

·         Soporta escenarios con múltiples conexiones concurrentes.

·         Fácil migración a Sql Server.

Para instalar Sql Server CE 4.0, hay que descargarlo desde el siguiente enlace http://www.microsoft.com/downloads/en/details.aspx?FamilyID=033cfb76-5382-44fb-bc7e-b3c8174832e2

Si quieres, también puedes descargarte los BOL desde aquí http://www.microsoft.com/downloads/en/details.aspx?FamilyID=DDA9DC83-F59A-4ECA-B792-DD1D9629B6E7

Como herramienta de administración tenemos varias posibilidades. WebMatrix fue la primera herramienta en soportar la administración y gestión de Sql Server CE 4.0. Por otro lado, si quieres utilizar Visual Studio 2010, tienes primero que instalar el Service Pack 1 y después tienes que instalar las herramientas “Visual Studio 2010 SP1 Tools for SQL Server Compact 4.0” desde WPI (Web Platform Installer). La verdad es que no he encontrado otra forma de conseguir estas herramientas sino es a través de WPI. De hecho, gracias a que encontré este post que hablaba sobre ello, sino aún me estoy volviendo loco… http://programmers.stackexchange.com/questions/56718/sql-server-ce-4-graphical-tools-for-designing-tables-etc

Además he descubierto recientemente una extensión para Visual Studio 2010 que francamente es muy buena y diría yo casi indispensable para trabajar con Sql Server Ce 4.0 desde Visual Studio. Te dejo aquí el enlace de CodePlex, http://sqlcetoolbox.codeplex.com/. Yo la verdad es que me pregunto como usuarios desinteresados se curran estas pedazo de herramientas y mientras tanto Microsoft hace las suyas tan parcas… al menos en lo que respecta a Sql Server Ce 4.0…

Después de esto, ya podemos agregar un nuevo elemento en la carpeta App_Code de un sitio web o proyecto de aplicación web, que será del tipo “Base de datos local de SQL Server Compact 4.0” y que agregará un fichero con la extensión .sdf. También podemos ver que agregar este fichero ha incluido una referencia al ensamblado System.Data.SqlServerCe del GAC.

clip_image002

A partir de aquí podemos trabajar con nuestra base de datos con normalidad, agregar tablas, índices, etc. Cabe señalar que SQL Server CE 4.0 no soporta procedimientos almacenados, pero podré vivir con ello…

Además, ahora tenemos disponible un nuevo espacio de nombres que es el proveedor ADO.NET para SQL Server CE 4.0. El espacio de nombres es System.Data.SqlServerCe. Por ejemplo, un código simple para llenar un GridView podría ser el siguiente:

Imports System.Data

Imports System.Data.SqlServerCe

 

Partial Class _Default

    Inherits System.Web.UI.Page

 

    Protected Sub Button1_Click(sender As Object, e As System.EventArgs) Handles Button1.Click

        Dim connection As New SqlCeConnection("Data Source=|DataDirectory|\EJEMPLO.sdf")

        Dim dataAdapter As New SqlCeDataAdapter

        Dim command As New SqlCeCommand("SELECT * FROM Clientes", connection)

        dataAdapter.SelectCommand = command

        Dim dataSet As New DataSet

        dataAdapter.Fill(dataSet)

        GridView1.DataSource = dataSet

        GridView1.DataBind()

        dataSet.Dispose()

        command.Dispose()

        dataAdapter.Dispose()

        connection.Dispose()

    End Sub

End Class

 

Cabe mencionar que este ejemplo lo he hecho tanto en un sitio web con .NET Framework 3.5 como en uno con .NET Framework 4.0 y en ambos ha funcionado.

El ejemplo va viento en popa, sólo queda subir el sitio web a un hosting compartido para ver que todo funciona OK y que nunca más perderé tiempo preguntando si el hosting soporta Sql Server Express, cuánto cuesta, etc.

El último paso que hay que dar antes de subir al hosting compartido es cambiar la referencia al ensamblado System.Data.SqlServerCe, para que en vez de cargarlo desde GAC lo cargue desde el directorio \bin de nuestro sitio web (de este modo no tendremos ninguna dependencia externa al proyecto). En mi caso, el ensamblado está en la carpeta C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\Desktop\System.Data.SqlServerCe.dll, así que eliminamos la referencia a GAC y copiamos el ensamblado en el directorio \bin.

Ahora ya puedo hacer la prueba definitiva en un hosting compartido y… bueno, para esto tengo que esperar al lunes, pero asumo que funcionará… que emoción… ya os contaré! Mejor visita este otro post donde ya hemos publicado con éxito la aplicación.

Un saludo!.

 

jueves, 17 de marzo de 2011

¿Depurar javascript con IE o con Firefox?

Está claro que a día de hoy un desarrollador web no puedo vivir sin herramientas de programación integradas en el explorador. De hecho, todos los navegadores modernos integran una herramienta de este estilo, así que sin más vamos a ver como lanzar esta herramienta en cada navegador.

  • IE
    • Herramientas \ Herramientas de desarrollo (F12)
  • Firefox
    • No soporta de forma nativa ninguna herramienta, pero a cambio podemos descargar el complemento Firebug que si no es la mejor de las herramientas de desarrollo disponibles en cualquier navegador, poco le falta.
    • Herramientas \ Firebug \ Abrir Firebug (F12)
  • Chrome
    • Herramientas \ Herramientas para desarrolladores (Ctrl+Mayus+I)
  • Safari
    • Herramientas \ Preferencias \ Avanzado \ Mostrar el menú Desarrollo en la barra de menús.
    • Desarrollo \ Mostrar inspector web (Ctrl+Alt+I)
  • Opera
    • Página \ Herramientas \ Opera Dragonfly (Ctrl+Mayus+I)

Si nos fijamos, más o menos todas las herramientas tienen las mismas posibilidades pero presentadas de distinta forma. De hecho, la herramienta de Chrome y Safari parecen ser la misma.

Como decía antes, curiosamente Firefox es el único navegador que no soporta de forma nativa ninguna herramienta de desarrollo, pero a cambio nos ofrece Firebug, un complemento absolutamente necesario y que una vez utilizas es difícil dejar de hacerlo. De hecho, Firebug tiene incluso un sistema de extensiones que pueden mejorar esta herramienta. Por ejemplo, yo tengo instalado además del propio Firebug, las extensiones FireCookie, NetExport, etc. Para encontrar una lista actualizada de las extensiones existentes para Firebug puedes visitar la web del creador http://getfirebug.com/wiki/index.php/Firebug_Extensions

Lo cierto es que me gustaría conocer las características de todas ellas, pero las que utilizo habitualmente son “IE Developer ToolBar” (IE) y “Firebug” (Firefox) y entre ellas no hay color, gana de largo Firebug.

Tengo que reconocer que utilizo IE principalmente por estos motivos:

  • Porque siempre que hay un error de script, aparece la deseada a la par que odiada pantalla que me alerta inmediatamente el error. Digo deseada porque el resto de navegadores no son tan agresivos a la hora de informar de errores de script al usuario, pero también digo odiada porque después, y cuando no estoy desarrollando, precisamente esa agresividad me impide muchas veces navegar normalmente.
  • Porque se lleva bien con Visual Studio y por ejemplo, cuando detengo la ejecución de mi solución me cierra el navegador que abrió previamente (y esto sólo lo hace con IE).
  • Porque soporta puntos de interrupción en el código de cliente.
  • Porque soporta la instrucción debugger que hace que Visual Studio se detenga automáticamente en esa instrucción y la depuración de código de cliente en Visual Studio es, sin duda, infinitamente mejor que con cualquier otra herramienta (en mi opinión).

En cualquier caso, como no quiero ser un fan-boy de IE (pero lo soy, perdón) voy a ver como soluciono esto en Firefox y así poder elegir entre cualquiera de estos 2 navegadores.

Para la alerta de error en javascript, Firefox tiene disponible una ventana en Herramientas \ Consola de errores (Ctrl+Mayus+J) que lo cierto es que da mucha información. En cualquier caso, el problema persiste porque yo no quiero tener que abrir esta consola, yo quiero que se informe automáticamente de cualquier error de javascript en el preciso instante en que ocurre. Para ello, la única forma que conozco es descargar un complemento llamado Console que reemplaza la consola de errores original de Firefox por una más avanzada y con más posibilidades. De hecho, la característica que estábamos buscando es activar la opción “Dar el foco al informar” que hará que aparezca la consola automáticamente cuando se produzca cualquier error de javascript (aunque cabe recordar que para que esto suceda tiene que estar abierto la consola, aunque esté minimizada).

Por otro lado, la instrucción debugger si esta soportada en Firefox también a través del complemento Firebug, pero de nuevo, es necesario tener abierto Firebug y activa la pestaña Script.

La pregunta es ¿Podré algún día establecer como navegador predeterminado en Visual Studio a Firefox?

Me gusta Firefox, me gusta Firebug, pero Visual Studio está tan integrado con IE que resulta difícil desembarazarse de él.

Un saludo!