Infragistics Html Editor y el Encode/Decode.

Como he perdido un ratito largo con el Html Editor de Infragistics, voy a comentarlo por aquí y así me sirve de recordatorio.

En un proyecto MVC he añadido a la vista el controlito para poder editar texto en negrita, cursiva, etc. y luego guárdalo en la base de datos en formato HTML.

Pero claro, al principio me sorprende que lo que le llega al controlador cuando grabo en la vista está completamente “encode”, algo similar a “%3Cp%3Ei.%20listado%3C/p%3E!” y claro, esto no me vale para nada, vaya!, que lo que yo necesito es el HTML del texto que he escrito.

Ahora está claro, pero al principio no lo veía. Por cosas de seguridad completamente normales, el texto “viaja” así entre cliente y servidor (normal) y luego cuando llega al controlador, pues solo hay que “decode”.

Nada, una chorrada pero que si te pilla con el “celebro” saturado, pues no caes.

 

Fuente: http://igniteui.com/html-editor/aspnet-mvc-helper

http://www.infragistics.com/community/forums/p/80851/434201.aspx#434201

Anuncios

Actualizar propiedad del ViewModel (y oculta en la View) con otro elemento visible.

Imaginemos que utilizamos un editor HTML que hemos encontrado por internet, este editor nos permite escribir código HTML.

Ahora bien, aquí no podemos usar un HtmlHelper en la vista para editar la propiedad que hará referencia al contenido de este editor, por lo que la solución es poner nuestra propiedad del viewModel: “Contenido” como oculta, y posteriormente actualizarla con el contenido del editor de HTML. De ese modo, al hacer el POST, nuestro controlador ya tendrá el valor de la propiedad con el texto que hayamos metido en el editor.

submit1: botón

editor1: widget que nos permite editar código HTML

Contenido: propiedad del viewmodel que debe almacenar el texto HTML editado

 

VISTA:

(Elemento oculto del modelo)

@Html.HiddenFor(x=>x.Contenido)

(Actualizo el elemento oculto con el valor de otro que sí es editable)

 

$(document).ready(function
()
{

$(“#submit1”).click(function
()
{


var texto = $(“#editor1”).html();

 

$(“#Contenido”).val(texto);

 


});


});

 

Ahora desde el controlador ya puedo leer el valor actualizado de “Contenido”.

Cómo añadir el ID a una fila en Infragistics igGrid con ASP.NET MVC

Al añadir una fila en la rejilla, el igGrid tiene formas de poder calcular el nuevo Id de la fila mediante propiedades y eventos en jQuery, pero cuando este Id, viene dado desde el controlador, hay que hacer un pequeño “invento”.

Es sencillo, pero hay que saberlo. El controlador debe pasarle a la vista los nuevos Ids mediante Json, y ya en la vista, un evento del igGrid se encargará de actualizar el Id de la nueva fila.

Sería algo parecido a:

CONTROLADOR:

public ActionResult SaveProducts()

 

{

 

GridModel m = new GridModel();

 

List<Transaction<Product>> transactions = m.LoadTransactions<Product>(HttpContext.Request.Form[“ig_transactions”]);

 

List<Ids> ids = new List<Ids>();

 

int newId = 0;

 

foreach (Transaction<Product> t in transactions)

 

{

 

if (t.type == “newrow”)

 

{

 

// repository Add mehtod returns the new id generated from the underlying data source

 

newId = productsRepository.Add(t.row);

 

ids.Add(new Ids() { OldId = t.row.ProductID, NewId = newId });

 

}

 

}

 

JsonResult result = new JsonResult();

 

Dictionary<string, object> response = new Dictionary<string, object>();

 

response.Add(“Success”, true);

 

response.Add(“ids”, ids);

 

result.Data = response;

 

return result;

 

}

========================

VISTA:

=======================

$.ig.loader(function () {

 

$(“#grid1”).data(“igGrid”).dataSource._addChangesSuccessHandler(function (data) {

 

var i;

 

for (i = 0; i < data.ids.length; i++) {

 

$(“#grid1”).igGridUpdating(“setCellValue”, data.ids[i].OldId, “ProductID”, data.ids[i].NewId);

$(“#grid1 > tbody > tr[data-id='” + data.ids[i].OldId + “‘]”).attr(“data-id”, data.ids[i].NewId);

}

 

$(“#grid1”).data(“igGrid”).dataSource.commit();

 

$(“#grid1”).data(“igGrid”).dataSource.allTransactions().length = 0;

});

 

});

 

 

Fuente: http://www.infragistics.com/community/forums/p/84192/420302.aspx#420302

Diferencias MVC y WebForms.

1.1 MVC.

Podríamos definir MVC como un patrón arquitectural que describe una forma de desarrollar aplicaciones software separando los componentes en tres grupos (o capas):

•El Modelo que contiene una representación de los datos que maneja el sistema, su lógica de negocio, y sus mecanismos de persistencia.

•La Vista, o interfaz de usuario, que compone la información que se envía al cliente y los mecanismos interacción con éste.

•El Controlador, que actúa como intermediario entre el Modelo y la Vista, gestionando el flujo de información entre ellos y las transformaciones para adaptar los datos a las necesidades de cada uno.

MVC son las siglas de Modelo-Vista-Controlador, y se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo.

1.2 Ventajas MVC.

· Clara separación de responsabilidades entre interfaz, lógica de negocio y de control, que además provoca parte de las ventajas siguientes.

· Produce un código más limpio y estructurado, independizando totalmente la interfaz de la lógica de navegación y, por supuesto, de la de negocio.

· Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD) y técnicas avanzadas de mocking.

· Simplicidad en el desarrollo y mantenimiento de los sistemas: el conjunto de convenciones en cuanto a la estructura de proyectos y de nombrado y disposición de elementos facilita el desarrollo una vez son asimiladas.

· Reutilización de los componentes.

· Facilidad para desarrollar prototipos rápidos.

· Sencillez para crear distintas representaciones de los mismos datos.

· Los sistemas son muy eficientes, y a la postre más escalables.

· Fácilmente se puede utilizar DI (dependency injection): es una técnica que permite realizar aplicaciones cuyos componentes se encuentran muy desacoplados entre sí, lo que flexibiliza el diseño y, por ejemplo, facilita la realización de pruebas unitarias.

· Se trata de un patrón muy fácilmente implementable y que nos puede aportar muchos beneficios.

· Integración sencilla del framework MVC con soluciones basadas en cliente, como jQuery y su interminable colección de plugins, en los que podemos encontrar elementos de interfaz para prácticamente cualquier necesidad.

· Las direcciones amigables, es un beneficio directo del uso del framework de Microsoft, estrictamente hablando no es mérito de la plataforma MVC, sino del juego de clases presentes en el espacio de nombres System.Web.Routing, incluidas en .NET , con las ventajas que ello conlleva (SEO, REST, claridad en direcciones, etc.).

· La ausencia de automatismos y persistencia de estado aligera en gran medida el peso y complejidad de las páginas, lo cual redunda en el rendimiento del sistema.

· Existen multitud de frameworks MVC para ASP.Net, como MonoRail, Maverick.Net, FubuMVC y muchos otros.

· Es un framework con licencia MS-PL (Microsoft Public License), por tanto es libre, y permite su uso en aplicaciones comerciales.

· Flexibilidad de la arquitectura de ASP.NET MVC framework en la utilización de motores de vistas distintos al estándar.

1.3 Inconvenientes MVC.

· Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del proyecto. De hecho, hay problemas que son más difíciles de resolver.

· Al principio cuesta cierto esfuerzo adaptarse a esta filosofía, sobre todo a desarrolladores acostumbrados a otros modelos más cercanos al escritorio, como Winforms.

· La distribución de componentes obliga a crear y mantener un mayor número de ficheros.

· En general requiere de más código que WebForms.

· Existe un número ingente de componentes y controles reutilizables disponibles para Webforms. Dado que no son compatibles con el framework MVC, se parte de una situación de clara desventaja frente a estos, aunque esto está ya cambiando y seguro que con el tiempo mejorará.

· Requiere un conocimiento más profundo del entorno web y sus tecnologías subyacentes, puesto que a la vez que ofrece un control mucho más riguroso sobre los datos que se envían y reciben desde el cliente, exige una mayor responsabilidad por parte del desarrollador, ya que deberá encargarse él mismo de mantener el estado entre peticiones, maquetar las vistas, crear las hojas de estilo apropiadas, e incluso los scripts.

1.4 Ventajas WebForms.

· La tecnología de formularios web permite el desarrollo rápido de aplicaciones (RAD) a través de diseñadores visuales con los que es posible componer una página compleja y definir el comportamiento del interfaz a golpe de ratón, puesto que el framework se encarga de realizar parte del trabajo duro, como el mantenimiento del estado entre peticiones, convertir propiedades de controles en código HTML y CSS, o incluso generar scripts que realicen determinadas tareas en cliente.

· Es posible crear aplicaciones para Internet sin tener apenas idea de las particularidades inherentes al desarrollo web, lo que permite que muchos programadores procedentes del mundo del escritorio puedan ser productivos muy rápidamente, aunque sea a costa de generar páginas mucho más pesadas y con un código de marcado complejo.

· Si el equipo de desarrollo tiene ya experiencia creando aplicaciones con WinForms y no posee grandes conocimientos sobre programación web de más bajo nivel ni experiencia previa trabajando con el patrón MVC, esta tecnología va a permitir una mayor productividad del equipo.

· La última versión del framework ya permite direcciones amigables.

1.5 Inconvenientes WebForms.

· Problemas en la separación de código e interfaz.

· Dificultad para realización de pruebas unitarias.

· Podemos decir, que todas las ventajas de MVC, no se producen en WebForms, con todos los inconvenientes que esto conlleva.

· Puede producir comportamientos extraños cuando intentamos intervenir en el ciclo de vida de las páginas, por ejemplo para la carga y descarga de controles dinámicos.

· No hay control sobre el código HTML generado si se utilizan controles de servidor, por lo que a veces, es difícil conseguir el resultado deseado.

· Las páginas son mucho más pesadas debido al viewstate.

1.6 Principales diferencias.

MVC es radicalmente distinto al uso de formularios web, algunas de las principales características que destacaría son:

· No existe el postback.

· No hay viewstate.

· No hay eventos.

· El diseñador visual deja de tener sentido.

· No hay controles de servidor, al menos en la forma en que los conocemos en WebForms.

· No es necesario utilizar los archivos code-behind de las páginas .aspx.

· Las páginas no siguen complejos ciclos de vida, el proceso de una petición es infinitamente más simple que en WebForms.

· Control total del código de marcado generado.

· Podemos sustituir componentes internos del framework para adaptarlo a nuestras preferencias.

· Se integra con Ajax de forma natural, sin artificios como los UpdatePanels y similares.

· Favorece la introducción de buenas prácticas como la inversión de control o inyección de dependencias.

· Diferencias entre code-behind y MVC controllers: aparentemente hay similitudes entre ambos, ya que estos contienen la lógica de la aplicación, sin embargo la página aspx no se puede separar del code-behind, ambas trabajan unidas para implementar la lógica de la aplicación y la lógica de presentación, pero en MVC es diferente, hay una clara separación entre la vista (UI) y los controladores, que son una representación abstracta de la interacción con el usuario. Esto permite un código más simple, por lo que la aplicación es más fácil de entender y mantener.

1.7 Experiencia personal.

Particularmente, tras realizar ambas web, las mayores diferencias que he encontrado ya se han comentado con anterioridad, pero enfatizaría la facilidad que proporciona WebForms, seguramente por su proximidad a WinForms, el uso de controles de servidor implica no tener que hacerlo prácticamente todo manual, como en MVC. La cantidad de código de la primera, refiriéndome solo a la capa de presentación, es casi la mitad que en MVC. Sin embargo, en ésta, al controlar exactamente el código HTML generado, no he tenido tantos problemas a la hora de presentar los datos en la página. La validación sin embargo, me ha parecido más simple en MVC gracias al uso de metadata en la definición de las clases.

2. Conclusiones.

Desde el nacimiento de la World Wide Web hasta la actualidad, hay un verdadero abismo tecnológico y conceptual. No solo se ha evolucionado en la parte visual que utiliza el usuario, sino en la parte que no se ve. ASP.NET permite crear aplicaciones web de un modo muy productivo, proporcionando una visión moderna, interactiva y escalable de la red. Las mejoras ofrecidas por Visual Studio 2010, ASP.NET 4.0 y en general todas las funcionalidades que permite el framework 4, permiten desarrollar una web de calidad en poco tiempo.

Visual Studio 2010 me ha permitido desarrollar la aplicación desde las primeras fases, integrándose perfectamente con todas las herramientas de Microsoft para facilitar el trabajo.

A pesar de las facilidades que proporciona WebForms, pienso que para una aplicación de una determinada envergadura, la mejor opción es MVC, por todas las ventajas y pocas desventajas, que ya se han comentado. A pesar de que tiene una mayor curva de aprendizaje que WebForms y de que la productividad es menor en un primer momento, a la larga, MVC será más fácil de entender y mantener. Pienso que es el patrón con más futuro a corto plazo y medio plazo, aunque WebForms no desaparecerá, por su simplicidad.