CSS tablas filas estilos TBODY

Las hojas de estilos en cascada, popularmente conocidos como Cascade Stylesheet, es una de las cosas maravillosas que nos brindaron los browsers -hace unos años atras- para establecer la apariencia de nuestras vistas al usuario en los aplicativos web que desarrollasemos, reduciendo el codigo redundante del formato entremezclado con el HTML.

NO hay duda, las hojas de estilos en cascada o CSS, nos salvaron la vida.

Llegaron para quedarse. Para brindarnos facilidad de uso y ahorro de energia en la construccion de nuestras vistas.

Sin embargo, aquellos que usabamos las tablas para diseñar el layout de nuestras paginas vivimos en carne propia que los DIV brindaban un manejo mas sencillo para la configuracion del layout de nuestras vistas orientadas al usuario.

Las tablas cedieron terreno para dejarle el trabajo del layout a los DIV.

Algunos mencionaban que el performance de pintar: TABLE, TR, TD y demas era mucho mas bajo que al usar los DIV para hacer algo relativamente similar.

Pero entre otros tantos mitos, uno quedo muy claro, usar CSS sobre tablas se complicaba mas de lo debido.

¿A que se debia esto? ¿Acaso NO era sencillo establecer una clase TABLE > TR para aplicar un estilo en particular a dicha combinacion de elementos?

Pues, alli radica uno de los problemas.

El operador > : mayor que, implica que la combinacion se establece entre el ascendente y el descendiente inmediato, sin embargo NO era comunmente usado.

En comparacion al operador tacito, TABLE TR, que aplicaba el estilo a todos los descendientes TR, de primer o enesimo nivel, con respecto al elemento TABLE.

Lo mejor es usar combinaciones de TABLE > TR para aplicar estilos a los elementos internos a un TABLE. Por que de esa manera NO pierdes el control de las cosas que estas desarrollando sobre la vista.

Sin embargo, dicha combinacion nunca funcionaba. ¿Que es lo que pasaba?

Bueno aqui viene la parte mas triste de todo esto embrollo.

Sucede pues, que el elemento TBODY es implicito en la construccion jerarquica de los TABLE, TR y TD.

Es decir, a pesar que explicitamente NO colocases el TBODY luego del TABLE y antes del TR, dicho elemento -el TBODY- se encontraba alli.

Entonces, necesariamente debias establecer tus estilos para las combinaciones TABLE > TBODY > TR si querias aplicar algun estilo para las filas inmediatamente inferiores de un TABLE en particular.

Pequeño detalle ¿cierto? Ahora todo encaja ¿verdad?

Ante dicho truquillo, poco difundido, es que las tablas se alejaron del diseño de los layouts para dejar ese trabajo a los DIV usando propiedades float y clear, segun sea el caso.

Las tablas solo seria usadas para mostrar informacion tabularmente.

Las clasicas grillas de datos y demas relativamente similares.

Bottom Up para desarrollar software

La perspectiva Bottom Up para desarrollar software provoca que una de tus primera tareas sea modelar la estructura logica de la Base de Datos que soportara el producto de software que vayas a construir.

Muchas veces se cae en la simpleza de mencionarse que si la base de datos esta bien modelada cualquier cambio posterior NO tendra un impacto muy grave.

Los que estamos involucrados en el mundo del desarrollo de software con conectividad a Base de Datos, hemos modelado una estructura de datos, si o si, y hemos visto hasta Base de Datos en produccion, sin primary keys, constraints, relations ships, sin nada.

Con campos redundantes de informacion de una tabla en otra, entre quienes existen solo algun tipo de relacion.

Entonces, ¿hasta que punto es valido rasgarse las vestiduras para aferrarse a la fragil idea de que la base de datos debe estar MUY bien modelada?

En la fase de la contruccion del software, aquella en la que los developers empiezan su tarea, desarrollan las vistas del usuario y demas, por alguna u otra circunstancia se haran necesarios diferentes cambios en la estructura de datos original de la base de datos que hayas modelado.

NO existe el modelamiento preciso y exacto que resuelva todas las incidencias posteriores, sin requerirse cambios en los objetos de la base de datos: tablas, campos, relaciones, etc.

Si aun puesto en produccion, el software al ser usado por un mayor volumen de usuarios, brotaran incidencias que traeran como consecuencias cambios en las vistas y muchas veces -algunos de esos cambios- requeriran cambios en la estructura de datos original, pues con mayor razon que en la fase de la construccion del software seamos testigos presenciales y activos de esos cambios.

La Base de Datos NO tendria por que ser necesariamente la mayor de las prioridades, pues las vistas del usuario NO interacturan directamente con dicha estructura.

La capa de negocio o Business Layer adquiere mayor relevancia.

Clases parciales con Visual Source Safe

Una de las tantas aplicaciones que puedes darle a las clases parciales esta directamente asociada con el uso del Visual Source Safe 2005.

Cuando tienes algunos developers en tu equipo de trabajo, dedicados a la construccion de un producto de software y se apoyan en Visual Source Safe para la gestion y cuidado del codigo fuente, sucede una necesidad.

Acceder a un archivo .cs en particular para agregarle alguna funcionalidad o aplicar un pequeño refactory en el mismo.

Sea como fuese, es necesario poder acceder a un mismo archivo fisico a la vez.

Justamente el Visual Source Safe existe para todo lo contrario. Impedir el acceso de escritura a un mismo archivo fisico, a la vez.

Ante el requerimiento de poder hacerlo y la funcionalidad de la herramienta que te lo impide, utilizar Clases Parciales o Partial Classes es una solucion al problema.

Al utilizar mas de un archivo fisico para definir una entidad logica, solo te quedara la tarea de agrupar ciertas funcionalidades en el primero de los archivos y otras funcionalidades en los archivos fisicos restantes.

Puedes utilizar tantos archivos fisicos requieras para la definicion de tu entidad logica, la clase.

Web Client Software Factory

Una propuesta para desarrollo de software en modalidad web con la propuesta Model View Presenter MVP, es el llamado Web Client Software Factory.

Este interesante add-on para el Visual Studio .NET 2005 propone una forma peculiar de desarrollar software para ASP.NET.

Web Cliente Software Factory se monta sobre el Composite UI Application Block.

Esto es una ladilla pues cuando te encuentres desarrollado alguna vista en particular te encontraras con un error mas deconocido que el anterior.

Unos errores realmente espantosos.

Ello es consecuencia directa de utilizar el Composite UI Application Block como base para el Web Client Software Factory.

Por otro lado, el Web Cliente Software Factory propone un marco para desarrollo de una aplicacion ASP.NET en lo correspondiente a la capa del usuario. El manejo de las vistas a traves de un presenter.

Escucharas sobre Presenters, Controllers y Views a diestra y siniestra.

Sin embargo, debes y tienes que encontrar una forma creativa de fusionar la propuesta del Web Client Software Factory con tu capa de negocio y posteriormente con tu capa de acceso a datos.

De una forma u otra, sentiras en carne propia que requieres utilizar mas tiempo -que el que utilizabas antes- para construir un aplicativo cualesquiera bajo la propuesta del Web Client Software Factory.

Los Views solo deberian gestionar los eventos de los controles que estan disponibles al usuario.

Los Presenters son los encargados a establecer la logica de presentacion de la informacion en los Views. Pues los Presenters tiene una referencia a los Views.

Esto podria sonar relativamente extraño, pero es asi. Pues uno espera que sea el View que tenga una referencia al Presenter, sin embargo la referencia es a la inversa y eso ayuda a poder utilizar los elementos definidos en los Views desde el Presenter.

Los Controllers hacen justamente eso, controllar la forma en que los Presenters han de interactuar.

Sin embargo, queda en un limbo como hacer para que tu Business Layer se integre facilmente con la propuesta del Web Client Software Factory.

Cada quien tiene su propio criterio y encontraras soluciones buenas y otras NO tan buenas.

En el intento esta la respuesta. Y en las pruebas de stress la mejor solucion.

Tipos anonimos en C# 3.0

Una de las cosas que me fascinan del C# 3.0 es el uso de tipo anonimos.

Las tipos anonimos o anonymous types, tambien conocidos como clases anonimas, brindan una posibilidad interesante que nos hubiese gustado poder disfrutar en la version C# 2.0 del Visual Studio .NET 2005.

Una de las primeras aplicaciones de los tipos anonimos lo encontramos en el desuso de los RowDataBound del GridView al mostrar informacion de vistas relativamente sencillas.

Gracias a que existen los tipos anonimos, puedes entregar un lista de elementos cuya estrutura NO se encuentra definida previamente.

Muchas veces, al usar un modelo de objetos basado en Collections and Business Entities, se hacia necesario utilizar el RowDataBound del GridView para poder enlazar los controles definidos en los TemplateColumn -que hayas diseñado en el GridView- con el dato que deseas.

Por ejemplo, si tenias un collection de Clientes y tienes una propiedad para cada cliente llamada TipoCliente.

Evidentemente NO hibas a enlazar en una columna del GridView solo el ID del TipoCliente.

Era requerido por el usuario final, mostrar la descripcion del TipoCliente en la grilla de datos.

Ese tipico escenario, era motivo para utilizar el RowDataBound del GridView, con la intencion de enlazar el Label que habias definido en el TemplateColumn con el dato que se encontraba en ICliente.TipoCliente.Descripcion que habias establecido segun el modelo de objetos a nivel de la capa de negocio del producto de software que te encontrabas construyendo.

Gracias a las clases anonimas y su facil uso, hemos dejado de usar los RowDataBound del GridView en algunos tipicos escenarios.

Esto ayuda mucho en la mejora del tiempo para el desarrollo del software.

Al poder definir un collection de tipos anonimos de una forma relativamente similar a: new { item.Entity.ID, item.Entity.Nombre, item.TipoCliente.Descripcion }; donde item es un objeto del tipo ICliente y naturalmente la clase Cliente implementa la interfaz ICliente, todo se hace mas sencillo y menos trabajoso para el developer.

Los tipos anonimos han logrado facilitarnos la vida, como NO tienes idea.

Partial Class en Visual Studio .NET

Una de las mejoras del C# 2.0 son las Partial Class o clases parciales.

Partial Class permite definir una misma clase y sus miembros en archivos .cs distintos.

Una de sus primeras aplicaciones lo encontramos en los .designer de las ASPx web pages.

Pues en las versiones anteriores del Visual Studio .NET previas al 2005 los elementos definidos en el diseñador de las paginas ASPx eran plasmados en un solo archivo aspx.cs.

Lo cual se le hacia muy complicado gestionar al Visual Studio .NET 2002 y 2003, por ejemplo.

Hoy esto ha sido superado. Facilitando el manejo del designer y la estabilidad del Visual Studio .NET 2005 y con mayor razon en el Visual Studio .NET 2008.

Usar las Partial Class es un primer ejemplo del Divide y Venceras.

MARS MultipleActiveResultSets True

Cuando estas trabajando con SqlDataReader para obtener informacion del SQL Server 2005 muy probablemente te encuentres con este mensaje al ejecutar el metodo ExecuteReader del SqlCommand:

There is already an open DataReader associated with this Command which must be closed first.

En terminos sencillos, se nos dice, que ya tenemos un SqlDataReader que se encuentra abierto y NO seria posible aperturar otro al mismo tiempo, mientras NO se cierre el primero.

Para este incidente, el SqlServer2005 brinda la posibilidad de agregar una propiedad al ConnectionString para permitir multiples SqlDataReader abiertos, al mismo tiempo.

Agregando MultipleActiveResultSets=True al ConnectionString se resuelve el problema.

Sin embargo recuerda que esta facilidad solo esta permitida en SQL Server 2005 y superiores.

En la version del SQL Server 2000 esta propiedad para el ConnectionString NO esta factible de utilizar. Por lo que el error aun prevalecera.

SetValue PropertyInfo FieldInfo Struct

Cuando defines tus Business Entities como structuras y NO como clases, es decir como struct.

Estableciendo sus diferentes atributos, para que posteriormente manejar el mapping correcto con su correspondiente tabla a nivel de base de datos, requeriras de una mecanismo generico para hacer la lectura de los registros de dicha tabla de base de datos hacia una coleccion de Business Entities, para manejarlos como tal dentro del mundo .NET

Hasta alli, todo relativamente normal.

Pero al usar un struct para definir cierto Business Entity, te daras cuenta que el metodo SetValue del PropertyInfo o el FieldInfo -dependiendo lo que estes usando para definir las propiedades o atributos de tu Business Entity- NO estan funcionando como tu esperas.

Lo que sucede es que las estructuras o struct, son tipos de datos por valor a diferencia de las clases o class.

Y este es uno de los puntos en contra al utilizar estructuras o struct para definir tus Business Entities.

En este incidente la clase ValueType resuelve tu problema.

TEntity entity = new TEntity();

Debera ser reemplazado por:

ValueType entity = new TEntity();

Dentro del bucle que este leyendo el SqlDataReader para iterar cada uno de los registros de la consulta que hayas realizado, mapeando cada uno de estos registros dentro de su Business Entity para retornar finalmente a una coleccion de Business Entities, a quien haya utilizado el metodo generico que implementaste.

IEnumerable ExecuteReader( String sql ) where TEntity : struct

Vale recalcar que es importante utilizar la clausula where TEntity : struct para poder instanciar el template TEntity dentro de la implementacion de dicha funcion y para poder castearlo a un ValueType, posteriormente.

Top Down versus Bottom Up

Cuando desarrollamos software con conectividad a Base de Datos, nos encontramos con diferentes herramientas, en el mercado, que facilitan la construccion de los Business Entities a partir de una estructura de datos relacional.

El resultado es alentador. Gracias al Drag & Drop o algo relativamente similar obtenemos los Business Entities para el mundo .NET desde el conjunto de tablas que se encontraban ya definidas en la Base de Datos.

Esta es una perspectiva Bottom-Up.

Pues partimos del nivel mas bajo de la arquitectura de un producto de software, la Base de Datos, para facilitar la contruccion de las demas capas de la arquitectura, aquellas que estan por encima de la Base de Datos.

Pero existe la posicion contraria. Un punto de vista distinto, llamado Top Down.

A partir del cual prototipeamos las interfaces de usuario, con las cuales este -el usuario- ha de interactuar con el producto de software que vayamos a construir, para ir construyendo conceptualmente las demas capas de nuestra arquitectura de software.

Seguidamente un modelo de clases que se desprendera a partir de la discusion y analisis de los casos de uso, sera nuestro siguiente paso.

Dicho modelo de clases orientados al negocio del producto de software, que tenemos la mision de construir, estan relacionados en funcion a: herencia, asociacion, agregacion y otros mecanismos de relacion los cuales NO necesariamente deberian plasmarse tal cual en la estructura de datos final, ya en la Base de Datos.

Y he aqui la moraleja.

Ambas perspectivas tienen sus pros y contras, cada una de ellas validas desde sus respectivos puntos de vista.

Pero ambas perspectivas: Top Down y Bottom Up, se encuentran en ese punto. Aquel punto donde la conciliacion es el mejor fusible, para tener contentos a la mayoria, pero NO siempre la mejor solucion.

Para Bottom Up un Business Entity en terminos sencillos deberia ser tal cual una tabla que esta definida a nivel de Base de Datos. Tantas propiedades en cada Business Entity como columnas existan en la tabla correspondiente.

Por otro lado, Top Down propone algo diferente pues la relacion de una herencia o una agregacion a nivel de un modelo de clases de negocio NO se plasman tan facilmente a nivel de Base de Datos.

Menudo problema.

Web Service Software Factory

El Web Service Software Factory es una verdadera cochinada.

Más de cuatrocientos archivos que construye aquel bendito tool, de un modelo de NO mas de 20 tablas en mi base de datos, son prueba indubitable e insoslayable de la afirmación inicial.

Por cierto, recuerdo que tuve que renombrar a nivel del tool, todas la tablas e inclusive los campos de las mismas, para poder obtener un resultado relativamente decenten, en principio, a nivel de Business Entities.

Pero conforme vas haciendo cambios a nivel de la estructura de datos, te das con la amarga sorpresa, que esto trae como consecuencia que tengas que zambullirte en las cuchumil cuatrocientas clases creadas en el Data Access de tu solución.

Yo solo quiero hacer un UPDATE en un campo de una de mis tablillas. ¿Por que me complicas la vida?

¿Acaso no pensaron colocar un boton en el tool que diga algo asi como REFRESH?

En fin, esas son una de las razones por la que usar esta cochinada es una verdadera perdida de tiempo.

Nada como el BusinessLayer.Components y el BusinessLayer.Entities liberado hacer unos años atras, y que fue un golazo en su momento.

Hoy sin embargo, en los cuarteles de invierno, construyendose la version para LINQ aprovechando los lambda expression y clases anonimas para acelerar la construcción del Desarrollo de Software y que favorezca la estabilidad en dicha fase de producción.

Tan distante de las actuales realidades.