ClientResourceManager la pieza olvidada en ASP.NET MVC

Muchas veces, cuando se comienza a escribir una aplicación desde cero, es frecuente incluir un archivo con los scripts que se van a ejecutar en el cliente (aka javascript). Resulta que cuando la aplicación comienza a crecer, este archivo se vuelve inmanejable, más aún cuando otros desarrolladores se incorporan al proyecto, aún así tiene una “ventaja” y es que en ese archivo está todo, no hay que buscar nada en otro lugar, y lo fundamental, con que se haga referencia a este archivo es suficiente para que la interfaz funcione bien.

Con esto muchos pensarán que es mejor tenerlo todo en un solo archivo, sin embargo, para mantener el código lo más “higiénico” se recomienda escribir pequeños módulos que sean fácilmente actualizables. Esto trae consigo problemas que antes no se tenían como puede ser la dependencia entre los diferentes módulos. Por ejemplo, si una página requiere una funcionalidad implementada en un determinado módulo (archivo js), y a su vez, dicho módulo depende de otro módulo (otro archivo js), entonces es necesario referenciar ambos módulos en la página (escribir 2 secciones <script>). Peor aún, muchas veces se tiende a escribir una pequeña funcionalidad de la página en una especie de componente (UserControl, Include, Partial o como le quiera llamar) que requiere de la presencia de algún script, en ese caso se debe estar atento e incluir las referencias que necesita en la página que está usando el componente.

Para evitar lo anterior surge el ClientResourceManager. La responsabilidad de este componente es administrar los recursos que se descargan al cliente, fundamentalmente archivos JavaScript y CSS. En la siguiente figura se muestra un diagrama de clases con la estructura básica de nuestro componente.

Proyectando grandes Datasets en Google Maps

Proyectar información georeferenciada de nuestro sistema con Google Maps es un proceso que se logra con relativa facilidad. Sin embargo cuando el volumen de información que se muestra comienza a crecer, el mapa se vuelve prácticamente inservible pues es imposible localizar algo con facilidad.

Es en este punto cuando se comienza a buscar alguna solución a este “agradable” problema. Rápidamente te das cuenta que necesitas de alguna forma “agrupar” (cluster en inglés) información y por ahí comienzas a trabajar.

Muchos métodos de agrupamiento en el fondo se parecen. Básicamente se trata de agrupar datos siguiendo algún criterio. Para esto se necesita alguna ecuación que nos indique cuán parecidos son 2 elementos, se define un umbral y los datos que no sobrepasen dicho umbral conforman el clúster. En nuestro caso, el criterio que se sigue es hallar la distancia que existe entre 2 puntos, si esa distancia es menor que un umbral que se defina entonces se agrupan. En la siguiente figura se muestra el resultado final, también se puede ver en la dirección http://www.chil.es/yellowpages
 

Publicando contenido de nuestro sitio en Facebook

Resulta muy divertido publicar en Facebook pero más aún si se hace a través del código.

Recientemente recibimos una solicitud, de esas que a veces no queremos oír, de publicar parte del contenido que los usuarios subían a nuestro sitio, a la página oficial del sitio en Facebook. Aunque parecía algo disparatado al inicio, tenía su encanto, así es que aquí les comento la solución que encontramos.

Pues bien, lo primero que hicimos fue crear una página en Facebook lo cual resultó sumamente sencillo, como era de esperar. Luego creamos una aplicación en Facebook y por último vino el problema de verdad, ver cómo publicar en esa página, el contenido subido por los usuarios a nuestro sitio a través de la aplicación, es en este punto donde aparece el Graph API.

También el API resultó sencillo de usar, está basado en REST y bastante bien documentado, lo otro que necesitamos es una biblioteca que nos ayude, en nuestro caso usamos el Facebook C# SDK.

Veamos un poco la arquitectura que seguimos para este problema. Cuando un usuario publica un contenido en nuestro sitio y decide que desea también publicarlo en Facebook, no se publica de manera automática (sería un costo en tiempo que puede llegar a ser perjudicial), lo que hacemos es enviar un mensaje a una cola con los datos del contenido que deseamos publicar. Luego, existe un proceso en background que es el encargado de tomar estos datos y hacer la publicación en Facebook.

Es en este último punto donde aparece un problema, el contenido no se va a publicar en el muro del usuario sino en la página de nuestro sitio en Facebook y la idea es que parezca que la propia página es quien publica el contenido. Pueden ver el resultado final en la siguiente imagen o con más detalle en la página Chil Social Network en Facebook.

 

Para que parezca que es la propia página la que publica el contenido necesitamos de alguna manera obtener el access_token de esa página, lo cual está descrito en la documentación de Facebook y más concretamente en el apartado “Page Login”.

Autenticación de usuarios contra Facebook y OpenId

Para los usuarios resulta cómodo poder acceder a nuestro sitio web con las mismas credenciales que usan para entrar a sus sitios habituales, es por eso que en nuestro equipo nos planteamos implementar un mecanismo que permitiera entrar en nuestro sitio con su cuenta de Google, Yahoo! o Facebook.
Para Google y Yahoo!  es posible usar OpenId pero con Facebook la técnica cambia. Suena interesante, veamos qué podemos hacer.

Lo primero que haremos es definir un esquema común de autenticación, para esto definimos la interface IAuthenticationProvider como se muestra en esta figura:

La interface consta del método Authenticate que es el encargado de gestionar el permiso contra el proveedor (Facebook, Google o Yahoo!)  y de la propiedad ProviderId que nos puede servir para identificar el IAuthenticationProvider contra el que se autentica el usuario en algún repositorio. Las clases FacebookAuthenticationProvider y OpenIdAuthenticationProvider implementan la inerface IAuthenticationProvider para autenticar el usuario contra Facebook y contra Google y Yahoo! respectivamente.

La primera vez que se hace una llamada al método Authenticate de IAuthenticationProvider se retorna un objeto AuthenticationResult con el estado “Initializing” y  la URL a la cual debemos redireccionar al usuario en la propiedad InitializingUrl. En dicha URL el proveedor mostrará una interfaz donde el usuario introducirá sus credenciales, la imagen que sigue es la interfaz de autenticación de Facebook.

Una vez que el usuario ha sido autenticado, el proveedor (en este caso Facebook) nos debe redireccionar nuevamente a nuestra aplicación. Esta vez se invoca nuevamente el método Authenticate y ahora debe retornar un objeto de tipo AuthenticationResult con un estado que indique que el usuario ha sido autenticado con éxito (Authenticated) así como los datos del usuario autenticado en la propiedad UserData. Con estos datos podemos registrar al usuario en nuestra aplicación o hacer cualquier otra cosa que deseemos.