Consejos para configuración de las Rejillas

[mamcx]

Lo que estas persiguiendo es el elusivo sueño de la multi-plataforma universal, completa, funcional, eficiente y bonita.

Spoiler?

Eso NO EXISTE.

Es la fantasia mas grande, costosa y quita-tiempo-dinero-recursos de la computación.

Aun cuando pienses que es mucho mas simple ("son solo grillas, todo en windows") es el mismo problema, pero a una escala menor. Puedes resistirte a la idea que te presento, argumentando que debería ser muy facil... pero es algo que décadas de experiencia en computación han probado ser cierto.


---

El problema de que esta ilusión y fantasia sea tan creíble es que puede ser aparentemente facil de lograr. Es como un linea que va de facil a imposible, y dependiendo, puede que sea facil o imposible.

Como se llega a una posible solución?

Se crea una sub-mini-plataforma (o: especificación o: runtime o similar) y se reconstruye sobre ella todo desde cero, apuntando a N-clientes/plataformas/targets/etc. Entiende en adelante con "plataforma" cualquier cosa que trata de unificar multiples cosas en un concepto, estilo, diseño unificado.

Esto es otra forma de decir que la multiplataforma persigue el principio de la mediocridad y genera una nueva plataforma que es una version inferior y/o diferente de cualquiera sobre la que se construya:

http://xkcd.com/927/

Lo que quiero decir y es importante entender es que "multiplataforma" no es " app en N plataformas" sino "app en una sub-mini-plataforma que emula a N-plataformas" por eso siempre hay una(s) plataformas que sufren mas que otras (ej: Java corre mejor en Unix que Windows, HTML en Firefox (o Safari, o Chrome, eso cambia todo el tiempo) que en IE, OpenGL en *nix, etc)

Mientras mas cerca a la maquina, mas posible. Mientras mas cerca al usuario, menos posible.

Si lees sobre MVC (modelo-vista-controlador) veras que la parte de modelo es muy viable hacerla generica, el controlador casi pero la vista *no*.

-----

Lo que quieres hacer se hace así:

Creas una especificación de lo que es una grilla a nivel generico. Lo que dices: Columna1 = Texto Just. Izq, Tipo= Numerico, Etc. (el modelo). Es irrelevante si lo metes en JSON, archivos .ini o lo que sea. Eso no es el problema.

Luego creas un adaptador (el controlador) que conecta a cada tipo especifico de grilla (la vista) y traduce de GrillaX a tu modelo y viceversa.

Osea:

MiEspecificacion.Alineacion = Izquierda | Centro | Derecha | Justificado

Dentro de MiTraductorDeEspecificacion

SubClase: ParaGrillaX

--GrillaX.Column1.TextAlign = ConvertirAGrillaX (MiEspecificacion.Alineacion)

ParaGrillaY

--GrillaY['col1'].Format.Text.Align = ConvertirAGrillaY (MiEspecificacion.Alineacion)

Lo simple sera relativamente simple, y lo demás quien sabe. El problema es que eventualmente te encontraras conque GrillaX hace trivial hacer tal cosa pero GrillaY no.

-----

Consejo? No hagas esto, o no hagas algo mas complejo de usar la funcionalidad que ya tiene la grilla de manejarse a si misma.

En vez de seguir la TEORICA VENTAJA (e ilusoria, falsa, quita tiempo, etc) de la solucion generica, usa la MEJOR opcion que tengas en la plataforma que tengas que resuelva de la mejor forma posible la tarea que tengas que resolver. Reducir las capacidades de tu solucion al nivel de la mediocridad no vale el esfuerzo.

P.D: Es MUY deseable crear soluciones genericas y todo eso. Siempre y cuando sepas y entiendas que a nivel de modelo/controlador es donde es factible y correcto eso esta bien. Pero tarde o temprano hay que saltar de lo generico a lo concreto y en el momento que se llega a lo concreto lo generico, por pura logica, deja de existir.

Ademas, y esto es algo difícil de entender, la OO + Estado es ENEMIGA de la generalización. Solo las funciones puras permite generalizar de forma global.

Osea: En el momento que entras a configurar sub-clases, se pierde la habilidad de aplicar soluciones genericas. Osea: Mientras mas cerca estas de resolver la tarea, menos generico puedes ser. Osea: Lo concreto es enemigo de lo generico. Osea: Si haces la forma como le sirve al usuario, has llegado al fin.

Las interfaces de usuario es algo concreto. Es por eso que se resisten a cualquier intento de hacerla supergenericas. Es por eso que es perdida de tiempo multi-plataformalizarlas.

[ecfisa]

Hola.

Sobre la generalización no tengo mas para agregar, mamcx lo expuso muy cláramente.

En referencia al tema del guardado y recuperación del formato, es muy sencillo de implementar en un TDBGrid:

Código Delphi [-]
unit DBGridExt;

interface

uses SysUtils, Classes, DBGrids;

type
  TDBGrid = class(DBGrids.TDBGrid)
  public
    procedure SaveToFile(const aFileName: TFileName);
    procedure LoadFromFile(const aFileName: TFileName);
  end;

implementation

procedure TDBGrid.LoadFromFile(const aFileName: TFileName);
begin
  if not FileExists(aFileName) then
    raise Exception.Create('No se encuentra el archivo');
  with TFileStream.Create(aFileName, fmOpenRead) do
  try
    ReadComponent(Self);
  finally
    Free;
  end;
end;

procedure TDBGrid.SaveToFile(const aFileName: TFileName);
begin
  with TFileStream.Create(aFileName, fmCreate) do
  try
    WriteComponent(Self);
  finally
    Free;
  end;
end;
end.

Luego basta con agregar DBGridExt al final de la cláusula uses de la sección interface de la unidad donde reside el DBGrid y ya estan disponibles estos nuevos métodos.

Saludos

[elrayo76]

Lo que pone ecfisa no lo conosco pero no es lo que necesito.

Lo que quiero es poder pasar de una base de datos todo lo que tengo guardado para configurar como se deben mostrar los datos en la grid (todo esto ya fue explicado en otro post).

Lo que quiero hacer es levantar desde la clase los datos que se le pasan mediente alguna propiedad, pero sin que la clase sepa ni haga uso de la base de datos. Tampoco quiero tener que levantar todos los datos en un ClienteDataSet, DataSet o similar fuera de la clase y luego pasarlos a la misma ya que estaría duplicando los datos en memoria y no tiene ningun sentido hacer esto.

Si nadie puede dar una respuesta a lo que pido, igualmente gracias por intentar ayudarme.

Saludos,
El Rayo

[[AgustinOrtu]]

Te lo explicó ecfisa perfectamente.

La idea es generar un archivo, reitero, similar a los .dfm donde estableces el formato de cada campo

En un grid campo es sinónimo de columna, lo que se traduce en TColumn

El objetivo es mandarle a tu grid una estructura, por ejemplo una lista, un array, el que más te guste, con el contenido del archivo. Recorres esa estructura, preguntando si el campo es igual al campo que referencia cada columna de tu grid, si es igual entonces asignas las propiedades.

Como leer el archivo debería ser responsabilidad de otro método por ejemplo el citado LoadFromFile, el cual se implementa fácilmente con la RTL. También podes hacerlo a mano usando un .ini, un .xml, un .txt, o un archivo binario.

Lo importante es que ese método provea de la información necesaria a otro método que se encarga de decirle a cada columna el formato que tiene que adoptar, asi como tamaño, fuente, ancho, si esta visible o no, título de cabecera, etc

[Casimiro Noteví]

Empezado por elrayo76

Si nadie puede dar una respuesta a lo que pido, igualmente gracias por intentar ayudarme.

Pero si ya te han respondido con distintas alternativas

[mamcx]

Empezado por elrayo76

Lo que quiero es poder pasar de una base de datos todo lo que tengo guardado para configurar como se deben mostrar los datos en la grid (todo esto ya fue explicado en otro post).

Entonces???? Guarda eso en la BD y se lo pasas a la clase

Empezado por elrayo76

Lo que quiero hacer es levantar desde la clase los datos que se le pasan mediente alguna propiedad, pero sin que la clase sepa ni haga uso de la base de datos. Tampoco quiero tener que levantar todos los datos en un ClienteDataSet, DataSet o similar fuera de la clase y luego pasarlos a la misma ya que estaría duplicando los datos en memoria y no tiene ningun sentido hacer esto.

????????

Y si no usas nada para pasar la info de un lado a otro... como pretendes que suceda??