Html

Diseño / Futuro / Html / Internet / Jackfiallos / javascript / Ocio / Web — No Comments
17
abr 12

SVG una tecnología en extinción

No Gravatar
SVG Logo

SVG Logo

Hace algunas meses atrás parte de algunas de las características que pensaba desarrollar en Celestic .. y que aún se encuentran pendientes, era crear una especie de pizarra que permitiera a multiples usuarios escribir o hacer anotaciones en tiempo real.. para ese entonces pensaba en solamente 2 opciones, canvas o svg.. incluso escribí algunas pruebas de diferentes librerías y al final estuve muy certa de utilizar RaphaelJS, eso sobre cualquier librería para canvas.

En ese momento, html5 no estaba muy difundido y las librerías de canvas estaban muy verdes para utilizar alguna, al final Celestic se detuvo un poco y decidí centrar el desarrollo en otro tipo de características.. Han pasado 3 años desde que tuve en mente si utilizar svn sobre canvas.. y hoy estoy a punto de cambiar de idea.

Las tecnologías cambian de la noche a la mañana, un día una nueva herramienta de desarrollo esta en la cima y otro día simplemente cae .. y lo peor es que nosotros nos preparamos tanto tiempo para aprenderlas .. que un día nos deja de servir y tenemos que empezar desde cero con algo totalmente nuevo.

La web cambia rápido .. ahora parece que flash ya no es una tecnología en la que valga la pena invertir.. hemos de aceptar que tuvo su gran momento, años de desarrollo y grandes comunidades dedicándose a perfeccionar los métodos de codificación.. para que al final no quede en nada.. “nada es eterno”.

Entonces creo que con SVG esta ocurriendo una situación similar.. los equipos de escritorio tienen soporte para SVG, los equipos móviles no lo tienen y si lo tienen es con especificaciones diferentes.. el SVG es una tecnología en extinción, los navegadores se estan especializando en pintar (render) canvas de manera muy rápida.. igualmente algunos browsers preparan su javascript para utilizar aceleración por hardware, lo que hace de canvas la nueva tecnología ideal para dibujar sobre la web.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
Futuro / Html / Internet / javascript / moviles / Servicio / software / tecnologia / Tendencias / Web — 1 Comment
13
mar 12

Aplicaciones moviles – nativas vs web

No Gravatar
Aplicaciones nativas vs aplicaciones web moviles

Aplicaciones nativas vs aplicaciones web moviles

Ya desde el año pasado había estado dando pequeños pasos y haciendo pruebas de desarrollo para iPhone y Android, tratando de conocer las fuerzas y debilidades de estas plataformas, conociendo el flujo de trabajo y tiempos que podría tomar desarrollar una aplicación. Después de mis pruebas obtuve resultados y en la comparación fue cuando noté que es realmente caro desarrollar aplicaciones nativas para cada plataforma (iOS, Android, BlackBerry o Windows Phone).

Ahora con el auge de las aplicaciones web, el uso extensivo de javascript, css y estándares web.. veo una gran ventaja el desarrollar aplicaciones móviles web en lugar de aplicaciones nativas. Sé que este tema en la red es un debate de nunca terminar, pero no se trata de comparar ambas formas de desarrollo diciendo que una es mejor que otra.. Algunas aplicaciones hechas específicamente para los dispositivos móviles podrían portarse a una aplicación web y otras quizás no.. todo depende de la naturaleza de la aplicación y si o no debe de interactuar con el hardware.

Entonces que diferencias existen entre una aplicación nativa y una aplicacion web móvil ?

Las aplicaciones nativas realizan tareas específicas que podrían ser el uso de la agenda, grabar o reproducir música, tomar fotografías o utilizar el hardware del equipo al máximo para tener el mejor rendimiento en una aplicación.. como por ejemplo los juegos que necesitan muchos recursos para ejecutarse y disponen en su totalidad del procesamiento del equipo para funcionar. En cambio una aplicación web móvil es una pieza de software que simplemente dá acceso a herramientas de seguimiento visual, donde no es necesario interactuar con el equipo, por ejemplo los manejadores de tareas o aplicaciones donde solo se necesite ingresar información y ver resultados.

Y que tan fácil puede ser desarrollar una aplicación web para los móviles que sea compatible con cualquier dispositivo ?

Existen aplicaciones tales como Sencha, PhoneGap, Titanium, Rhomobile, ParticleCode, CoronaSDK, Mosync, etc… que se desarrollan como aplicaciones web o con una sintaxis muy similar y que al final se traducen las diferentes plataformas móviles.. claro, esto con algunas diferencias porque mientras unas aplicaciones traducen todo el código a código nativo, otras simplemente  crean una aplicación web y la dejan en un contenedor nativo que sería casi un browser personalizado. Este tipo de aplicaciones se conocen como aplicaciones Híbridas ya que utilizan ciertas características físicas de los equipos pero son básicamente aplicaciones web.

A su vez, existen frameworks para desarrollo de aplicaciones web que igualmente emulan apariencia y comportamiento de las aplicaciones nativas, tales como son: The-M-Project, jQuery Mobile, Sencha Touch, jQTouch, DHTMLX touch, SproutCore, etc.. solo que este tipo de herramientas no nos permiten utilizar las características del equipo y son aplicaciones netamente web que se montan en un servidor de aplicaciones y se sirven como sitios web.

En cuanto a las dificultades que podemos tener al desarrollar aplicaciones móviles con estas herramientas, pues para empezar es difícil que  existe una curva de aprendizaje que quizás será menos pronunciada que aprender el lenguaje nativo para desarrollar aplicaciones pero es tiempo al final de cuentas, fácil hasta el punto en que se comienza a pensar en componentes o funcionalidades específicas que aunque se pueden desarrollar en las aplicaciones web, puede que sea más complicado hacerlo o adaptarlo para todos los dispositivos y es ahí donde esta el reto (pensando en equipos móviles o tablets).

Que forma para desarrollar aplicaciones es más segura ?

Definitivamente contestaría que las aplicaciones nativas son más seguras ya que la información nunca es enviada a través de internet y siempre se mantiene en el dispositivo.. aunque también pensando de otra manera diría que una aplicación que funciona local no almacena respaldos por lo que la información esta propensa a dañarse..

Y que puede ser más costoso mantener ?

Igualmente ambos tipos de aplicaciones tienen sus pros y sus contras.. por un lado las aplicaciones nativas viven en los dispositivos móviles lo cual no genera ningún tipo de costo adicional al desarrollo.. Mantener este tipo de aplicaciones implicaría que quienes hayan descargado una versión, vuelvan a descargar la actualización.. Por otro lado, las aplicaciones móviles tienen un costo de mantenimiento para quienes las desarrollan ya que por su naturaleza deben vivir en un servidor en internet lo cual genera un costo anual.. En cuanto a las actualizaciones es mucho más fácil para quienes las utilizan ya que no necesitan descargar nada adicional, ya que todo ocurre de manera centralizada.

Aplicaciones nativas, híbridas o web para móviles compiten actualmente en el mercado.. cada una con sus puntos en contra y a favor.. yo recomendaría siempre evaluar los alcances, los recursos, los costos y tomar como punto de partida una aplicación web que es multiplataforma, en caso de que los requerimientos sean superiores o se tenga dificultades para utilizar este tipo de aplicación.. entonces lo mejor es dar el salto hacia aplicaciones nativas.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
ajax / Html / Internet / Jackfiallos / javascript / jquery / MVC / Proyectos / Pruebas de Software / software / tecnologia / Tendencias / Web — No Comments
28
feb 12

jQuery Mobile lo bueno y lo malo

No Gravatar
JQuery Mobile

JQuery Mobile

Desde mi blog la semana pasada hacía una reseña sobre 3 diferentes alternativas para desarrollar aplicaciones web para teléfonos móviles (iPhone, Android, Blackberry, Windows Phone, etc) .. al final decidí quedarme con jQuery Mobile por la sencillez y rápida curva de aprendizaje.. además que estaba trabajando en un prototipo de proyecto que no debía tomarme más de 3 días desarrollarlo. En fin, el propósito de este artículo es mostrarles de que manera funciona esta librería.. las carencias que encontré y las virtudes que pueden ayudar a escribir aplicaciones móviles en casi cuestión de horas.

Como funciona

Las aplicaciones web básicamente trabajan 2 capas que son el procesamiento de datos, algo que siempre ocurre del lado del servidor y la presentación de la información que es lo que el servidor regresa a los navegadores en un formato de meta etiquetas (html) .. pues bueno, jQuery Mobile agrega una capa extra que sería como una especie de manejador de eventos que se encarga de escuchar todas las pulsaciones que hacemos sobre los enlaces y botones de formularios para luego solicitar al servidor su proceso vía ajax .. La verdad es que la lógica de como funciona es muy simple porque todo ocurre mediante callbacks.. Si llegan a ver algunos ejemplos de como son estas aplicaciones desarrolladas con jQuery Mobile verán transiciones de entrada y salida entre las páginas y pues esto es el resultado de esas peticiones administradas vía ajax.. Y como todo lo que se hace con javascript, jQuery Mobile se puede parametrizar para que tenga el comportamiento que deseamos.

La tecnología que emplea

Es importante mencionar que esta librería y así he decidido llamarlo porque no creo que llegue al nivel de framework.. su uso esta basado totalmente en HTML5 .. ese nuevo estandar de desarrollo web que se está poniendo de moda.. y CSS3 que vienen a ser como el estilista del HTML5.. entonces si defino a jQuery Mobile diría que es una combinación de mucho HTML5 que utiliza inteligentemente metadatos en las etiquetas, canvas para dibujar algunos botones y CSS3 para administrar la capa visual (esquinas redondeadas, gradientes lineares, sombras y más)…

Una buena recomendación

Si estan interesados en empezar a desarrollar aplicaciones móbiles nativas, creo que antes deberían de entrarse un poco en el uso de este tipo de herramientas para desarrollar la visión del diseño de como son las aplicaciones móbiles, ya que la naturaleza de este tipo de aplicaciones requiere de otro tipo de destrezas relacionadas más que todo con usabilidad que al final es la parte visual y lo que más interesa a los usuarios. Con esto no estoy tratando de decir que las aplicaciones móbiles web son mejores que las nativas.. claro que no!! sería imposible hacer la comparación, pero en el caso de que se necesita escribir una aplicación en tiempo record que sea multiplataforma.. lo más obvio sería utilizar jQuery Mobile o cualquier otra herramienta para este propósito y bueno, eso sin mencionar que el costo monetario es mucho muy inferior.

Lo que hay que tener en cuenta

Es bueno recordar que las aplicaciones móbiles no deben ser complejar, el contenido debe invitar a los usuarios a navegar y al mismo tiempo a constuir un mapa de enlaces en la mente para que sepan como utilizarla casi inmediatamente. Eso significa que no se deben de pensar en interfaces complejas o en componentes que puedan confundir a quienes la usen. Jquery Mobile tiene como elementos básicos los componentes de formularios (input, select, checkbox, radio y button).. otros elementos serían las listas, barra de navegación y es todo.. igual que con jQuery hay desarrolladores externos que estan escribiendo plugins como por ej. datepickers o uploaders que son necesarios y no estan incluidos en la librería.

Utilizarlo con moderación

Creo que antes de decidir su uso o no.. deberían de tomar uno de los ejemplos de la página de ayuda y ver si es compatible con los dispostivos en los que pensarían utilizarlo.. por. ej. yo utilizo un Android 2.3 donde las imágenes y animaciones no son tan fluídas.. lo he probado en un iPhone 3GS y lo ví un poco torpe con las animaciones.. con el iPhone 4 se vé de maravilla al igual que con una tablet android con 3.0 y tampoco tuvo problemas..

—

Al final la aplicación que escribí es un ligero CRM con un enfoque hacia seguimiento de ventas.. si!! tarde 3 días en el desarrollo, aun es una versión beta y fue rápido hacerlo porque tras el código estuvo una arquitectura MVC.. si me animo quizás suba el código a github y luego al laboratorio de Qbit para que aprendan un poco sobre jQuery Mobile.

Y para finalizar el resultado final en un teléfono LG Optimus Black.. nada mal eh..!!

Mobile CRM

Mobile CRM

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
ajax / ASP / c# / Html / Internet / javascript / MVC / software / Web — 2 Comments
21
feb 12

How to Gridview con MVC Contrib para ASP MVC

No Gravatar
MVC Contrib

MVC Contrib

Como saben asp mvc 2 no tiene componentes visuales que nos ayuden a mostrar la información.. e ilógicamente eso es lo que más me ha gustado de este framework ya que eso nos permite tener el control total de las aplicaciones web.. a diferencia de webforms que se incluía código de más y era muy tedioso mezclar componentes propios que utilizaran ajax con su scriptManager y su updatePanel..

Entonces esta vez nos encontramos con el ya conocido problema de que asp mvc no tenemos un componente de tipo grid nativo.. por lo que básicamente tenemos 3 opciones para implementar uno.. la primera solución es hacerlo a mano.. escribiendo un tabla y vaciando todos los datos, creando paginación, agregando ordenamiento de registros por columnas y estilizándola porque siempre es necesario que se vea bonito.. la segunda opción es utilizar componentes ya escritos y comerciales por su puesto.. (Telerik, DevExpress, Ext, jqGrid) o la tercera opción que sería buscar alternativas de código abierto como MVC Contrib (CPOL) .. que esta última opción sería nuestra elección.

Entonces para empezar lo primero que se debe de hacer es descargar MVC Contrib de esta dirección http://mvccontrib.codeplex.com/releases .. es importante mencionar que MVC Contrib es una suite de componentes, pero en este ejemplo solamente utilizaremos el componente grid..

Una vez que hayamos descargado los archivos lo que necesitaremos será descomprimirlo, ubicar el archivo MvcContrib.dll y agregarlo como referencia a nuestro proyecto en Visual Studio.. Para poder generar un grid con datos necesitamos un modelo que luego será el contenedor de la información.. entonces lo siguiente es crear una clase de tipo modelo.. que en mi ejemplo sería lo siguiente:

UsuariosModel.cs

namespace MvcContribExample.Models
{
    public class UsuariosModel
    {
        public string nombre { get; set; }
        public string apellido { get; set; }
        public string deporte { get; set; }
    }
}

Listo.. ya tenemos nuestro modelo.. ahora vamos a trabajar con el controlador para manejar la primera petición a nuestra página y que automáticamente se cree el grid con datos.. entonces simplemente para generarlo damos clic derecho sobre la carpeta “controllers”, seleccionamos agregar y luego tomamos la opción “Controller…” —  como esto es un ejemplo muy básico no necesitamos que se genere nada.. asi es que la opción de agregar otros métodos no la requerimos..

HomeController.cs

using System.Collections.Generic;
using System.Web.Mvc;
using MvcContribExample.Models;
using FizzWare.NBuilder;
 
namespace MvcContribExample.Controllers
{
    public class HomeController : Controller
    {
        public ActionResult Index()
        {
            var listaRandom = Builder<UsuariosModel>.CreateListOfSize(20).TheFirst(1)
                .With(x => x.nombre = "Jack")
                .And(x => x.apellido = "Fiallos")
                .And(x => x.deporte = "Baloncesto")
                .Build();
            var model = (List<UsuariosModel>)listaRandom;
            return View(model);
        }
    }
}

Por ahí verán que estoy utilizando NBuilder (using FizzWare.NBuilder;).. pero no es necesario que ustedes lo tengan en su proyecto.. NBuilder lo que hace es generar una lista arbitrária de datos.. es muy útil para hacer pruebas.. al final lo que NBuilder genera es una lista que se debe convertir a (List[UsuariosModel]) que es lo que espera el grid.

Ahora que en nuestro controlador tenemos un método llamado Index .. necesitaremos una vista con el mismo nombre.. entonces en la carpeta Views crearemos otra carpeta llamada Home y dentro de ella una vista llamada Index..

Y una vez con la vista Index generada pegamos el código del grid.. que sería algo como lo siguiente:

Views/Home/Index.aspx

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
 
<%@ Import Namespace="MvcContrib.UI.Grid" %>
<%@ Import Namespace="MvcContribExample.Models" %>
 
<!DOCTYPE html> 
<html> 
<head runat="server">
    <title>MVC Contrib Example, Ejemplo o como le quieran llamar</title>
</head>
<body>
    <div class="grid">
    <% Html.Grid((List<UsuariosModel>)Model)
       .Columns(column =>
       {
         column.For(c => c.nombre);
         column.For(c => c.apellido);
         column.For(c => c.deporte);
       }).Attributes(@class => "gridclass", @id => "gridview").Empty("Sin registros :(").Render();
    %>
    </div>
</body>
</html>

Y voilá.. habemus grid sin tener que escribir tanto código..  Ahora hay cosas extras que faltarían para tener un grid hecho y derecho.. como por ejemplo la paginación, ordenamiento datos por columnas y colorear las filas tipo zebra striped.. pero eso sería tema de otro artículo.. para adelantarme un poco.. yo utilicé los estilos de twitter bootstrap y agregué como estilo “zebra-striped bordered-table” .. además incluí jquery.tablesorter para permitirle al grid ordenarse por columnas.. algo de paginación con el mismo componente de MVC Contrib y ajax para paginar el grid sin recargar toda la página.

Espero les sirva para entender el funcionamiento de MVC Contrib, Nbuilder que no era parte del artículo pero que al final lo incluí para efectos de prueba y hasta casi un pequeño tutorial de ASP MVC. :D

Y porque no quiero dejar nada inconcluso.. dejo el código fuente que utilicé para el ejemplo.. MvcContribExample

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
Html / Internet / Proyectos / Servicio / servidor / Sistemas de Informacion / tecnologia / Tendencias / Web — No Comments
14
feb 12

REST vs SOAP

No Gravatar
REST vs SOAP

REST vs SOAP

Aunque REST y SOAP son arquitecturas muy similares de intercambio de información entre aplicaciones web y de escritorio con servidores, antes de decidirse por uno de ambas es importante tener en cuenta las siguientes consideraciones. Trataré de ser objetivo en este artículo ya que hasta hace poco empecé a utilizar REST (4 meses), todo lo que aprendí sobre websvices esta basado en SOAP.

Primeramente hay que entender que REST esta basado en una arquitectura donde se identifican los recursos claves a consumirse.. veámoslo como una forma semántica de escritura ante la web donde hay métodos que al ser interpretados nos retornan información… Algo como por ejemplo utilizando el método GET del protocolo HTTP (digo GET porque también se puede utilizar POST, PUT, HEAD, DELETE, etc.. ) haría una petición de la siguiente manera: “http://servidor.com/api/proyecto/1/tarea/5″  .. donde api es el contenedor de mi webservice y lo que sigue sería equivalente a decir.. Del proyecto con identificador no. 1 seleccionar la tarea con identificador no. 5 y mostrar el resultado en formato json o xml.

Así de fácil es REST, mientras que SOAP es un poco más complicado por que lo que se consumen son métodos o funciones almacenadas igualmente en un servidor.. entonces si quisiera hacer lo mismo.. en SOAP tendría que escribir algo como lo siguiente: “http://miservidor.com/api/calcula” donde calcula contiene una definición de funciones (sumar y restar) que se pueden implementar mediante la creación de un objeto, un concepto de la programación orientada a objetos .. del uso de alguno de los métodos listados en el servicio calcula como respuesta obtendría una salida en xml con una definición del tipo de datos que respondió el servidor..

Si se fijan ambos tipos de conexión ya sea REST o SOAP se parecen mucho, ya que sirven para solicitar información a un servidor, pero distan de implementarse de una manera similar.. verán que REST es mucho más fácil y SOAP conlleva escribir un poco más de código..

En la actualidad muchos de los servicios que utilizamos a diario como twitter, facebook, fourquare, delicious, flickr, etc.. estan basados en REST por la facilidad de imlementación y la simplesa que se obtiene en los resultados.

SOAP ya que tiene una arquitectura de respuesta más compleja, es utilizado comunmente en corporaciones, hasta me atrevería a decir que la mayoría de empresas que utilizan sistemas basados en .NET o Java tienen sus servicios de comunicación basados en SOAP .. porque ha decir verdad es muy fácil implementar esos objetos y consumir esos métodos.. porque claro!! hay personas que ya hicieron todo el trabajo pesado de crear librerías que se usan casi con un par de líneas. Además que en estos lenguajes se tienen componentes visuales que se conectan casi de manera transparente a webservices basados en SOAP por lo que como dije.. ya todo lo interesante ya se hizo.

Entonces ya que tenemos una mejor idea de que hace REST vs SOAP podemos hacer comparaciones y obtener una conclusión..

REST

En lo que es genial

  • Es muy ligero, sus respuestas contienen exactamente la información que necesitamos.
  • Para los nosotros los humanos es muy fácil y simple de interpretar.
  • Es sencillo de desarrollar y no se necesita mucho código extra.
  • Es flexible en cuanto al tipo de respuesta que se necesita, ya que puede ser xml o json.
En lo que falla
  • Creo que la seguridad es un problema y puede llegar a ser una tarea muy difícil implementarla correctamente.
  • No hay un estándar en sus respuestas por lo que no se definen tipos de datos.
SOAP

En lo que es genial

  • Si trabajas con componentes y utilizas .NET o Java es muy sencillo de consumir.
  • El resultado que siempre es XML contiene una definición específica del tipo de dato, lo que hace del protocolo algo muy estricto.
  • Se dice que es más seguro porque su implementación siempre o la mayoría de las veces se hace del lado del servidor.

En lo que falla

  • Una vez implementado, si se desea cambiar algo en el servidor impacta de forma negativa en los clientes ya que estos tienen que hacer muchas modificaciones al código.
  • Las respuestas son demasiado complejas y difíciles de interpretar si no se tienen las herramientas correctas para hacerlo.

Conclusión

Creo que ambas arquitecturas de intercambio de información tienen sus nichos bien definidos, cuando se trata de aplicaciones públicas refiriéndome a servicios de uso masivo es mucho mejor utilizar REST por la sencillez en su implementación y respuestas, inclusive en clientes móviles es mucho más fácil utilizar REST. Por otro lado si se esta pensando en webservices para corporaciones donde se manejan datos complejos y se necesita una presición detallada en las respuestas se debe de utilizar SOAP, entornos de desarrollo como Visual Studio hacen que el desarrollo e implementación de SOAP sea sumamente sencillo sin tener que escribir código de más para interpretar respuestas.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
Html / Internet / Linux / MySQL / Ocio / Proyectos / Qbit / Servicio / software / tecnologia / Web — No Comments
4
ene 12

Celestic un largo camino por seguir y muchas ganas de continuar

No Gravatar

Celestic Community

Creo que han pasado alrededor de 2 meses desde que hice público Celestic Community, una nueva aplicación open source la cual ayuda a mejorar el seguimiento de proyectos de software.. Durante ese tiempo he recibido diversos tipos de  comentarios alentandome a continuar su desarrollo.. De todos esos comentarios uno en particular llamó mi atención, uno relacionado a mejorar la usabilidad y la forma en que los usuarios interactuan con la aplicación.

Comprendo que hasta cierto punto Celestic puede ser un tanto complejo de utilizar debido a la cantidad de información que solicita, pero todo eso es necesario para lograr un nivel de detalle aceptable y tener un histórico completo de todo lo ocurrido durante la vida del proyecto..

Falta de “usabilidad”? Tienen razón, uno de los principales puntos que en este momento Celestic tiene en contra es el uso excesivo de formularios, algo que inicialmente y de forma adrede decidí dejar así porque no quería escribir un poco más de código para utilizar ajax lo cual ayudaría a resolver las quejas..

El desarrollo de Celestic continua, muchas mejoras estan en camino, estoy trabajando en eso que le falta en este momento (estadísticas, usabilidad y mucho más client side), todo pensado para enriquecer su uso. De las cosas que recuerdo estarán en las nuevas versiones son: administración de notificaciones, modificaciones a los estatus de las tareas siguiendo un orden específico, nuevos gráficos estadísticos, integración de nuevos paquetes de idiomas, correcciones a bugs encontrados por colaboradores, etc..

Para más detalles sobre Celestic Community.

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
ASP / Html / Internet / Microsoft / MVC / Ocio / Proyectos / Qbit / software / tecnologia / Web — 2 Comments
20
dic 11

Asp.net MVC 2 Model List<> DropdownListFor

No Gravatar

ASP.NET MVC

En mi experiencia recorrindo diferentes lenguajes de programación y sus respectivos frameworks de desarrollo ágil para aplicaciones web, esta vez tocó el turno a asp mvc 2 y para iniciar esperaba crear un lista de selección.. Se que la versión actual de asp mvc es la 3, pero solamente se puede utilizar con visual studio 2010, el cual aun no hemos comprado, por eso este mini how to lo hago con la versión 2.

Leí muchos tutoriales y ejemplos sobre como lograr hacer un dropdownlist con información de un modelo, la mayoría de los ejemplos mostraban lo siguiente:

Crear un modelo y luego una propiedad de tipo List conteniendo SelectListItem que básicamente es una estructura de textos y valores.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

public class EjemploModel
{
   [DataType(DataType.Text)]
   [Required(ErrorMessage = "Selecciona un mes")]
   [DisplayName("Mes")]
   [UIHint("List")]
   public List<SelectListItem> meses { get; set; }
 
   // Constructor para llenar la lista en la instancia
   public EjemploModel()
   {
      meses= new List<SelectListItem>();
      for(int i=1; i<=12; i++)
      {
         meses.Add(new SelectListItem() { Value =i.ToString(), Text = i.ToString() });
      }
   }
}

Hasta esta punto todo parece tener sentido.. creando una propiedad de tipo lista y luego pasándola a la  vista:

1
2
3

<%= Html.LabelFor(model => model.mes) %>
<%= Html.DropDownListFor(Model.mes, Model.mes, "-------")%>
<%= Html.ValidationMessageFor(model => model.mes, "*")%>

Y seguramente funciona.. el problema venía cuando hacia submit del formulario.. ya que el valor seleccionado del dropdownlist nunca era tomado como parametro en el action donde la enviaba.. Leí muchos post donde a novatos como yo les ocurría el mismo error.. claro, en los tutoriales nunca decían como resolverlo por lo que la respuesta viene a continuación, sencilla para serles sincero..

En los otros frameworks no es necesario definir una propieda de tipo lista, simplemente lo que se hace es definir una propiedad que en este caso sería Int .. y la lista crearla por aparte sin necesidad de hacerla propiedad del modelo. Sé que hay más de una manera de hacer esto y mi forma es la siguiente:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

public class EjemploModel
{
   [DataType(DataType.Text)]
   [DisplayName("Mes")]
   [UIHint("List")]
   public List<SelectListItem> mesLista { get; set; }
 
   [DataType(DataType.Text)]
   [Required(ErrorMessage = "Debe de seleccionar un mes de vencimiento.")]
   [DisplayName("Mes")]
   public int mes{ get; set; }
 
   // Constructor para llenar la lista en la instancia
   public EjemploModel()
   {
      mesLista= new List<SelectListItem>();
      for(int i=1; i<=12; i++)
      {
         mesLista.Add(new SelectListItem() { Value =i.ToString(), Text = i.ToString() });
      }
   }
}

Y en la vista quedaría de la siguiente manera:

1
2
3

<%= Html.LabelFor(model => model.mes) %>
<%= Html.DropDownList("mes", new SelectList(Model.mesLista, "Value", "Text"), "-------")%>
<%= Html.ValidationMessageFor(model =>; model.mes, "*")%>

Ahora al momento de hacer submit, el valor seleccionado se pasará hacia la propiedad mes y no a mesLista como ocurría anteriormente. Espero les sirva de ejemplo y guía..

Suerte

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
accesibilidad / Html / Internet / Ocio / software / Web — No Comments
12
abr 10

Como mejorar la accesibilidad de tu sitio web

No Gravatar
Puntos a tomar en cuenta para mejorar la accesibilidad de tu sitio

http://centro.us.es/facpsi/accesibilidad/

Durante la vida de este blog, más de una vez he tratado de explicar que significa la accesibilidad en un sitio web o algunos puntos importantes que se deben de tomar en cuenta.. esta vez en este post quiero extender esos puntos y dejar claro cuales son las reglas a seguir y el porque son importantes seguirlas.

Codificación válida = codigo válido [por aquí se debe de empezar]

Recuerda que muchos intérpretes de páginas verifican la codificación y estructura del código para poderlo entender y traducir de manera correcta el contenido de la página a las personas con discapacidades, muchas veces obviamos este punto y desarrollamos aplicaciones pensando en que todas las personas que la utilizarán no tienen ninguna discapacidad.

Nunca olvides ponerle un título a tus páginas

Para algunos quizás no parezca importante como sucede con muchas cosas relacionadas con la accesibilidad, pero el título es el primer paso para saber a que lugar he llegado. Debe existir un título para la página, a través del elemento <title>, este debe ser claro, descriptivo y conciso.

Siempre que utilices dentro del cuerpo el tag <script> trata de poner seguido el tag <noscript>

Los scripts incluidos en el cuerpo del documento deben llevar contenidos alternativos en <noscript> que describan su acción o reemplacen su funcionalidad, esto porque quizás algunos navegadores no se encuentran actualizados o no soportan las características del script que se esta usando.

Recuerda poner la propiedad alt cada vez que incluyas una imagen

Cada imagen debe llevar el atributo “alt” con un texto que describa su contenido o la función que cumple. Si la imagen es muy compleja debe llevar también “longdesc”. Es muy importante el atributo alt ya que navegadores muchas veces no interpretan el contenido binario de las imagenes (razones pueden haber pocas, pero suele suceder), algunas personas con discapacidades físicas o motoras tienen intérpretes que por decirlo de cierta manera traducen el contenido de esta propiedad para ser entendido por ellos.

Si creas eventos, recuerda que estos no sean exclusivamente disparados por el mouse

Los eventos deben poder activarse con cualquier dispositivo porque hay usuarios que no pueden, por ejemplo, usar un ratón. Por tanto se deben especificar manejadores de evento independientes del tipo de dispositivo o definir eventos redundantes. Ahora con la difusión de los frameworks de javascript es muy fácil crear porciones de código que envian el evento a funciones específicas, lo que significa que se pueden utilizar globalmente através del código script.

La etiqueta <label> fue desarrollada para que la utilices siempre junta a una etiqueta de formulario

La etiqueta <label> contiene una propiedad llamada “for” la cual debe coincidir con el atributo “id” del control de formulario al que identifica. Esto es especialmente útil para los usuarios que utilizan lectores de pantalla para navegar.

Los enlaces deben de contener la propiedad target y la propiedad title

Verifique que siempre exista la propiedad target y la propiedad title dentro de la etiqueta <a>, en caso de que el target abra una ventana emergente se debe de dar aviso al usuario. El title generalmente siempre muestra el contenido que se encuentra dentro de la etiqueta <a>.

Mantener una aplicación actualizada no solamente significa librarla de errores

Es importante usar las tecnologías del W3C cuando se encuentren disponibles y sean soportadas. Entre otros motivos porque cada vez se tienen más en cuenta las cuestiones relacionadas con la accesibilidad. Algunos me odiaran, pero flash no es accesible para nada, hay que aceptarlo, la plataforma no fue desarrollada pensando en la accesibilidad.

Escribe en pequeños bloques de información

Se debe de estructurar y segmentar los textos incluidos organizándolos mediante títulos, subtítulos, párrafos y listas. Recuerda que los bloques de información demasiado largos dificultan su comprensión.

Maquetar sitios web con tablas no es una opción válida para desarrollas sitios ni aplicaciones web

Las tablas son elementos utilizados para presentar contenido tabular y no deben utilizarse para presentar otro tipo de contenido. Esto es especialmente importante para quienes utilizan navegadores sólo texto o lectores que leen línea a línea los datos en pantalla.

No olvides específicar el idioma de tu página

En todas las páginas debe indicarse el idioma principal del documento. Si el documento es XHTML, debe verificarse que, además del atributo “lang”, se debe de utilizar “xml:lang”.

Las listas deben de estar organizadas mediante etiquetas estándares

Se deben proporcionar barras de navegación constituidas por listas de enlaces para agruparlos y facilitar su localización. Recuerda que las listas no se definen por su aspecto sino por el uso de elementos <ol>, <ul> y <dl>.

Utiliza enlaces directos mediante teclas específicas

Los atajos de teclado permiten a quienes utilizan el teclado para navegar, acceder rápidamente a los elementos más importantes de la página. La propiedad accesskey es utilizada en etiquetas tipo <input> y etiquetas tipo <a>, al momento de presionar una tecla enlazada a un control o link esta envía el foco hacia el control.

La mayoría de esta información muchas veces no es tomada en cuenta y validando estos puntos o no haciéndolo, las páginas siguen funcionando aparentemente bien para aquellos que no tienen discapacidades o quienes no utilizan dispositivos traductores de páginas web. La meta de la accesibilidad es lograr que personas con discapacidades motoras o físicas puedan tener acceso a la web.

Fuentes y Sitios Relacionados

Importancia de la accesibilidad

Introduccion a la accesibilidad

Porque es importante la accesibilidad

La importancia de la creciente accesibilidad

Porque la web debe de ser accesible

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon
Html / Internet / mootools / Ocio / Qbit / software / Web — No Comments
29
mar 10

Implementando un ToDo con jQuery para tu aplicacion Web

No Gravatar
jQuery ToDo

jQuery ToDo

Antes que nada quiero decir que al escribir este pequeño tutorial me siento muy mal porque estoy traicionando a mi comunidad.. Soy mootools-cista pero en vías de que el framework (Yii Framework) que estoy utilizando a implementado jQuery tuve que cambiarlo de momento.

Esto sería el equivalente a la usabilidad de los usuarios pero exclusivamente para los desarrolladores de aplicaciones web, a continuación describiré como aplicar un widget a tu aplicación web desde el cual podrás mantener registro de las tareas pendientes o realizadas. Y hablo de usabilidad porque la lista siempre se mantiene a la vista del desarrollador.

Normalmente siempre utilizamos una aplicación para llevar el rastreo de tareas y seguimiento de errores cuando trabajamos en grupo con otras personas (por ejemplo en Qbit Mexhico utilizamos Solar Bugs Report), pero algunas veces cuando trabajamos solos es un poco más difícil ya que entra en juego la decídia y que por comodidad decidimos no llevar control de tareas pendientes desde una aplicación externa.

Mi propuesta para llevar una organización alternativa al seguimiento de errores y tareas pendientes es implementar mediante jQuery, CSS y HTML una especie de widget que se debe de pegar en cada página de la aplicación de la cual se desea realizar seguimiento.

1. La definición del código CSS

.popNotification {
   border:3px solid red;
   padding:15px;
   position:fixed;
   right:0;
   width:480;
   bottom:0;
   z-index:1400;
   background-color:#000;
   color:#fff;
   filter:alpha(opacity=4);
   -moz-opacity:0.4;
   -khtml-opacity:0.4;
   opacity: 0.4;
}

2. Definición del Código Javascript con jQuery

$(document).ready(function() {
   $('.popNotification').css('opacity',0.4).hover(function(){
      $(this).fadeTo(200,1);
   }, function(){
      $(this).fadeTo(200,0.4);
   });
});

3. Definición del Código HTML

La idea es pegar este código antes del la etiqueta <body> y escribir la lista de tareas que se necesitan realizar.

<div class="popNotification">
   <h2>ToDo</h2>
   <ul>
      <li>Esta puede ser la tarea #1</li>
      <li>Esta puede ser la tarea #2</li>
      <li>Esta puede ser la tarea #n</li>
      <li>Y asi podemos definir nuestras tareas</li>
   </ul>
</div>

El widget se puede mejorar o extender su funcionalidad, yo cuando una de las tareas la he realizado lo que hago no es borrar la tarea de la lista, sino que incluyo la imagen de un check al inicio de esa tarea.. Con eso me doy cuenta de si o no una tarea ya fue realizada. [muchas veces repetí la palabra tarea ¬¬]

Compartir y Disfrutar

  • Facebook
  • Twitter
  • Delicious
  • Digg
  • StumbleUpon

Qbit Mexhico Blog is using WP-Gravatar