www.devjoker.com

Herramientas para expresiones regulares

Las expresiones regulares son un dolor de cabeza, al menos para mí. Aquí os dejo un par de herramientas que hacen mas llevadero el trabajo ellas.

txt2re

Esta herramienta nos permite obtener una expresión regular a partir de una entrada de texto.

http://txt2re.com/

El funcionamiento es sencillo, solo tenemos que introducir un texto y formar la expresión regular con el editor que sale en la página.

regex101

Esta herramienta nos permite probar expresiones regulares de forma rápida. Además nos muestra una pequeñas explicación de cada una de las partes de nuestra expresión regular. (gracias a mi compañero Daniel Quijada por este descubrimiento)

https://regex101.com/

Hay muchas herramientas similares, pero lo que realmente diferencia a está es que posee una librería en la que podemos buscar expresiones regulares para cualquier cosa, además cada expresión regular está valorada por la comunidad para poder saber si funciona o no de forma rápida. Por último también tiene un chat. Imprescindible.

Espero que os sean de utilidad,

Saludos, DJK

Servicios WCF con AJAX y JSON.

Un tema sencillo pero que aún mucho programadores desconocen o no saben bien como implementar es la forma de exponer un servicio WCF para ser ejecutado vía AJAX y devolviendo los datos en formato JSON. Vamos a ver un ejemplo de como hacerlo, utilizando un servicio simple de WCF y jQuery desde una página HTML.

Lo primero que debemos hacer es crear un nuevo servicio, desde la plantilla “WCF Service with AJAX enabled”.

Al seleccionar este tipo de plantilla se crean los ficheros del servicio (*.svc y *.svc.cs) y el archivo de configuración, web.config. También añadiremos a nuestro proyecto una página simple HTML para probar el servicio (el contenido de todos estos ficheros los veremos más adelante).

Es importante destacar que en el archivo de configuración se crea un endpoint a nuestro servicio y un comportamiento (behaviour) que permitirá su ejecución con AJAX, esto se indica con enableWebScript. Sin esta opción el servicio no permitirá su ejecución con AJAX.

<system.serviceModel>
    <behaviors>
        <endpointBehaviors>
            <behavior name="WebApplication1.MyServiceSampeAspNetAjaxBehavior">
                <enableWebScript />
            </behavior>
        </endpointBehaviors>
    </behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
        multipleSiteBindingsEnabled="true" />
    <services>
        <service name="WebApplication1.MyServiceSampe">
            <endpoint address="" behaviorConfiguration="WebApplication1.MyServiceSampeAspNetAjaxBehavior"
                binding="webHttpBinding" contract="WebApplication1.MyServiceSampe" />
        </service>
    </services>
</system.serviceModel>

Ahora creamos el servicio, que es extremadamente simple: tan solo un método en el que devolvemos una nueva instancia de la clase Foo.

Un aspecto a destacar es que utilizamos la configuración simplificada de WCF por lo que no es necesario tener una interfaz adicional sobre el servicio.

El código también incluye la clase Foo – que es el tipo de dato que queremos devolver en JSON - , recordad que es necesario decorar la clase con los atributos DataContract y DataMember.

using System;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace WebApplication1
{
    [ServiceContract]
    [AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]
    public class MyServiceSampe
    {        
        [OperationContract]
        public Foo GetFoo()
        {
            return new Foo() { Id = Guid.NewGuid(), Name= "devjoker", Surname="devjoker.com" };
        }        
    }

    [DataContract]
    public class Foo
    {
        [DataMember]
        public Guid Id { get; set; }
        [DataMember]
        public string Name { get; set; }
        [DataMember]
        public string Surname { get; set; }
    }

}

En la página de prueba que hemos creado, añadimos una referencia a jQuery y realizamos la llamada al servicio. El callback de dicha llamada recibe los datos obtenidos del servicio y los muestra en pantalla.

<!DOCTYPE html>
<!--ServiceClientPage.html-->
<html>
<head>
<script src="http://code.jquery.com/jquery-1.9.1.min.js"></script>
  <meta charset="utf-8">
  <title>devjoker.com</title>
  <script>
      $(document).ready(function () {
          $.post("MyServiceSampe.svc/GetFoo", function (response) {
              var foo = response.d;
              $("#foo_id").val(foo.Id);
              $("#foo_name").val(foo.Name);
              $("#foo_surname").val(foo.Surname);
          });
      });

  </script>
</head>
    <body>
        <h1>Service Client Sample</h1>
        <h2>www.devjoker.com</h2>
        <div id="content">
            <input type="text" id="foo_id"/>
            <input type="text" id="foo_name"/>
            <input type="text" id="foo_surname"/>
        </div>
    </body>
</html>

La ejecución de la página tiene el siguiente aspecto, nada del otro mundo!

Si nos fijamos en el código cliente, observamos que el resultado del servicio lo obtenemos a través de una propiedad “d” de la respuesta:

var foo = response.d;

Por defecto, WCF devuelve los datos envueltos en un propiedad «d», este comportamiento es debido a una recomendación de seguridad, como se explica en este enlace. Si analizamos el tráfico HTTP vemos claramente este comportamiento.

No obstante, esto suele ser interpretado como un inconveniente por muchos desarrolladores. Por supuesto es posible devolver el resultado de forma plana modificando el archivo de configuración del siguiente modo:

<behaviors>
    <endpointBehaviors>
        <behavior name="WebApplication1.MyServiceSampeAspNetAjaxBehavior">
            <enableWebScript />
            <webHttp defaultOutgoingResponseFormat="Json" defaultBodyStyle="WrappedRequest" /> 
        </behavior>
    </endpointBehaviors>
</behaviors>

Nota: Es posible configurar el servicio del mismo modo, utilizando los atributos WebInvoke y WebGet, aunque personalmente prefiero este acercamiento desacoplado, ya que es posible modificar como envía y devuelve datos el servcio desde configuración.

Si modificamos el web.config de este modo obtenemos la respuesta limpia.

Para que el ejemplo funcione debemos modificar también el código javascript cliente, ya no es necesario leer la propiedad «d»

$(document).ready(function () {
    $.post("MyServiceSampe.svc/GetFoo",  function (response) {
        // var foo = response.d
        var foo = response;
        $("#foo_id").val(foo.Id);
        $("#foo_name").val(foo.Name);
        $("#foo_surname").val(foo.Surname);
    });
});

Enviar parámetros al servicio WCF

Ahora vamos a ver otro ejemplo, esta vez enviado parámetros al servicio. Lo primero añadimos un nuevo método al servicio, en el que enviamos dos parámetros.

[OperationContract]        
public Foo BuildFoo(string name, string surname)
{
    return new Foo() { Id = Guid.NewGuid(), Name = name, Surname = surname };
}

El código cliente para ejecutar el servicio es ligeramente mas complejo, aunque nada del otro mundo:

$.ajax({
    url: "MyServiceSampe.svc/BuildFoo",
    type: "POST",
    data: JSON.stringify( { name: "The name", surname: "The surname" }),              
    contentType: "application/json"
}, function (response) {
        var foo = response;
        $("#foo_id").val(foo.Id);
        $("#foo_name").val(foo.Name);
        $("#foo_surname").val(foo.Surname);
});

Lo único destacable es el uso de $.ajax y la función JSON.stringify para el envío de los parámetros al servicio. No olvidemos especificar el contentType “application/json”.

Por último, vamos a añadir otro método al servicio, está vez recibiendo como parámetro una clase .net InputType .

[OperationContract]        
public Foo BuildFooFromType(InputType input)
{
    return new Foo() { Id = Guid.NewGuid(), Name = input.Name, Surname = input.Surname };
}

Donde el parámetro “input” de entrada es la siguiente clase:

public class InputType {    
    public string Name { get; set; }    
    public string Surname { get; set; }
}

Y la ejecución del lado cliente es muy similar al ejemplo anterior, pero debemos “envolver” los parámetros en una propiedad input (debe coincidir con el nombre del parámetro en el servicio).

$.ajax({
    url: "MyServiceSampe.svc/BuildFooFromType",
    type: "POST",
    data:  JSON.stringify({ "input":{ Name: "The name", Surname: "The surname" } }),              
    contentType: "application/json"
},
    function (response) {
        var foo = response;
        $("#foo_id").val(foo.Id);
        $("#foo_name").val(foo.Name);
        $("#foo_surname").val(foo.Surname);
});

Si analizamos el tráfico HTTP vemos la ejecución y respuesta del servicio en JSON.

Bueno, espero que este articulo os haya resultado interesante y haya aclarado algunas dudas sobre la forma de trabajar con WCF, AJAX y JSON.

Saludos y hasta la próxima. DJK

IT Books. Libros gratuitos para descarga

Un post cortito, solo compartir con vosotros el siguiente site: http://it-ebooks.info , un excelente recurso donde podemos encontrar todo tipo de libros de programación e informática.

Muy recomendable.

Saludos, DJK

Cambiar el idioma teclado con los nuevos Windows 8 y Windows 2012.

Por si alguien tiene problemas para encontrar donde cambiar el teclado en Windows 2012 o Windows 8 (algo que suele suceder cuando te conectas por escritorio remoto a un equipo en otro país) os incluyo un video que he grabado para un cliente

Como digo en el video parece una tontería pero yo he tardado un rato en encontrarlo.

No te olvides de poner el Where en el Delete From (Una canción para programadores)

No sé si es de los creadores de “Tocame el windows” o no, pero estamos ante otro de esos WTF que van a pasar a la historia como una de la mayores frikadas jamas vistas!.

Sin palabras!

Visto en https://www.facebook.com/kunfCode

Safari, Ajax y autenticación Windows. No se envían lo datos del POST.

Esta semana he estado liado con un problema que me ha estado volviendo loco. La aplicación con la que trabajo hace uso intensivo de jQuery y Ajax, y funciona bastante bien (modesto que soy :-)) en todos los navegadores modernos. ¿Todos? No! Una aldea poblada por … en Safari no.

En Safari, tanto en su versión de windows como iPAD la página provocaba un error en el servidor. Tras depurar la aplicación encontré que el problema era que no se están enviado los datos del POST, por lo que inicialmente pensé en un problema del lado del cliente, algún error de javascript y jQuery, así que lo primero que hice fue probar la aplicación y analizar el tráfico con Fiddler.

Mi sorpresa llego cuando la aplicación funciono sin problema … apague Fiddler y volvió a fallar. El caso es que tras volverme medio loco encontré este hilo de stackoverflow y me dio la solución:http://stackoverflow.com/questions/7613196/ajax-post-request-only-works-once-in-safari-5, en el se puede ver la respuesta correcta.

The reason the call is failing is because of a bug in Safari when working with Windows Authentication under IIS. Go to the Authentication settings of your website. Right click on Windows Authentication, choose providers and remove Negotiate, leaving NTLM which works fine. I haven't tested Kerberos.

This issue only appears in certain builds of safari.

Como vemos se trata de un bug de Safari. En el se describe perfectamente mi problema:

Envío de datos POST con Ajax
Aplicación con autenticación Windows sobre IIS.
Safari

Lo gracioso del tema es que se indica que solo ocurre con algunos de los builds del producto … Y para lo que os esteis preguntando porque funciono cuando trabaje con Fiddler decir que Fiddler se pone como proxy, siendo finalmente Fiddler (y no Safari) el que envía las peticiones al IIS.

Para solucionarlo debemos abrir la consola de administración de IIS, seleccionar nuestro site web e ir a la opción de autenticación.

Abrimos el elemento y nos muestra las distintas opciones de autenticación disponibles, seleccionamos Autenticación de Windows.

De ahí seleccionamos proveedores y eliminamos Negotiate, dejando únicamente NTLM como proveedor.

Y eliminamos Negotiate de la lista de proveedores. Mas información sobre el proveedor: http://technet.microsoft.com/es-es/library/dd560645(v=ws.10).aspx

Espero que esta entrada os resulte de ayuda.

Saludos y hasta la próxima.

Test Unitario y ficheros. Adiós DeploymentItem

Trabajar en un proyecto de test unitario que requiera de ficheros es un suplicio, además de tremendamente engorroso.

Si nos remitimos a la documentación de Microsoft, http://msdn.microsoft.com/en-us/library/microsoft.visualstudio.testtools.unittesting.deploymentitemattribute.aspx , debemos decorar nuestro método de test con el atributo DeploymentItem, y configurar la información de la ruta de entrada y salida del fichero. Este proceso es necesario ya que los test se ejecutan en el contexto de programa host (vstest.executionengine.exe)

Pero realmente esto no es suficiente, y para que realmente funcione debemos establecer varias propiedades a nivel del archivo (como CopyToOutput true) y configurar el test para que admita el deployment de archivos. Cuando solo necesitamos uno o dos ficheros, puede pasar, pero cuando el número de test que requieren de ficheros aumenta se convierte en un autentico calvario.

Por si fuera poco, debemos incluir el código para leer el fichero en nuestro test, con lo que estamos añadiendo complejidad y posibles puntos de error (un test podría fallar al leer el fichero, y no en la condición de prueba).

Para rematar la faena, la complejidad aumenta si ejecutamos nuestros test en un servidor de integración continua como parte de una Build. Si buscamos un poco el panorama es desalentador …

Afortunadamente existe un método muy sencillo que nos evita todo este jaleo, que es extremadamente simple y que además os lo voy a explicar ahora mismo! :-)

Es tan fácil como usar archivos, de recursos. Los archivos de recursos permiten incluir archivos como parte de sus componentes. Los ficheros adjuntos se almacenan fuera del archivo de recursos – lo que nos permite modificarlos de forma fácil desde el propio VisualStudio, y es el propio framework quien se encarga del resto. Además cuando accedamos al fichero lo haremos directamente a través de propiedades sin necesidad de tener que andar leyendolo.

Vamos a verlo con un sencillo ejemplo, Imaginemos un programa en el que tenemos la siguiente clase:

public class Persona    
{
    public static Persona Load(string xmlString) {
        var document = XDocument.Parse(xmlString);            
            
        var persona = new Persona();
        persona.Id = Guid.Parse(document.Root.Element("Id").Value);
        persona.Name = document.Root.Element("Name").Value;
        persona.SurName = document.Root.Element("SurName").Value;
        return persona;
    }

    public Persona()
    {
        this.Id = Guid.NewGuid();
    }

    public Guid Id { get; protected set; }

    public string Name { get; set; }

    public string SurName { get; set; }
           
}

La clase es muy sencilla, y solo tiene una serie de propiedades básicas. Le hemos añadido un método estático Load que nos permite instanciar la clase desde un string – ya sé que no es el mejor diseño, pero necesitaba un ejemplo válido para el articulo!!

Ahora, en nuestro proyecto de test añadimos un fichero Personal.xml con el siguiente contenido:

<?xml version="1.0" encoding="utf-8" ?>
<persona>
    <Id>316F0DFC-CD03-458F-85BE-389B7E0E2D0C</Id>
    <Name>www.devjoker.com</Name>
    <SurName>Unit Test y archivos</SurName>
</persona>

Este fichero nos va a servir como entrada para el test del método Load de la clase.

Ahora tenemos que añadir un archivo de recursos a nuestro proyecto de test, al que llamamos PersonaTestResources.resx. En un archivo de recursos podemos añadir el fichero simplemente modificando la vista a “Files” desde el combo de la esquina superior izquierda …

Y añadir el archivo Persona.xml al fichero de recursos arrastrandolo al interior de la vista de diseño.

Y por fin el test:

using Files = TestSample.Test.Resources.PersonaTestResources;
[TestClass]
public class PersonaTest
{
    [TestMethod]        
    public void PersonaLoadTest() { 
        // arrange
            
        // act
        var persona = Persona.Load(Files.Persona);

        // assert
        Assert.AreEqual(persona.Id.ToString(), "316F0DFC-CD03-458F-85BE-389B7E0E2D0C",true);
        Assert.AreEqual(persona.Name, "www.devjoker.com");
        Assert.AreEqual(persona.SurName, "Unit Test y archivos");
    }

}

Fijaros que hemos creado un alias Files para nuestro fichero de recursos - using Files = TestSample.Test.Resources.PersonaTestResources; - , y podemos acceder al contenido del fichero simplemente accediendo a la propiedad de Persona (dado que nuestro archivo se llamaba Persona.xml )

Cuando el test se ejecuta podemos ver que dicha propiedad tiene el contenido del fichero:

Lo mejor de todo es que además nuestro test se ejecuta sin problemas en un servidor de builds.

Este método es mucho más sencillo y fácil de mantener que el tradicional con el atributo DeploymentItem, asi que adios DeploymentItem … adios!

Saludos y hasta la próxima!.

Estructura de una aplicación ASP.NET MVC

Crear una aplicación ASP.NET MVC con Visual Studio

Ya hemos visto los fundamentos de una aplicación web y una introducción al patrón MVC. Llegados a esto punto ya podemos crear nuestra aplicación web con ASP.NET MVC. Para ello, abrimos Visual Studio, y a través del menú seleccionamos “New Project”. En el caso de que no tengamos instalado Visual Studio podemos descargar la versión Express (gratuita) desde el siguiente enlace: http://www.asp.net/mvc

Para crear una aplicación ASP.NET MVC basta con seleccionar la opción adecuada dentro de la pantalla de templates para Visual Studio. Seleccionamos ASP.NET MVC Web Applicattion. En el caso de que la opción no figure en al lista, es indicativo de que no hemos instalado ASP.NET MVC. Podemos realizar dicha descarga desde este enlace: http://www.asp.net/mvc

En el siguiente paso debemos seleccionar la plantilla del proyecto. Disponemos de tres plantillas:

Empty – Plantilla vacia.
Internet Application – Plantilla de propósito general configurada con seguridad basada en formularios (la aplicación pedirá usuario y password al visitante para identificarse). Adecuada para aplicaciones de internet.
Intranet Application - Plantilla de propósito general configurada con seguridad basada en Windows, integrada con el directorio activo (la aplicación utiliza el usuario de Windows que esta conectado). Adecuada para entornos de intranet.

En nuestro caso seleccionamos “Internet Application”.

Es importante destacar que en la parte inferior de esta pantalla es en la que seleccionamos el motor de renderizado de las vistas «View Engine» - seleccionamos RAZOR. En ASP.NET MVC las vistas son procesadas por un motor de renderizado antes de ser devueltas al cliente. Este motor es RAZOR. En este mismo tutorial veremos en detalle la sintaxis de RAZOR.

Además disponemos de un segundo motor de renderizado – ASPX, que emplea la misma sintaxis utilizada por Web Forms (basado en las marcas <% %>)

También podemos instalar motores adicionales, como el caso de NHAML - http://code.google.com/p/nhaml/, una implementación de .NET del popular motor de renderizado de Ruby On Rails.

En esta pantalla – New ASP.NET MVC 4 Project -, seleccionamos además la casilla para crear un proyecto de «Testing» y el framework que deseamos utilizar para el mismo. Una de las ventajas que obtenemos al utilizar ASP.NET MVC es simplificar el proceso de test de nuestro código, algo importantísimo de cara a la calidad de nuestros desarrollos. Al final de este tutorial incluiremos un anexo sobre test unitario (mientras tanto os invito a la excelente introducción que realizo Ibon Landa en Geeks http://geeks.ms/blogs/ilanda/archive/2009/06/16/pruebas-unitarias-resumiendo.aspx)

Finalmente, pulsamos OK y Visual Studio creará el proyecto.

Al finalizar, debemos tener una solución de Visual Studio con una estructura como la siguiente:

Como podemos ver la imagen anterior Visual Studio ha creado una solución con dos proyectos:

MvcApplication1, se trata del proyecto web que contiene los archivos de nuestra aplicación web.
MvcApplication1.Test, es el proyecto de testing asociado.

A continuación vamos a explicar los diferente archivos y directorios que se han creado en el proyecto MvcApplication1, con el objetivo de entender la organización de ficheros y carpetas de ASP.NET MVC.

Profundizaremos en los diferentes conceptos según avancemos en el tutorial, se muestran aquí de manera introductoria para que nos vayamos familiarizando con la estructura de archivos y carpetas.

Estructura de directorios y archivos.

Cuando creamos una nueva aplicación con ASP.NET MVC se crea por defecto una estructura de directorios, apropiada para la gran mayoría de las aplicaciones. Por supuesto podemos añadir nuevos directorios a esta estructura, aunque por razones de coherencia recomendamos mantener la estructura que propone ASP.NET MVC.

Directorio App_Data.

Este directorio está pensado para ubicar archivos de datos, normalmente bases de datos MSSQL. También es el lugar adecuado para archivos XML o cualquier otra fuente de datos.

Inicialmente está vacio.

Directorio App_Start.

Este directorio, nuevo en ASP.NET MVC 4, contiene los archivos de código que se ejecutan al inicializar la aplicación. Como veremos mas adelante, todo aplicación ASP.NET MVC es una instancia derivada de la clase System.Web.HttpApplication, definida en el archivo global.asax. Esta clase es la encargada de iniciar la aplicación, el directorio App_Start está pensando para ubicar las clases de configuración para el inicio de la aplicación.

La siguiente imagen muestra el contenido del directorio.

Por defecto contiene los siguientes archivos(clases):

AuthConfig.cs
BundleConfig.cs
FilterConfig.cs
RouteConfig.cs
WebApiConfig.cs

Directorio Content.

El directorio Content está pensado para el contenido estático de la aplicación, especialmente útil para archivos css e imágenes asociadas.

ASP.NET MVC nos ofrece por defecto una organización en base a “temas”, que nos permita personalizar el aspecto visual de nuestra aplicación de forma fácil y rápida (eso en teoría… elaborar un tema visual puede requerir de mucho trabajo y la colaboración de un diseñador gráfico, algo que recomiendo siempre que sea posible).

También es el lugar apropiado para los archivos .less en el caso de que utilicemos esta tecnología en nuestra aplicación.

Directorio Controllers.

El directorio controllers en el lugar para los controladores, que como hemos visto en el capitulo anterior los controladores son las clases encargadas de recibir y gestionar las peticiones http de la aplicación.

Veremos los controladores en profundidad mas adelante.

Directorio Filters

El directorio Filters es el lugar donde debemos ubicar los filtros. Los filtros son atributos (también llamados decoradores) para los controladores, que nos permiten aplicar un comportamiento previo y posterior a la ejecución de uno o varios métodos de los controladores. Son clases derivadas de System.Web.Mvc.ActionFilterAttribute. A través de este mecanismo podemos añadir fácilmente funcionalidad a nuestros controladores evitando repetir la misma lógica una y otra vez, sobrescribiendo el comportamiento de algunas acciones.

La plantilla incluye un filtro de ejemplo, InitializeSimpleMembership, en el siguiente ejemplo vemos como se utiliza el fitlro para decorar la clase AccountController (también incluida en la plantilla de proyecto)

[Authorize]
[InitializeSimpleMembership]
public class AccountController : Controller
{
    //
    // GET: /Account/Login

}

Veremos los filtros en profundidad mas adelante.

Directorio Images

Este es evidente … El directorio images es lugar para la imágenes de nuestra aplicación.

Como observación diremos que en el caso de que las imágenes formen parte del aspecto visual del sitio web, y no del contenido, deberían estar en el directorio content, como parte de un tema.

Por ejemplo, el contenido de una galería fotográfica o de un catalogo de productos debería estas en la carpeta images, mientras que las imágenes de fondo, iconos de los botones, sprites, etc deberían estar en la carpeta content junto con los archivos css. Básicamente, si una imagen se utiliza en un archivo css el lugar adecuado es la carpeta content.

Directorio Models

El directorio models es la ubicación que nos propone ASP.NET MVC para las clases que representan el modelo de la aplicación, los datos que gestiona nuestra aplicación.

Nota. En aplicaciones complejas, divididas en capas las clases de modelo suelen incluirse en assemblie aparte.

La siguiente clase muestra un ejemplo muy básico para representar el modelo de nuestra aplicación.

public class FooModel
{
    public Guid Id { get; set; }

    public string Name { get; set; }
}

Una de las grandes ventajas de las que disponemos en ASP.NET es que podemos decorar la clase que representa la modelo con diferentes atributos, que nos van a permitir establecer reglar sobre los datos como por ejemplo las reglas de la validación, si el datos es requerido o no, la longitud máxima y mínima del dato … etc

public class FooModel
{
    [Required]   
    public Guid Id { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 3)]    
    [Display(Name = "Name for FooModel")]
    public string Name { get; set; }
}

Como veremos cuando veamos las vistas, estos atributos son interpretados por la vista para establecer automáticamente las validaciones necesarias en función del los decoradores utilizados en el modelo.

Directorio Scripts

El directorio scripts está pensado para ubicar los archivos de javascript (*.js). El código javascript es ejecutado en el contexto del navegador, es decir, en la parte cliente, y nos permite ejecutar acciones sin necesidad de enviar los datos al servidor.

ASP.NET MVC incluye varias librerias de javascript por defecto:

jquery.js. Esta popular y súper útil librería nos va a permitir gestionar fácilmente peticiones AJAX, manipular el DOM en cliente, etc … Esta librería se ha convertido en un framework muy popular, y es la base de para la creación de pluggins que nos van a permitir dotar a nuestro sitio web de efecto sorprendentes sin apenas esfuerzo. http://jquery.com/
jquery.spin.js. Este pluggin nos permite crear animaciones de indicación de carga de contenidos – el circulito que da vueltas para indicarnos que la página esta realizando algún proceso . Es un pluggin de jQuery basado en spin.js. http://fgnass.github.io/spin.js/
jquery.validate.js. Este pluggin nos permite realizar validaciones en el lado cliente fácilmente. Esta vinculado al uso de decoradores en el modelo de nuestra aplicación.
knockout.js. Esta librería nos permite utilizar el patrón de diseño MVVM (Model View ViewModel), que introdujo Microsoft para el desarrollo con WPF y Silverlight en aplicaciones web con javascript. http://knockoutjs.com/
modernizr.js. Esta librería nos permite validar fácilmente si el navegador que esta ejecutando la página web es compatible con HTML5, en en caso de que no sea así proporcional un mecanismo alternativo (polyfill). http://modernizr.com/. Por ejemplo, si nuestro navegador es compatible con HTML5 interpretará sin problema la etiqueta VIDEO, pero en el caso de que estemos navegando con un navegador antiguo deberemos ofrecer al usuario un mecanismo alternativo para el video (un flash por ejemplo). En el siguiente enlace podemos encontrar polyfills para casi todas las características de HTML5: https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills

Nota: El nombre de los archivos puede varias dependiendo de la versión instalada, por ejemplo el archivo jQuery.js se llama jquery-1.7.1.js, ya que corresponde con la versión 1.7.1 de la librería.

Directorio Views

El directorios Views contiene los archivos de vista. Como explicamos en la introducción al patrón MVC los controladores devuelven vistas sobre las que inyectamos el modelo de nuestra aplicación. Estas vistas son interpretadas por el motor de renderización – Razor en nuestro caso. Son archivos similares a aplicaciones de ASP clasico, donde tenemos código HTML estático y determinadas zonas de código que son ejecutadas en el servidor.

El siguiente ejemplo muestra el clásico “Hola Mundo”.

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
    ViewBag.Title = "HelloWorld";
}
<h2>HelloWorld</h2>
@*El código se servidor se especifica con el caracter @*@

Podemos asignar un modelo a la vista a través de la siguiente directiva.

@model MvcApplication1.Models.FooModel

Veremos las vistas en profundidad mas adelante.

Directorio Shared

El directorio Shared contiene vistas que van a ser reutilizadas en otras vistas. Veremos como incluir vistas - denominadas parciales – en otra vista cuando veamos Razor, aunque de manera muy breve diremos que se realiza a través del Helper Html, de la siguiente forma:

@Html.Partial("Error") @*Incluye la vista parcial Error.cshtml, del directorio Shared*@

En este caso es muy importante respetar la ubicación de los archivos, ya que cuando desde una vista hagamos la llamada @Html.Partial(“Error”) para incluir la vista de la pantalla de error, el motor buscara en el directorio Shared para encontrar la vista Error.cshtml.

No debemos confundir una vista compartida con los controles .ascx de ASP.NET WebForms. Cuando incluimos vistas compartidas en otra vista, esta son interpretadas por RAZOR sin ejecutarse ningún controlador. Simplemente se renderiza su contenido – no como en los controles ascx donde se ejecuta todo el ciclo de vida del control completo y sus correspondientes eventos.

Es posible utilizar una vistas compartida de un modo muy similar al de un control ascx de ASP.NET WebForms, aunque para este debemos forzar la ejecución del controlador a través de los métodos Action y RenderAction del Helper Html:

@Html.Action("About") @*Ejecuta el método "About" del controlador correspondiente*@

Archivo _ViewStart.cshtml

Este archivo establece el layout por defecto de las páginas. El contenido del archivo es sencillo y únicamente especifica el archivo de layout.

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

El layout es un archivo con extension .cshtml que contiene la estructura general de documento, que es reutilizada en el resto de vistas. De este modo evitamos tener que reescribir el código en todas las vistas, reutilizando el código y permitiendo que este sea mucho mas sencillo de mantener.

En cierto modo es similar a las MasterPages de ASP.NET WebForms.

Archivo _Layout.cshtml

El archivo _Layout.cshtml define el layout de la aplicación, que contiene la estructura general de documento, que es reutilizada en el resto de vistas. El archivo _Layout.cshtml se encuentra dentro del directorio Views/Shared. El contenido del archivo layout por defecto se muestra a continuación:

<!DOCTYPE html>
<html lang="en">
    <head>
        <meta charset="utf-8" />
        <title>@ViewBag.Title - My ASP.NET MVC Application</title>
        <link href="~/favicon.ico" rel="shortcut icon" type="image/x-icon" />
        <meta name="viewport" content="width=device-width" />
        @Styles.Render("~/Content/css")
        @Scripts.Render("~/bundles/modernizr")
        
    </head>
    <body>
        <header>
            <div class="content-wrapper">
                <div class="float-left">
                    <p class="site-title">@Html.ActionLink("your logo here", "Index", "Home")</p>
                </div>
                <div class="float-right">
                    <section id="login">
                        @Html.Partial("_LoginPartial")
                    </section>
                    <nav>
                        <ul id="menu">
                            <li>@Html.ActionLink("Home", "Index", "Home")</li>
                            <li>@Html.ActionLink("About", "About", "Home")</li>
                            <li>@Html.ActionLink("Contact", "Contact", "Home")</li>
                        </ul>
                    </nav>
                </div>
            </div>
        </header>
        <div id="body">
            @RenderSection("featured", required: false)
            <section class="content-wrapper main-content clear-fix">
                @RenderBody()
            </section>
        </div>
        <footer>
            <div class="content-wrapper">
                <div class="float-left">
                    <p>&copy; @DateTime.Now.Year - My ASP.NET MVC Application</p>
                </div>
            </div>
        </footer>

        @Scripts.Render("~/bundles/jquery")
        @RenderSection("scripts", required: false)
    </body>
</html>

Fijemonos en la llamada que hace Razor al método @RenderBody(), es ahí donde se procesará la vista que estemos mostrando.

Podemos tener múltiples archivos de layout dentro de nuestro proyecto.

El archivo web.config

El archivo web.config es el archivo principal de configuración de ASP.NET. Se trata de un archivo XML donde se define la configuración de la aplicación. Veremos poco a poco el contenido de este fichero, aunque vamos a ver aquí algunas características generales que es necesario conocer.

Para simplificar el despliegue de las aplicaciones, el archivo de configuración se presenta en diferentes versiones o “sabores”, de forma que podemos modificar el archivo de configuración dependiendo de nuestra configuración de despliegue. Si observamos estos archivos observaremos que contienen transformaciones XML que se aplican sobre el archivo web.config al desplegar la aplicación. De este modo cuando desplegamos la aplicación en modo Debug se aplicarán las transformaciones XML definidas en Web.Debug.config.

El archivo de configuración aplica un mecanismo de jerarquía a nivel de los archivos de configuración, en la que un archivo de mayor profundidad dentro de la jerarquía sobrescribe al de menor, en el contexto del recurso solicitado.

Por ejemplo, si dentro de nuestra aplicación tenemos un archivo web.config sobre la raíz del sitio (en gris sobre la imagen), y otro sobre la carpeta Views (en rojo), el archivo de configuración de la carpeta Views prevalece y sobrescribe el valor del archivo de configuración raiz (siempre que el recurso solicitado sea se encuentre el directorio, en este ejemplo Views).

De esta forma podemos por ejemplo establecer en nuestro sitio web “areas” públicas y privadas de manera muy sencilla, tan fácil separar los archivo es directorios e como incluir un archivo de configuración con la seguridad activada sobre el directorio privado, y otro accesible a todo el mundo en el directorio privado. Veremos como hacer esto con Areas de ASP.NET un poquito mas adelante.

El archivo global.asax

Toda aplicación ASP.NET MVC es una instancia de una clase derivada de System.Web.HttpApplication. Esta clase es el punto de entrada de nuestra aplicación – el Main de la aplicación web por decirlo de alguna manera. Como podemos observar, la clase base es la misma que para una aplicación ASP.NET clásica (WebForms) por lo que todos que podemos reutilizar todo lo que ya sabíamos de ASP.NET.

Desde este archivo podemos manejar eventos a nivel de aplicación, sesión, cache, autenticacion, etc ...

Este archivo varia mucho desde la versión anterior de ASP.NET MVC, aunque el funcionamiento es el mismo. En ASP.NET MVC 4 se ha incluido el directorio App_Start que nos permite organizar como se inicializa la aplicación.

// Por defecto, el namespace corresponde con el nombre del proyecto 
namespace MvcApplication1 
{
    public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();
            WebApiConfig.Register(GlobalConfiguration.Configuration);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
            AuthConfig.RegisterAuth();
        }
    }
}

Como podemos ver, el código se encarga de registrar las áreas definidas en el proyecto, cargar la configuración, filtros, etc…, en definitiva, se encarga de configurar la aplicación para que esta pueda ejecutar de manera correcta. Las clases de configuración se encuentran en el directorio App_Start

En el siguiente enlace podemos encontrar la documentación oficial sobre el archivo global.asax http://msdn.microsoft.com/en-us/library/1xaas8a2(v=vs.71).aspx

La lista completa de eventos disponibles es la siguiente:

// Summary:
//     Occurs when ASP.NET acquires the current state (for example, session state)
//     that is associated with the current request.
public event EventHandler AcquireRequestState;
//
// Summary:
//     Occurs when a security module has established the identity of the user.
public event EventHandler AuthenticateRequest;
//
// Summary:
//     Occurs when a security module has verified user authorization.
public event EventHandler AuthorizeRequest;
//
// Summary:
//     Occurs as the first event in the HTTP pipeline chain of execution when ASP.NET
//     responds to a request.
public event EventHandler BeginRequest;
//
// Summary:
//     Occurs when the application is disposed.
public event EventHandler Disposed;
//
// Summary:
//     Occurs as the last event in the HTTP pipeline chain of execution when ASP.NET
//     responds to a request.
public event EventHandler EndRequest;
//
// Summary:
//     Occurs when an unhandled exception is thrown.
public event EventHandler Error;
//
// Summary:
//     Occurs just before ASP.NET performs any logging for the current request.
public event EventHandler LogRequest;
//
// Summary:
//     Occurs when the handler is selected to respond to the request.
public event EventHandler MapRequestHandler;
//
// Summary:
//     Occurs when the request state (for example, session state) that is associated
//     with the current request has been obtained.
public event EventHandler PostAcquireRequestState;
//
// Summary:
//     Occurs when a security module has established the identity of the user.
public event EventHandler PostAuthenticateRequest;
//
// Summary:
//     Occurs when the user for the current request has been authorized.
public event EventHandler PostAuthorizeRequest;
//
// Summary:
//     Occurs when ASP.NET has completed processing all the event handlers for the
//     System.Web.HttpApplication.LogRequest event.
public event EventHandler PostLogRequest;
//
// Summary:
//     Occurs when ASP.NET has mapped the current request to the appropriate event
//     handler.
public event EventHandler PostMapRequestHandler;
//
// Summary:
//     Occurs when ASP.NET has completed executing all request event handlers and
//     the request state data has been stored.
public event EventHandler PostReleaseRequestState;
//
// Summary:
//     Occurs when the ASP.NET event handler (for example, a page or an XML Web
//     service) finishes execution.
public event EventHandler PostRequestHandlerExecute;
//
// Summary:
//     Occurs when ASP.NET bypasses execution of the current event handler and allows
//     a caching module to serve a request from the cache.
public event EventHandler PostResolveRequestCache;
//
// Summary:
//     Occurs when ASP.NET finishes updating caching modules and storing responses
//     that are used to serve subsequent requests from the cache.
public event EventHandler PostUpdateRequestCache;
//
// Summary:
//     Occurs just before ASP.NET starts executing an event handler (for example,
//     a page or an XML Web service).
public event EventHandler PreRequestHandlerExecute;
//
// Summary:
//     Occurs just before ASP.NET sends content to the client.
public event EventHandler PreSendRequestContent;
//
// Summary:
//     Occurs just before ASP.NET sends HTTP headers to the client.
public event EventHandler PreSendRequestHeaders;
//
// Summary:
//     Occurs after ASP.NET finishes executing all request event handlers. This
//     event causes state modules to save the current state data.
public event EventHandler ReleaseRequestState;
//
// Summary:
//     Occurs when the managed objects that are associated with the request have
//     been released.
public event EventHandler RequestCompleted;
//
// Summary:
//     Occurs when ASP.NET finishes an authorization event to let the caching modules
//     serve requests from the cache, bypassing execution of the event handler (for
//     example, a page or an XML Web service).
public event EventHandler ResolveRequestCache;
//
// Summary:
//     Occurs when ASP.NET finishes executing an event handler in order to let caching
//     modules store responses that will be used to serve subsequent requests from
//     the cache.
public event EventHandler UpdateRequestCache;

Home Controller

La clase HomeController es el punto de entrada de la aplicación, la página por defecto.

Cuando creamos un nuevo proyecto ASP.NET MVC se crea también un controlador HomeController situado directamente el folder Controllers.

El controlador de ejemplo que se incluye en el proyecto por defecto, incluye tres métodos: Index, About y Contact, que disponen de sus correspondiente vistas en el folder Home.

El código del HomeController es el siguiente:

namespace MvcApplication1.Controllers
{
    public class HomeController : Controller
    {
        public ActionResult Index()
        {
            ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";

            return View();
        }

        public ActionResult About()
        {
            ViewBag.Message = "Your app description page.";

            return View();
        }

        public ActionResult Contact()
        {
            ViewBag.Message = "Your contact page.";

            return View();
        }
    }
}

Como podemos ver cada uno de los métodos del controlador devuelve la vista asociada por defecto:

Index() devuelve la vista index.cshtml
About() devuelve la vista about.cshtml
Contact() devuelve la vista contact.cshtml

Veremos los controladores en el siguiente capitulo.

Creación de Áreas.

Como hemos visto, ASP.NET MVC divide los elementos que componen su arquitectura en carpetas con el mismo nombre (Models, Views, Controllers). Esta división es fácil e intuitiva pero puede ser limitada en aplicaciones grandes, donde el número de entidades a manejar sea grande. Para estos casos ASP.NET MVC proporciona un mecanismo muy sencillo que nos permite agrupar contenidos (y sus configuraciones) denominadas Areas.

Un Area no es mas que una carpeta que replica en su interior la estructura anterior de MVC - Model, Views, Controllers y define sus propias rutas de acceso a través de la clase PublicContentAreaRegistration que se crea automáticamente al añadir una nueva área. Tiene la ventaja adicional de tener su propio archivo de configuración de modo que es ideal para diferenciar zonas públicas y privadas por ejemplo.

Podemos crear Areas del siguiente modo:

Sobre el explorador de soluciones de Visual Studio,

Visual Studio nos preguntara el nombre del área que queremos crear, en nuestro caso le damos el nombre PublicContent

Podemos ver que se ha creado en Visual Studio un directorio Areas, con un subdirectorio PublicContent en el que podemos encontrar la estructura de carpetas de Controllers, Models y Views que ya hemos visto anteriormente.

También tenemos un archivo de configuración (que nos permite sobrescribir la configuración raiz a través del mecanismo de jerarquia explicado anteriormente) y un archivo PublicContentAreaRegistration.cs en el que se registra la ruta del área sobre la tabla de rutas de ASP.NET MVC (veremos como funciona este mecanismo mas adelante), de momento diremos que la tabla de ruta establece un mapeo entre las URLs que envía el navegador y el controlador que debe gestionar estas peticiones.

El valor de this en Javascript: cómo manejarlo correctamente

Articulo reproducido de http://www.etnassoft.com, con el consentimiento de Carlos Benítez autor del post original.

Enlace al post original: http://www.etnassoft.com/2012/01/12/el-valor-de-this-en-javascript-como-manejarlo-correctamente/

Introducción

this es un valor complejo en Javascript; un error en el diseño del lenguaje susceptible de causar tanto comportamientos inesperados como potentes estructuras de código reutilizable. Su valor, lejos de ser intuitivo, se determina según la forma en que se invoque a la función que lo encierra, algo que no siempre es correctamente entendido o aprovechado.

Dado que el correcto manejo de this resulta esencial en la programación orientada a objetos, y en definitiva en el desarrollo moderno de aplicaciones, es interesante dedicar unos minutos a revisarlo.

Qué es exactamente this

La palabra clave this tiene en Javascript un comportamiento diferente al de otros lenguajes pero por lo general, su valor hace referencia al propietario de la función que la está invocando o en su defecto, al objeto donde dicha función es un método.

La palabra clave del párrafo anterior es “propietario“.

Cuando no estamos dentro de una estructura definida, esto es un objeto con métodos, el propietario de una función es siempre el contexto global. En el caso de los navegadores web, tenemos que recordar que dicho objeto es window:

console.log(this === window);  // true
function test() {
    console.log(this === window);
}
test(); // true

Accediendo a los valores de un objeto desde el propio objeto

Este concepto de propietario puede inducir a errores. Pensemos en un objeto con una serie de propiedades:

var myApp = {
    name: 'Megan',
    lastName: 'Fox',
    birthDate: '16/05/1986',
    isPretty: true
};
console.log(myApp.name); // Megan
console.log(myApp.isPretty); // true

Supongamos ahora que necesitamos otra propiedad más ‘dinámica’ que participe de los valores asignados a cualquier otra. Por ejemplo, queremos un ‘completeName‘ que concatene ‘name‘ y ‘lastName‘. Parece que este un claro ejemplo de uso para this:

var myApp = {
    name: 'Megan',
    lastName: 'Fox',
    completeName: this.name + this.lastName
}

Aunque parece coherente, cuando pasamos a comprobarlo vemos que el resultado no es el esperado:

console.log(myApp.completeName); // undefined

El problema aquí es que this no está apuntando al objeto como cabría esperar, sino que está buscando la referencia fuera, en el contexto global (window).

Para obtener el resultado esperado tenemos que aplicar un patrón de invocación que modifique al propietario desde el que se invoca el this…

Patrón de invocación por método

En Javascript, existen varias formas de llamar a las funciones desde nuestro código; concretamente, podemos enumerar hasta cinco diferentes. La elección de una u otra responde al flujo de nuestro programa pero básicamente, difieren en el contexto que queramos aplicar a cada una. O lo que es lo mismo, al valor que queramos que la función asigne a la referencia this.

En el desarrollo de aplicaciones modernas, el patrón más recurrente es el de invocación por método: una función es almacenada como propiedad de un objeto convirtiéndose así en lo que denominamos un método.

Cuando llamamos (invocamos) a un método, this hace refencia al propio objeto:

var myApp = {
    name: 'Megan',
    lastName: 'Fox',
    completeName: function () {
        return this.name + ' ' + this.lastName;
    }
}
console.log(myApp.completeName()); // Megan Fox

En esta ocasión, si podemos comprobar como this apunta al propio objeto y busca la propiedades ‘name‘ y ‘lastName‘ dentro en lugar de remontarse hasta el contexto global.

Pero como vimos en el caso anterior, no siempre el uso de this es intuitivo. Consideremos la siguiente estructura:

var myApp = function () {
    var name = "World"
    var sayHello = function () {
        console.log('Hello, ' + this.name);
    };
    sayHello(); // Invoke the function
};
myApp(); // Hello,

¿A dónde está apuntando this en este caso? Como la función no es ahora la propiedad de un objeto, this apunta de nuevo al global (window). Esto es un error en el diseño del lenguaje ya que, de comportarse como se espera, this debería apuntar a la función contenedora (que no deja de ser su propietaria).

Este comportamiento lo podemos comprobar si creamos una variable global con aquel nombre por el que estamos preguntando:

var name = "Strange World";
var myApp = function () {
    var name = "World"
    var sayHello = function () {
        console.log('Hello, ' + this.name);
    };
    sayHello();
};
myApp(); // Hello, Strange World

La consecuencia de este error es que un método no puede utilizar funciones internas que la ayuden a hacer su trabajo porque éstas, no tiene acceso a sus propiedades.

Para resolver este problema, podemos recurrir a una solución muy simple: definir dentro de nuestra función contenedora una nueva variable que cachee el valor de this para que así esté disponible desde cualquier otra función anidada que lo precise. Por convención, el nombre de esta variable es that:

var myApp = function () {
    var that = this; // Work around!
    var name = "World"
    var sayHello = function () {
        console.log('Hello, ' + that.name);
    };
    sayHello();
};
myApp(); // Hello, World

NOTA: Últimamente, la convención que propuso Douglas Crockford está siendo revisada y son muchos los desarrolladores que prefieren el término self para referirse al objeto cacheado.

Sobreescribiendo el valor de this en tiempo de ejecución

Una de las características consideradas avanzadas dentro del lenguaje Javascript es la posibilidad de reescribir el valor de this en tiempo de ejecución consiguiendo así una modularidad y reusabilidad extrema.

Más arriba comentamos que existen varias formas de invocar funciones en Javascript donde la elección entre una u otra depende del valor que queramos asignar a this.

Consideremos el siguiente codigo:

var person1 = {
    name: 'Angelina',
    lastName: 'Jolie',
    birthDay: '04/06/1975',
    lastMovie: 'The Tourist'
};
var person2 = {
    name: 'Scarlett',
    lastName: 'Johansson',
    birthDay: '22/11/1984',
    lastMovie: 'We bought a Zoo'
}
var printName = function () {
    console.log(this.name + ' ' + this.lastName);
}

Si tratamos de ejecutar sin más la función printName, ya sabemos que el this apunta al objeto global window e irá ahí a buscar las propiedas name y lastName.

En una arquitectura modular, lo ideal es que esa función pueda ser reaprovechada y que nos permita imprimir los datos de cualquier objeto que cumpla con los requisitos. Para ello, podemos cambiar el valor de this en tiempo de ejecución con el fin de que apunte a ese objeto en cuestión. Para ello, contamos con las funciones nativas apply y call:

printName.call(person1); // Angelina Jolie
printName.call(person2); // Scarlett Johansson
printName.apply(person1); // Angelina Jolie
printName.apply(person2); // Scarlett Johansson

El resultado es el mismo: hemos ejecutado la función printName dentro del contexto de cada uno de los objetos que hemos pasado como argumento.

La diferencia entre cada uno de estas funciones es que la segunda de ellas, apply, acepta un array como argumento, lo que permite una flexibilidad aún mayor a la hora de plantear código reusable.

Pensemos en una función que nos permita actualizar datos dentro de nuestros objetos:

var updatePerson = function (name, lastName, birthDay, lastMovie) {
    this.name = name;
    this.lastName = lastName;
    this.birthDay = birthDay;
    this.lastMovie = lastMovie;
}
updatePerson(person1, 'Angelina', 'Jolie', '04/06/1975', 'Kung Fu Panda 2');

Las limitaciones de call se hacen rápidamente evidentes cuando queremos escribir código que no conoce (o no debe conocer) el número de argumentos que la función necesita.

Tomemos por ejemplo una función que siga el conocido paradigma del ‘dispatcher‘:

var dispatch = function (person, method, args) {
    method.apply(person, args);
}
dispatch(person1, printName);
dispatch(person2, update, ['Scarlett', 'Johansson', '22/11/1982', 'The Avengers']);

En este caso, el poder jugar con el valor de this y además asociar una serie de datos a través de un array, permite una poderosa flexibilidad a la hora de escribir código reutilizable.

Conclusión

El valor de this ha sido siempre difícil de manejar en Javascript. Las pequeñas diferencias que presenta frente a otros lenguajes así como un error en su diseño, lo hacen francamente especial. Sin embargo, esa peculiaridad, es precisamente la que permite crear un tipo de código muy versátil una vez que conocemos sus secretos.

Manejarlo correctamente es una parte esencial dentro del desarrollo de aplicaciones complejas en Javascript.

Visual Studio modifica la configuración de Proxy al ejecutar los test unitarios.

Ayer migré la solución de devjoker.com desde Visual Studio 2010 a Visual Studio 2012. Todo parecía funcionar sin problemas. pero hoy me he encontrado con que al ejecutar los test unitarios en Visual Studio 2012, se modifican las “Opciones de Internet”, activando al casilla “usar servidor proxy”. Todo parece funcionar correctamente cuando Visual Studio está activo, pero cuando lo cerramos nos encontramos con que la conexión a internet ha dejado de funcionar.

Por supuesto, he llegado a esta conclusión tras volverme loco un buen rato y maldecir un par de veces a «ya sabéis quien». Tras un rato de «ver que pasa», he descubierto de que el problema viene de la configuración de test que tenia en la maquina.

Para solucionar este problema, debemos modificar la configuración de test de nuestro archivo .testsettings, y desactivar la opción «ASP.NET Client Proxy for intellitrace and TestInpact»

Bueno, espero que este post un ahorre el tiempo que yo he perdido buscando la solución.

Saludos,

DJK.

Test de métodos privados. PrivateObject

Cuando realizamos test unitarios, en principio solo podemos realizar test de los métodos públicos. Pero es habitual querer realizar test de métodos privados, Visual Studio permite crear clases de acceso, denominadas “accesors”, estas clases se generar automáticamente cuando seleccionamos la opción de “generar test” desde el menú contextual del editor de código, pero es un sistema poco intuitivo que personalmente no me gusta nada. Además en VisualStudio 2012 la opción de generar los test automáticamente esta bastante escondida …http://dl.my/2013/enable-create-unit-tests-on-visual-studio-2012/ .

Otra forma mas elegante e intuitiva (a mi juicio) es utilizar la clase PrivateObject que nos permite ejecutar métodos privados y poder testearlos.

Veamos un ejemplo. Supongamos la siguiente clase, Foo. La clase tiene un única método público, que a partir de un array de cadenas de texto, devuelve un nuevo array con los tres primeros caracteres del texto de entrada. No es nada complejo, pero así salimos un poco del clásico ejemplo de la calculadora que utiliza todo el mundo cuando habla de testing…

La clase es la siguiente:

public class Foo
{
    private string[] names;
    public Foo(string[] names)
    {
        this.names = names;
    }

    public string[] GetShortNames()
    {
        List<String> returnValue = new List<string>(names.Length);

        foreach (var name in names)
        {
            returnValue.Add(GetShortName(name));
        }
        return returnValue.ToArray();
    }

    private string GetShortName(string name)
    {
        return name.Length > 3 ? name.Substring(0, 3) : name;
    }
}

Como podemos ver, el método público GetShortNames utiliza un método privado GetShortName. Por supuesto que testeando el método público estamos testeando también el privado, pero es mejor testear ambos, entre otras ventajas, si algo falla nos permitirá determinar más fácilmente donde esta el error. Además si aplicamos TDD es imprescindible.

Ahora vamos a ver el ejemplo del test del método privado. Por supuesto necesitamos agregar un nuevo proyecto de test a nuestra solucion, y agragar una clase FooTest como la siguiente:

using System;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace ConsoleApplication1.UnitTest
{
    [TestClass]
    public class FooTest
    {
        // SUT: Foo

        [TestMethod]
        public void GetShortNameTest()
        {
            // arrange
            var foo = new Foo(new string[0]);
            var privateObject = new PrivateObject(foo, new PrivateType(typeof (Foo)));
            var name = "www.devjoker.com";
            
            // act
            var actual = privateObject.Invoke("GetShortName", name);

            // assert
            Assert.AreEqual(actual, "www");
        }
    }
}

Como podemos ver, creamos una instancia de la clase Foo, y la utilizamos para crear un objeto PrivateObject con el que invocamos al método privado. Al ejecutar el test podemos ver que se ejecuta el método privado, que es lo que pretendíamos.

Saludos,

DJK

Introducción a KendoUI

KendoUI es un framework de componentes basado en jQUERY para agilizar el desarrollo web que está siendo desarrollado por la empresa Telerik; inicialmente nació con el objetivo de ofrecer componentes HTML5 y CSS 3, actualmente y gracias a las frecuentes actualizaciones soporta además del desarrollo vía JavaScript el desarrollo desde el lado servidor con versiones para ASP.NET MVC, JSP y PHP, así como componentes para desarrollar web móviles adaptadas al estilo de los sistemas móviles más importantes, y componentes para realizar gráficos.

Lo primero que vamos a hacer es descargar alguna de las versiones de KendoUI, para ello vamos a su web (http://www.kendoui.com) y en la sección downloads vemos las versiones disponibles, si vamos a desarrollar un proyecto open source tenemos la posibilidad de descargar la versión GPL 3 que aunque sólo ofrece los componentes web y acceso a las versiones mayores para probar y conocer el framework es más que suficiente. En este caso voy a descargar la versión Complete en versión trial, para poder realizar la descarga tenemos que crearnos una cuenta en la web de KendoUI.

Un vez descargado, descomprimimos el fichero y tenemos un conjunto de carpetas, nosotros vamos a necesitar las carpetas js, styles que contienen los ficheros JavaScript y los estilos CSS junto con las imágenes que vamos a necesitar. Si hubiéramos descargado la versión comercial además de estas carpetas tendríamos una más llamada src que contiene los ficheros JavaScript y estilos CSS sin “minificar” con lo que podemos leerlos bien formateados o incluso editarlos si es que nos atrevemos.

Ahora que tenemos ya todos los ficheros necesarios, abrimos Visual Studio (en mi caso 2012) y creamos una nueva aplicación web MVC 4 de tipo Internet, yo la he llamado KendoUISample.

Una vez creado el proyecto añadimos los ficheros JavaScript y los CSS a la solución.

KendoUI nos proporciona diferentes ficheros JavaScript para cada uno de los componentes por si solo queremos usar alguno en concreto, además nos proporciona también un fichero con todo (kendo.all.min.js) que es el que voy a añadir yo, también proporciona los ficheros para tener documentación en JavaScript (kendo.all.min.intellisense.js para Visual Studio 2012 y kendo.all-vsdoc.js para las versiones anteriores de Visual Studio).

Ahora en la vista _Layout.cshtml que se encuentra dentro de la carpeta Views\Shared añadimos las referencias a los ficheros de estilos y de JavaScript.

Por último vamos a crear un control calendario en la vista Index.cshtml de la carpeta Views\Home, para ellos añadimos un nuevo input con id datepicker y en una sección añadimos el código JavaScript que convertirá el input en un control de calendario de KendoUI.

Ejecutamos la aplicación y podemos ver el calendario funcionando. En la primera captura podemos ver el aspecto cerrado y en la segunda abierto.

Patrón MVC. Modelo Vista Controlador

MVC es un patrón arquitectónico cuyo principal propósito es establecer una separación clara entre la interfaz de usuario que presenta la aplicación y la lógica de negocio que maneja la aplicación. Se trata de un patrón antiguo, se remonta a los años a finales de los años 70, pero que ahora vive una nueva época de esplendor gracias a su intensa utilización en los entornos de desarrollo web.

ASP.NET MVC es el framework que propone Microsoft para el desarrollo web utilizando el patrón MVC sobre la tecnología ASP.NET. Esto, que a priori puede parecer evidente tiene una consecuencia inmediata: gran parte de los que podamos saber de ASP.NET WebForms es aplicable en ASP.NET MVC: Modelo de objetos integrado (Server, Response, Request …),Seguridad (API Membership),Modulos HTTP,Handlers …

Actualmente (abril 2013), ASP.NET se encuentra en su cuarta versión, y se ha convertido en un proyecto de código abierto: http://www.asp.net/mvc/open-source

Los elementos que componen el patrón son los siguientes:

El controlador. Es el elemento encargo de recibir y procesar la peticiones HTTP. Su responsabilidad es retornar una vista concreta con el modelo correcto.
El modelo. Corresponde con la representación de los datos/entidades de negocio que modelan la aplicación.
La vista. El contenido que va a ser devuelto como consecuencia de la petición HTTP. La vista recibe el modelo para poder realizar la presentación de los datos.

El siguiente diagrama ilustra el proceso.

Aplicado a la ASP.NET MVC, el diagrama funciona de la siguiente manera:

El navegador realiza un petición a una determinada URL.
ASP.NET MVC recibe la petición y determinar el controlador que debe ejecutarse (veremos más adelante como se realiza este proceso).
El controlador:
- Recibe la petición HTTP.
- Procesa los datos, y crea u obtiene el modelo.
- Retorna una vista, a la que normalmente le asigna el modelo (aunque no es necesario establecer un modelo).
La vista que ha retornado el controlador, es interpretada por el motor de renderización de ASP.NET MVC «Razor», que procesa la vista para generar el documento HTML que será devuelto finalmente al navegador
El navegador muestra la página.

Nota: ASP.NET MVC dispone de varios motores de renderización – Razor, aspx, - , en este tutorial utilizaremos Razor.

Nota: Los controladores pueden devolver diferentes tipos de contenido no solo documentos HTML, aunque en el dibujo se especifica únicamente HTML para simplificar el concepto.

Es por tanto, el controlador el encargado de coordinar la ejecución, generar el modelo y devolver la vista.

Veamos un ejemplo muy básico :

using System.Web.Mvc;
using DevjokerMvcTutorial.Models;

namespace DevjokerMvcTutorial.Controllers
{
    public class BasicController : Controller
    {               
        public ActionResult Index()
        {
            // Este método devuelve la vista index.cshtml, del directorio Views
            // Equivalente a return View("Index")
            return View(); 
        }
    }
}

Como podemos ver un controlador es una clase derivada de Controller, esta clase está definida en el framework de ASP.NET MVC y nos proporciona gran parte de la funcionalidad que vamos a necesitar. Entre esta funcionalidad se encuentra el método View() que nos permite devolver una vista (archivo con extensión .cshtml que será procesada por Razor)

El archivo de vista, index.cshtml tiene el siguiente aspecto (la vista puede ser un archivo html sin código Razor):

@{
    ViewBag.Title = "Index";
}
<h2>Index View</h2>
<p>Pagina index.cshtml - www.devjoker.com</p>

ASP.NET MVC hace uso intensivo de las convenciones, una de las mas importantes es la forma en la que se determina la ubicación física de las vistas. Cuando especificamos en un controlador BasicController un llamada al método View() el motor buscara una vista con el mismo nombre que el método invocado en la ruta «Views/Basic/» . De forma que si un controlador BasicController dispone de un método ProductList el método View() buscara la vista Views/Basic/ProductList.cshtml.

Pongamos algunos ejemplos con colorines para que quede claro:

Una petición con la siguiente URL:

http://localhost:5421/Basic/ProductList ejecutara el controller BasicController, método ProductList …

BasicController->ProductList->View() que devolverá la vista …

Views/Basic/ProductList.cshtml

Del mismo modo:

http://localhost:5421/Product/NewProduct ==> ProductController->NewProduct->View() ==>Views/Product/NewProduct.cshtml

http://localhost:5421/Client/New ==> ClientController->New->View() ==>Views/Client/New.cshtml

Nota: En realidad la búsqueda de la vista comienza en el directorio Views, en el caso de no encontrarse este fichero se buscará en el directorio Shared, otra de las convecciones de ASP.NET MVC. Estudiaremos mas en detalle este comportamiento cuando veamos Razor y las vistas.

Por supuesto, podemos modificar este comportamiento – podemos ver como en este artículo http://www.variablenotfound.com/2009/06/cambiar-la-ubicacion-de-las-vistas-en.html –, aunque de momento no haremos uso de esta característica.

En el ejemplo anterior – dada su extrema simplicidad – no hemos utilizado un modelo de datos. Veamos ahora un ejemplo, también muy sencillo, en el que utilizamos un modelo. Supongamos que queremos mostrar en una página los datos de un cliente

using System;

namespace MvcApplication1.Models
{
    public class Client
    {
        public Guid Id { get; set; }
        public string FirstName { get; set; }
        public string SurName { get; set; }

    }
}

Y en el controlador añadiremos el método correspondiente para devolver el cliente:

using System;
using System.Web.Mvc;
using MvcApplication1.Models;

namespace MvcApplication1.Controllers
{
    public class BasicController:Controller
    {
        public ActionResult ClientDetail()
        {
            var clientModel = new Client()
                             {
                                 Id = Guid.NewGuid(),
                                 FirstName = "Pedro",
                                 SurName = "Herrarte"
                             };
            return View(clientModel);
        }
    }
}

Y por último la vista, ClientDetail.cshtml , en la que incluimos el código necesario para mostrar los datos del cliente que inyectamos como modelo en el controlador:

@model MvcApplication1.Models.Client

<!DOCTYPE html>

<html>
    <head>
        <title>title</title>
    </head>
    <body>
        <div>
            <h1>Datos de cliente</h1>
            <div>
                @*Código Razor, muestra la propiedad id del módelo*@
                @Html.LabelFor(m=>m.Id)
                @Html.TextBoxFor(m=> m.Id)  
            </div>
            <div>
                @*Código Razor, muestra la propiedad FirstName del módelo*@
                @Html.LabelFor(m=>m.FirstName)
                @Html.TextBoxFor(m=> m.FirstName)
            </div>
            <div>
                @*Código Razor, muestra la propiedad SurName del módelo*@
                @Html.LabelFor(m=>m.SurName)
                @Html.TextBoxFor(m=> m.SurName)
            </div>
        </div>
    </body>
</html>

Ejecutamos la aplicación y en nuestro navegador introducimos la URL siguiente: http://localhost:3072/Basic/ClientDetail (la raiz de la url depende de la configuración del proyecto) y el resultado de la ejecución seria esta:

En los siguientes capítulos del tutorial ampliando nuestros conocimientos de cada uno de los elementos de ASP.NET MVC.

No aparece custom code activity para windows workflow foundation en la barra de herramientas de Visual studio

Un posible fallo que sucede con Workflow Foundation 4 o superior y que no han corregido con la versión 2012 es que a veces cuando creamos una custom activity o custom code activity esta no aparece correctamente en la barra de herramientas (toolbox)

Este problema tiene fácil solución simplemente cerramos el visual studio y lo volvemos a abrir.

Como digo sucede tanto con Workflows 4.0 como con los nuevos basados en la versión 4.5 y parece más un problema de visual studio (en todas sus versiones) que de .net, afortunadamente sólo sucede a veces

Saludos

Pablo.

¿Es legal usar SQL server express en entornos de producción?

mucha gente tiende a pensar que la versión xpress es sólo para desarrollo pero en realidad puedes usarla en cualquier entorno siempre y cuanto no tengas problemas de tamaño, con SQL server xpress 2012 estás limitado a:

1 Cpu (cuatro cores)
1 GB de memoria ram
10 GB de espacio por cada base de datos

No importa si tu servidor tiene más recursos, simplemente SQL server sólo usará esos como máximo.

Así mismo tampoco hay ningún problema en usar integration services o reporting services con la versión express (unicamente en que ese caso necesitamos la versión express with advanced services)

Eso si, hay que tener en cuenta que con la versión xpress tenemos las herramientas para ejecutar reportes y paquetes ssis de integration pero no las herramientas para crearlos ni para automatizarlos

Es decir: si, es completamente legal usar SQL server versión express en entornos de producción

Para más información sobre licencias podéis consultar en:

http://www.microsoft.com/en-us/sqlserver/get-sql-server/how-to-buy.aspx

Y para descargar la versión express podéis descargarla aquí:

http://www.microsoft.com/en-us/download/details.aspx?id=29062

Un saludo, Pablo.

CMSMatrix–Comparador de gestores de contenidos on-line.

Si has tenido que realizar la implantación del algún gestor de contenidos, seguramente te has preguntado cual es el mejor para tu necesidades ¿Te conviene implantar Joomla! o Wordpress?, ¿es mejor DotnetNuke o Umbraco, o quizas Orchard? ¿Son Open Source o de pago? …

En la web de CMSMatrix - http://www.cmsmatrix.org/, podemos comparar las caracteristicas de los sistemas de gestión de contenido más populares del mercado de forma fácil y rápida.

En la siguiente imagen podemos ver el resultado de la comparativa entre los CMS más populares para la plataforma .NET - DotnetNuke, Umbraco y Orchard.

Podemos realizar comparativas entre un monton de sistemas - algunos que seguro ni siquiera conoces!

En definitiva, un gran recurso que nos ayudará a tomar la mejor decisión a la hora de elegir un CMS.

Saludos, DJK!

Como montar un entorno de sharepoint 2010 de forma simplificada (desarrollo y sistemas)

Un enlace interesante para poder montar una máquina de sharepoint de forma simplificada.

http://www.microsoft.com/en-us/download/details.aspx?id=23415

Es un script de power shell para facilitar toda la instalación, funciona tanto en máquinas normales como en máquinas virtuales.

Desgraciadamente sólo está la versión para 2010 , todavía no hay versión para 2013, tampoco incluye el visual Studio 2012 mucho más para desarrollar en la versión 2012 pero en cualquier caso simplifica bastante la instalación.

Reducir el tamaño del log de transacciones en SQL server

Una pregunta típica en servidores SQL que usan el modo de restauración FULL o BULK es cómo reducir el tamaño del log de transacciones cuando este crece de forma anormal en SQL server 2008 o superior.

Normalmente el log se reduce sólo cuando hacemos un backup pero hay ocasiones en que esto no es así
y el log crece y crece .

Para evitarlo y reducir de nuevo el log tenemos que ejecutar el siguiente script:

-usamos la base de datos ficticia devjoker2013BD
--Primero hacemos un backup completo de la base de datos para evitar perder la información del log
--en caso de restauración hasta un punto en el tiempo

BACKUP DATABASE devjoker2013BD
TO DISK = 'D:\SQLServerBackups\devjoker2013BD.Bak'
   WITH FORMAT,
      MEDIANAME = 'D_SQLServerBackups',
      NAME = 'Backup completo de devjoker2013BD previo al truncado del log';

--cambiamos el modo del log de base de datos a SIMPLEALTER DATABASE devjoker2013BD

SET RECOVERY SIMPLE;
GO
-- Comprimimos el log a un sólo MB de tamaño

DBCC SHRINKFILE (devjoker2013BD_Log, 1);
GO
-- Volvemos a dejar el log en modo completo (o bulk logged si ese era el caso).
ALTER DATABASE devjoker2013BD
SET RECOVERY FULL;
GO

Nota: para que esta operación funcione al 100% es posible que tengamos que dejar temporalmente
la base de datos en modo monousuario (es decir sin acceso al mismo)
para garantizar que no haya transacciones pendientes en el momento de hacer el truncado

En ese caso necesitaríamos un código como este:

USE devjoker2013BD;

ALTER DATABASE AdventureWorks2012 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO ALTER DATABASE AdventureWorks2012 SET READ_ONLY;

--Realizamos el backup y el truncado del log
GO

ALTER DATABASE AdventureWorks2012 SET MULTI_USER;

Contrariamente a lo que podamos pensar a corto plazo no notaremos una mejora del rendimiento sino un empeoramiento ya que
tarde o temprano el log volverá a crecer hasta su tamaño optimo que supuestamente será menor que el tamaño anterior pero mayor de
1MB que es el valor que especificamos anteriormente.

Una vez que el log tenga el tamaño optimo y no sobredimensionado si deberíamos notar una mejora del rendimiento aunque no siempre
será perceptible a simple vista.

Por esto último no deberíamos realizar esta operación como parte de un plan de mantenimiento sino cómo una operación puntual
cuando detectemos que el tamaño del log toma un tamaño exagerado y siempre después de un backup completo para evitar perdida de datos en caso
de tener que restaurar.

Solution Load Manager. Extension de Visual Studio para trabajar con soluciones de gran tamaño.

Cuando trabajamos en Visual Studio con Soluciones de gran tamaño, lo mas habitual es que solo trabajemos al mismo tiempo con un pequeño número de proyectos, por lo que cargar y compilar todos los proyectos resulta una carga innecesaria.

Especialmente cuando trabajamos varios equipos, en una arquitectura bien estructurada en capas es muy habitual que existan especialistas web que solo trabajen con presentación, arquitectos que se ocupen de la infraestructura … No obstante, cuando abrimos la solucion Visual Studio carga todos los proyectos (aunque no los vayamos a necesitar) y hace que nuestro trabajo sea mucho mas lento de lo que debería, y por lo tanto seamos mucho menos productivos.

Solution Load Manager es un excelente pluging de Visual Studio que nos va a permitir especificar que proyectos queremos cargar cuando abramos la solucion de Visual Studio. Además disponemos de la posibilidad de crear perfiles, de modo que podemos especificar facilmente que proyectos han de cargase en cada momento.

Podemos descargar Solution Load Manager desde este enlace. Una vez instalado se habita una nueva opción de menú contextual (boton derecho) de la solución.

Este menú nos permitirá acceder a la pantalla de configuración de Solution Load Manager, desde donde podremos especificar que proyectos se deben cargar al abrir la solucion

Simplemente marcando los proyectos y utilizando los botones de color de la parte superior de la interfaz podemos especificar como han de cargarse los proyectos al abrir la solucion. La opciones permitidas son:

Cargar el proyecto por defecto al abrir la Solucion.
Carga en segundo plano.
Cargar el proyecto si es necesario.
Carga explicita.

Una vez realizadas las modificaciones, recargaremos la solución con solo los proyectos necesarios para nuestro trabajo. Espero que os sea de tanto utilidad como me ha sido a mi.

Saludos,

DJK

Fundamentos de funcionamiento de una aplicación web

Arquitectura cliente-servidor y modelo de petición - respuesta

Antes de poder entrar a ver como se programa una aplicación con ASP.NET es necesario conocer algunos de los fundamentos de funcionamiento de una aplicación web.

Los primero que debemos saber es que las aplicaciones web se basan en una arquitectura cliente-servidor. Donde:

El servidor es el ordenador encargado de proporcionar el contenido. Para ello necesitamos instalar un servidor web en dicha máquina. Existen multitud de servidores web (Apache, LigHTTPd, IIS) pero no todos son capaces de ejecutar aplicaciones ASP.NET. Únicamente los servidores de Microsoft pueden desempeñar dicha tarea. En nuestro caso utilizaremos IIS Espress.
El cliente, que es el encargado de solicitar la información al servidor y mostrarla al usuario. Es el navegador (Interner Explorer, Firefox, Chrome, etc ). Si estas viendo está pagina estas utilizando un navegador web.

El funcionamiento de una aplicación es simple, el cliente emite una petición de un recurso que se encuentra en el servidor, y el servidor devuelve el recurso solicitado que es mostrado por el navegador.

La petición del recurso en concreto se realiza a través de una URL. Una URL no es mas que una cadena de texto, expresada en un formato determinado en la que indicamos el protocolo, el puerto, el servidor y el recurso que estamos solicitando. Por ejemplo:

http://www.devjoker.com:80/default.aspx

En nuestro caso el protocolo es HTTP, el servidor www.devjoker.com, el puerto el 80 y el recurso default.aspx. El puerto estándar para el protocolo HTTP es el 80, por lo que no se suele especificar. Dependiendo de la configuración del servidor podríamos omitir el recurso y asignar uno por defecto. De este modo la siguiente URL seria equivalente a esta otra:

http://www.devjoker.com

La petición HTTP tendría la siguiente forma:

GET http://www.devjoker.com/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: es-ES
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: www.devjoker.com
If-Modified-Since: Fri, 03 Aug 2012 10:57:59 GMT
Connection: Keep-Alive
Pragma: no-cache
Cookie: ASP.NET_SessionId=nullimt1wzjmbtik5ferit4w;

Aunque nosotros solo especifiquemos la URL, el navegador web añadirá cierta información adicional a la petición como el tipo de contenido que acepta como respuesta, el lenguaje, tipo de navegador …

Y la respuesta sería algo similar a esto (se acorta el contenido del documento HTML devuelto por razones de espacio):

HTTP/1.1 200 OK
Cache-Control: public
Content-Type: text/html; charset=utf-8
Expires: Fri, 03 Aug 2012 10:58:48 GMT
Last-Modified: Fri, 03 Aug 2012 10:58:38 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 03 Aug 2012 10:58:39 GMT
Content-Length: 42013
<!DOCTYPE html >
<html lang="es">
<head id="Head1">
<title>www.devjoker.com</title>
</head>
<body>

....
</body>
</html>

Tanto la petición como la respuesta pueden tener dos secciones diferenciadas: Las cabeceras de HTTP (indicadas en cursiva y color gris en el ejemplo) y el cuerpo. Profundizaremos algo más en estos conceptos en capítulos posteriores de este tutorial. De momento diremos que en el caso de la petición HTTP podemos enviar información adicional (normalmente los datos de un formulario web), y que en el caso de la respuesta HTTP recibiremos el contenido HTML, el lenguaje de marcado que utilizará el navegador para visualizar la página.

Afortunadamente ASP.NET (y todos los framework de desarrollo web) encapsulan el manejo de la solicitud y la respuesta en objetos de fácil acceso.

Servidores DNS

Falta aún por introducir un elemento importante. Los servidores en internet (en realidad cualquier ordenador dentro de una red) se identifica por una direccion IP. Sin embargo, en el ejemplo anterior, al proporcionar la URL, no nos hemos referido a una dirección IP, sino al nombre del servidor (mas concretamente al nombre de “dominio”). Entonces … ¿Como sabe el navegador que un determinado servidor “www.devjoker.com” se corresponde con una dirección IP concreta? La respuesta es simple: Los servidores DNS.

Un servidor DNS es una especie de “centralita de internet”, de forma que cuando un navegador solicita una URL a un servidor desconocido, primero se consulta la “centralita” para obtener la dirección IP. Por motivos de rendimiento, una vez que se ha resuelto el nombre de dominio se almacena localmente para que no sea necesario volver a preguntar.

Podemos realizar consultas directamente al servidor DNS con la aplicación nslookup:

Microsoft Windows [Versión 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Reservados todos los derechos.
C:\Users\pedro_herrarte>nslookup
Servidor predeterminado: google-public-dns-a.google.com
Address: 8.8.8.8
> devjoker.com
Servidor: google-public-dns-a.google.com
Address: 8.8.8.8
Respuesta no autoritativa:
Nombre: devjoker.com
Address: 188.165.132.77
> 188.165.132.77

En el ejemplo anterior estamos utilizando los servidores DNS de Google (IP 8.8.8.8).

Por ultimo, nos faltaría conocer como es capaz el servidor DNS de obtener la IP correcta de nuestro servidor www.devjoker.com. Cuando registramos un dominio en internet, debemos configurar dicha información a través del panel de control DNS (opción que proveen TODOS los registradores de dominio … ¿TODOS? NO! MoviStar no te permite configurar los registros de DNS y te obliga a contratarlo como servicio aparte. Mi recomendación es que NUNCA registréis un dominio con MoviStar). De este modo, publicamos que nuestro nombre de dominio “devjoker.com”, se corresponde un servidor (o conjunto de servidores) con una dirección IP concreta.

La siguiente imagen muestra la configuración DNS de devjoker.com:

De un modo similar funciona el envío de correos electrónicos, con las salvedad de que el servidor DNS es consultado para registros de tipo MX – Mail eXchange, es decir, que para que nuestro servidor sea capaz de enviar y recibir correos debemos haber configurado correctamente ambos servidores y haber configurado los servidores DNS adecuadamente.

Protocolo HTTP

El protocolo de comunicaciones que se utiliza para solicitar y recibir páginas web es HTTP. HTTP es el acrónimo de HyperText Transfer Protocol, siendo el aspecto mas relevante que se trata de un protocolo de transmisión de texto. Solo texto. Es sumamente importante entender este aspecto, ya que condiciona como funciona la web.

Si analizamos los elementos base en los que sostiene la web hoy en día, nos encontramos los siguientes elementos fundamentales:

El lenguaje para la definición de los elementos de una página y su contenido es texto – HTML. Veremos una pequeña introducción a HTML en el siguiente capitulo.
El lenguaje para la definición del aspecto visual de la página es texto. CSS. También veremos una introducción a CSS en este tutorial.
El lenguaje para la programación del lado del cliente JavaScript, que se recibe en cuerpo de la respuesta como texto, y se compila e interpreta en el cliente. (Esto tiene interesantes matices, como la posibilidad de escribir código dinámicamente en el servidor …)

HTTP es un protocolo sin estado, es decir, HTTP no guarda ninguna información sobre conexiones anteriores. Esto significa que cuando enviamos varias solicitudes HTTP, la solicitud actual no conoce en los datos que han enviado y recibido las peticiones anteriores.

Por ejemplo, si en una primera solicitud enviamos la información de un usuario, y luego visitamos una segunda página, esta segunda página no sabe que usuario utilizamos en la anterior. Este es un factor que condiciona completamente la forma de trabajar cuando desarrollamos aplicaciones web, ya que al no proporcionarnos esta información el protocolo vamos a tener que realizarlo a nivel de aplicación.

Además las peticiones HTTP responden a una serie de “verbos” predefinidos, según el verbo de la solicitud el servidor actuará de una forma u otra. Los verbos mas comunes son GET y POST, aunque existen mas. Veremos mas adelante que ASP.NET MVC permite especificar que un método de un controlador responda únicamente a un conjunto de verbos concretos.

Cuando veamos la parte dedicada a AJAX y jQuery veremos que existen métodos $.get() y $.post() para realizar peticiones utilizando uno u otro verbo de forma simple desde JavaScript.

Ha continuación vamos a ver un par de ejemplos sobre GET y POST.

GET
Solicita un recurso especifico. Se utiliza sobre todo cuando solicitamos un recurso sin necesidad de enviar información adicional, aunque el verbo GET permite enviar datos adicionales como parte de la URL solicitada, su uso debe realizarse con cuidado, ya que es una información que un usuario malintencionado podría modificar para realizar un ataque.

GET /images/logo.png HTTP/1.1 obtiene un recurso llamado logo.png

POST
Envía los datos incluyéndolos en el cuerpo de la petición. Es muy habitual para el envío de datos (a través de formularios), en los que el usuario rellena cierta información y la envía al servidor.

POST http://devjoker.com/login.aspx HTTP/1.1

Accept: text/html, application/xhtml+xml, */*

Accept-Language: es-ES

User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

Host: devjoker.com

Content-Length: 650

Connection: Keep-Alive

Pragma: no-cache

UserName=nombreUsuario&Password=laclave

El ejemplo anterior corresponde a la captura de una petición HTTP de un formulario de identificación de usuario a través de POST. Podemos ver que la información se envía en el cuerpo de la petición, y fácilmente podemos obtener el usuario y el password, siendo muy fáciles de capturar (al menos desde el propio equipo que realiza las peticiones!). Es por este motivo, por el existe una versión cifrada de HTTP – HTTPS –, que se encarga de cifrar todas comunicaciones que se producen entre el navegador y el servidor. Es un aspecto que tendremos que tener en cuenta siempre que nuestras aplicaciones requieran del manejo de datos sensibles.

Por último, comentar que HTTP responde a cada petición con un código de estado predefinido que permite al navegador identificar que acción debe realizar. A continuación vamos a ver algunos de los códigos HTTP mas comunes.

Códigos de estado HTTP.

Cada respuesta HTTP identifica el resultado de la petición a través de un código HTTP. Dependiendo de este código de respuesta de HTTP el navegador realizará una acción u otra. Por ejemplo, mostrará la pantalla solicitada si el estado es 200 (OK) o mostrará la pantalla de error en caso de que reciba un error 500 (error de servidor).

Los códigos de error de HTTP con códigos numéricos, agrupados en familias por centenas. De forma que los errores 200 corresponden a peticiones correctas, los errores 300 redirecciones, los 400 errores en la petición y los errores 500 errores de ejecución del lado del servidor.

De manera muy breve veremos los principales códigos de respuesta de HTTP.

200 OK

Indica que el servidor a obtenido y enviado correctamente el recurso solicitado por la petición. En este caso el cuerpo de la respuesta contendrá el contenido en texto (HTML, CSS, Javascript, etc) del recurso solicitado, permitiendo al navegador mostrarlo en la pantalla.

El siguiente ejemplo muestra una petición GET al recurso http://devjoker.com :

GET http://devjoker.com/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: es-ES
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: devjoker.com
If-Modified-Since: Sun, 19 Aug 2012 22:22:57 GMT
Connection: Keep-Alive

Y la respuesta obtenida:

HTTP/1.1 200 OK
Cache-Control: public, max-age=10
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Expires: Sat, 22 Sep 2012 22:37:05 GMT
Last-Modified: Sat, 22 Sep 2012 22:36:55 GMT
Vary: Accept-Encoding
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Sat, 22 Sep 2012 22:36:56 GMT
Content-Length: 9357
<html>
…
</html>

La respuesta incluye el código HTML de la página que permitirá al navegador mostrar el contenido solicitado. Por razones de espacio se omite el contenido HTML en este ejemplo.

301 Redirección permanentemente.

Ésta es la opción más habitual en el caso de migraciones o cambios de dominio, indica al navegador que el recurso solicitado no ha cambiado de ubicación y que debe solicitar una nueva URL. Además le insta a modificar cualquier enlace que conserve almacenado o información asociada a dicha URL (como por ejemplo, el índice de Google o Bing). Una redirección 301 es interpretada por los motores de búsqueda de forma que implica que toda la información asociados a la página original se transmitan a la de destino, por lo que es el más aconsejable para trasladar contenido.

302 Found.

Indica que un recurso ha sido localizado pero que no ha sido devuelto como parte de la respuesta, indicando una nueva localización para el recurso. Está es la opción que se utiliza cuando queremos efectuar la redirección de un recurso a otro diferente. El código 302 se suele usar para todos los traslados temporales, donde el servidor responde al navegador indicándole una nueva URL con el nuevo recurso. Es el navegador el que interpreta este código y realiza una nueva petición (esta vez al nuevo recurso). El siguiente ejemplo muestra una respuesta HTTP 302 en la que navegador redirecciona a un nuevo recurso (Location: /private/index.aspx)

HTTP/1.1 302 Found

Cache-Control: private, no-cache="Set-Cookie"

Content-Type: text/html; charset=utf-8

Location: /private/index.aspx

También Es muy común utilizar el código 302 para controlar la navegación dentro de un sitio web.

304 Not Modified.

Básicamente indica que el contenido no se ha modificado desde la última vez que se solicitó. Lo mas normal es que nunca se provoque este estado a propósito, sino que dejemos al servidor decida cuando usarlo. La consecuencia directa en que cuando un navegador recibe esté código, la respuesta no contiene contenido alguno es el cuerpo – el recurso se obtendrá del los archivos temporales almacenados por el navegador en peticiones anteriores. Por ejemplo, si una página no se ha modificado, no se transmite de nuevo el contenido de la misma, simplemente se indica que no se ha modificado a través del código 304 y el navegador utiliza la última versión de la que dispone.

HTTP/1.1 304 Not Modified

Last-Modified: Mon, 06 Aug 2012 17:12:08 GMT

Accept-Ranges: bytes

ETag: "35ec559cf673cd1:0"

Server: Microsoft-IIS/7.5

X-Powered-By: ASP.NET

Date: Sat, 22 Sep 2012 22:36:58 GMT

Podemos entender mejor este código de estado si pensamos en una imagen que se muestra en una página web, la primera vez que visitamos la página el servidor nos entrega la imagen, pero en peticiones sucesivas se detecta que la imagen no se ha modificado y se utiliza la versión que se descargo la ultima vez.

400 Bad Request.

Este código indica que la solicitud no está correctamente formada. Normalmente se produce este error cuando la URL no es correcta.

HTTP/1.1 400 Bad Request

Otros errores de la familia 400 son:

401 No autorizado
402 Pago requerido
403 Prohibido

404 Not Found.

Sin lugar a dudas el error mas común. Indica que a pesar de que la petición es correcta el recurso solicitado no existe en el servidor. Normalmente esto se produce debido a que la URL apunta a un recurso que no existe en el servidor, pero también es posible que el servidor este ocultando el recurso intencionadamente.

HTTP/1.1 404 Not Found

Content-Type: text/html

Server: Microsoft-IIS/7.5

X-Powered-By: ASP.NET

Date: Sat, 22 Sep 2012 22:51:04 GMT

Content-Length: 1245

También se puede producir un error 404 cuando el servidor no tiene configurado el tipo de recurso correctamente.

405 Method Not Allowed.

Este código indica que el verbo utilizado en la petición no es válido. Se incluye como parte de la respuesta los verbos admitidos por el recurso.

HTTP/1.1 405 Method Not Allowed

Allow: GET, HEAD, OPTIONS, TRACE

Content-Type: text/html

500 Server Error

La familia de errores 500 corresponden con errores de servidor. Se pueden deber a multitud de causas, ya que suelen corresponder con un error de nuestra aplicación. Por ejemplo, si en nuestro programa cometemos un error de programación e intentamos realizar una división por cero, el cliente recibirá un error 500 como resultado de la respuesta.

También se produce un error 500 cuando el servidor no dispone de los recursos necesarios para atender la petición.

El siguiente ejemplo muestra un ejemplo de petición a devjoker.com en el que hemos detenido intencionadamente la aplicación. En este caso obtenemos un error con código 503 que nos indica que la aplicación no está disponible – 503 Service Unavaileable.

GET http://devjoker.com/ HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: es-ES
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept-Encoding: gzip, deflate
Host: devjoker.com
Connection: Keep-Alive
-----------------------------------------------------------------------------------------------------------------------------------
HTTP/1.1 503 Service Unavailable
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Sat, 06 Oct 2012 15:41:03 GMT
Connection: close
Content-Length: 326
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">
<HTML><HEAD><TITLE>Service Unavailable</TITLE>
<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>
<BODY><h2>Service Unavailable</h2>
<hr><p>HTTP Error 503. The service is unavailable.</p>
</BODY></HTML>

Los errores 500 definidos son: 501 No implementado, 502 Pasarela incorrecta, 503 Servicio no disponible, 504 Tiempo de espera de la pasarela agotado y 505 version not suported.

505 HTTP Version Not Supported.

Este error se produce cuando la petición solicita una versión de HTTP no soportada por el servidor. El siguiente ejemplo muestra una petición HTTP 2.0, y el error devuelto indicando que el servidor no soporta esta versión de HTTP.

GET http://www.devjoker.com/ HTTP/2.0

Host: www.devjoker.com

-------------------------------------------------------------------

HTTP/1.1 505 HTTP Version Not Supported
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0

Un estudio mas detallado del HTTP escapa completamente del ámbito de este tutorial donde solo pretendemos dar una breve introducción para facilitar los conceptos de programación con ASP.NET MVC que veremos en capítulos posteriores.

Analizar el trafico HTTP.

Si queremos analizar el tráfico HTTP directamente podemos hacerlo directamente utilizando las herramientas de desarrollo que incorporan casi todos los navegadores (pulsando F12), o bien a través de herramientas especificas como Fiddler.

La siguiente imagen muestra Fiddler utilizado para capturar el tráfico.