Muy buenas! Después de largo tiempo vuelvo a la carga con otro post sobre ASP.Net WebApi. En un post anterior vimos como WebApi usaba automáticamente el verbo http usado para invocar el método correspondiente del controlador. Eso está muy bien en aquellos casos en que el cliente es una aplicación de escritorio y tiene acceso a todos los verbos http posibles. Pero si el cliente es una aplicación web es posible que tan solo tenga acceso a dos de los verbos http: GET y POST.

¡Buenas! Este post está “inspirado” por un tweet de Gisela Torres. Posteriormente ella misma hizo un post en su blog sobre este mismo patrón que os recomiendo leer. Ultimamente está muy de moda, al menos en el mundo de Javascript, hablar del Promise pattern (lo siento, pero llega un punto en que yo ya desisto de intentar encontrar traducciones para todo…). Ese patrón se asocia mucho con la realización de aplicaciones asíncronas, llegándose a ver como el mecanismo para la realización de este tipo de aplicaciones.

En el post anterior vimos como integrar pseudo-autenticación basada en oAuth en aplicaciones MVC4, usando el paquete Microsoft WebPages OAuth Library. Pero… qué ocurre con versiones anteriores? O bien si no queréis usar este paquete? Es muy difícil integrar pseudo-autenticación basada en oAuth entonces? Hace algún tiempo tuve precisamente esta necesidad y estuve buscando librerías que me permitiesen integrar oAuth en mi aplicación de una forma cómoda. Como todo el mundo terminé por encontrar DotNetOpenAuth pero al final no la usé.

¡Buenas! Una de las novedades de ASP.NET MVC4 es la facilidad para incorporar pseudo-autenticación basada en oAuth. Si seleccionamos la plantilla de proyecto de “internet application” esta ya viene configurada por defecto y usarla es de lo más sencillo. Veamos ahora como añadirla en el caso de que estemos usando otra plantilla de proyecto. En este caso usaremos la plantilla de proyecto “Empty” que en el caso de MVC4 significa vacío de verdad, ya que no tendremos apenas nada en nuestro proyecto.

Bueno… sigamos con otro post sobre esta serie en la que vamos hablando de cosas sobre knockout. Y en esta ocasión toca hablar de como validar los campos que tengamos enlazados en un formulario. Dado que estamos moviendo toda nuestra lógica al viewmodel de cliente, es lógico asumir que las validaciones irán también en él, en lugar de estar “ancladas” al DOM como ocurre cuando usamos jQuery validate, p.ej. Si usamos knockout lo normal es tener los campos de nuestro formulario enlazados con propiedades de nuestro viewmodel.

Muy buenas! Puro divertimento 🙂 Os propongo un kata por si quereis entrenar las neuronas. Por supuesto no es un kata original mío (soy muy malo para eso), de hecho es un kata creo que bastante famosillo, pero es uno con el que me he enfrentado no hace mucho… El enunciado es muy simple… Crear una función que reciba dos parámetros: Un entero que represente una cantidad de dinero, y una colección que represente los tipos de monedas de los que disponemos.

Muy buenas! Tras un parón, volvemos a la carga con la serie que trata sobre knockoutjs. Recuerda que puedes ver todos los artículos de esta serie. En este post vamos a ver como filtrar colecciones con knockout. Como siempre comenzamos con una clase Beer y un controlador de WebApi que devuelva una colección de elementos Beer. La clase Beer es tal como sigue: public class Beer {     public string Name { get; set; }     public string Brewery { get; set; }     public int Ibu { get; set; } } Bien, ahora vamos a realizar una vista (Home/Index) que me muestre el listado de cervezas.

Disclaimer: Este post es un poco distinto al resto de posts de esta serie sobre knockout. De hecho no tenía presente escribirlo pero lo he hecho cuando he visto la cantidad de preguntas relativas a ello que aparecen por Google. Aunque lo he reescrito varias veces, entiendo que puede ser un post durillo de leer, especialmente si no se tiene experiencia previa en ASP.NET MVC. Si NO quieres leerte este post, no te preocupes: no es necesario para nada para entender el resto de posts de la serie, ni explica nada nuevo sobre knockout que no hayamos vistos en los 3 anteriores.

Bueno, continuamos aquí nuestra serie explorando las maravillas de Knockout. Todos los posts de esta serie los podéis encontrar en: http://geeks.ms/blogs/etomas/archive/tags/knockout/default.aspx Serializando viewmodels En el post anterior, vimos los observables de knockout y como funcionaban. Vimos como crear un formulario, enlazarlo a un viewmodel que usara observables y como mandar el viewmodel serializado en json hacia un servicio REST. Ciertamente, el tema de la serialización a JSON de nuestro viewmodel era un poco peliagudo.

Nota: Este post está basado en la versión RC de VS2012 y la versión RC de MVC4 y es posible (o eso espero, vaya!) que en la versión final no haya los problemas que este post menciona! Buenas! Coje un VS2102RC y crea un nuevo proyecto ASP.NET MVC4, con la plantilla “Basic”. Crea el HomeController, crea la acción Index y añádele un código tal como: 1: public ActionResult Index() <p> <!