[RESUELTO] Guardar estructura de memoria (clases) a disco

[Neftali [Germán.Estévez]]

Buenas a todos.
No se si el título explica claramente lo que necesito hacer, así que intentaré explicarme un poco mejor.

Se trata de que tengo en memoria una serie de datos almacenados en clases y listas de elementos que debo exportar a disco. Es una estructura compleja, por ejemplo una clase A, que posee propiedades (algunas enteros y otras cadenas) y una lista de elementos de la clase B. A su vez la clase B posee algún ENTERO, algún STRING y una lista de elementos de la Clase C. La clase C a su vez son una lista de PUNTOS y alguna propiedad más.

La estructura no es exactamente así, pero es bastante aproximada para que os hagáis una idea. La representaríamos como se ve a continuación.

Código Delphi [-]

Clase A
==============
prop1: integer
prop2: integer
prop3:string
prop4: List of ClaseB
...

Clase B
=============
prop1: boolean
prop2: string
prop3: integer
prop4: List of claseC
...

Clase C
==============
prop1: List of Tpoint
prop2:Tcolor
...

Ya tengo una o dos ideas para almacenarlo en disco (BACKUP) y después poder recuperarlo (RESTORE), pero la verdad es que ninguna de ellas me resulta sencilla.
Ya sea guardar en un formato tipo XML/JSON/... o incluso guardarlos en ficheros planos y empaquetarlo todo en un ZIP.

El caso es que estaba dándole vueltas a si habría alguna manera más fácil de hacerlo que no signifique recorrer todos los elementos de todas las clases. Algo así como el WriteComponent de la clase TStream. Algo que me permita "volcar" toda la clase y recuperarla de una sóla vez.
A lo mejor estoy "desvariando"... Si es así no me hagáis caso...

Se aceptan ideas, sugerencias, críticas,...

P.D: No necesito código sólo una idea/orientación.

[roman]

Quizá si derivas de TComponent/TCollectionItem y usas TCollection para las listas puedas usar WriteComponent y ReadComponent.

// Saludos

[dec]

Hola,

O lo ya apuntado o usar RTTI de forma más o menos similar a la explicada en este artículo. Reconozco que ahora mismo no se me ocurre otra forma. Quizá que tratando de hacerlo con "WriteComponent" y "ReadComponent" el asunto pueda resultar algo más rápido de implementar (digo yo...) y también más rápido a la hora de realizar la tarea en cuestión.

[Neftali [Germán.Estévez]]

Empezado por roman

Quizá si derivas de TComponent/TCollectionItem y usas TCollection para las listas puedas usar WriteComponent y ReadComponent.

Después de escribir lo del WriteComponent lo he pensado, pero hay también algún record.
De todas formas si fuera por eso estos records se podrían convertir a otra cosa.

Le doy una vuelta Román.
Gracias.

[Neftali [Germán.Estévez]]

Empezado por dec

O lo ya apuntado o usar RTTI de forma más o menos similar a la explicada en este artículo.

Hola David, gracias por el link.
Lo he ojeado por encima y tiene buena pinta aunque no se si cubre lo que necesito. ¿Qué pasaría con las clases anidadas?
No veo claro que con eso se puedan añadir al mismo fichero; Y me queda también la duda de las listas.

[[Al González]]

Hola Germán.

Empezado por roman

Quizá si derivas de TComponent/TCollectionItem y usas TCollection para las listas puedas usar WriteComponent y ReadComponent.

Este que comenta Román sería el camino más directo, pero supongo que por una buena razón esas clases no derivan de TComponent. Relacionado con esto, ya has de saber que la clase padre de TComponent, TPersistent, es la primera en introducir mecanismos de streaming:

Use TPersistent as a base class when declaring objects that are not components, but that need to be saved to a stream or have their properties assigned to other objects.

Por otro lado, sea cual sea el mecanismo que uses, es menester que la información de las propiedades esté disponible mediante reflexión (RTTI), lo cual hace que tengas que declarar dichas propiedades con visibilidad publicada (published).

Eso último se flexibiliza a partir de Delphi 2010, y el artículo que refiere dec va muy bien con el tema.

Ya nos dirás más, saludos.

[Neftali [Germán.Estévez]]

Le voy a dar otra vuelta al artículo, porque me parece que la primera vez lo he mirado "demasiado por encima"...

En cuanto a porqué las clases no derivaban de TComponent, es simplemente porque no son componentes.
En este caso no habría ningún problema en derivarlas de TPersistent si eso me aporta beneficios y tampoco lo hay en cuanto a la visibilidad de las propiedades, pues ahora son públicas y no hay problema en convertirlas a published para añadir datos de RTTI.

A ver si mañana puedo hacer alguna prueba para evaluar ambas soluciones y os comento...

Gracias.

[roman]

Empezado por Al González

Relacionado con esto, ya has de saber que la clase padre de TComponent, TPersistent, es la primera en introducir mecanismos de streaming:

Sí lo sabía pero oprimí Enviar muy rápido De hecho, TCollectionItem y TCollection derivan directamente de TPersistent.

// Saludos

[[Al González]]

Sobre los objetos anidados, no hay más camino que recorrer todos los elementos, entrando a cada propiedad objeto o lista de objetos. Eso ya lo hace WriteComponent. Pero si quieres implementar un mecanismo propio que evite la derivación de TComponent, entonces puedes echar una mirada a los métodos WriteProperties y WriteProperty de la clase nativa TWriter. Aunque en lo personal y teniendo Delphi 2010 o superior, buscaría en él algo de la RTTI extendida que facilite las cosas.

Lo de la "buena razón", ni qué decir...gajes del oficio de abreviar.

[dec]

Hola,

Al, por lo poco que sé, me parece que, a partir de Delphi 2010, no es necesario para trabajar con RTTI declarar propiedades "published", puesto que antes de Delphi 2010 sí que era como dices. Germán, me extraña que no tengas tú sobrada experiencia recorriendo objetos y posibles propiedades luego de tu proyecto GLibWMI. Creo recordar que también te toca lidiar con diferentes tipos de propiedades y resultados, etc. Pienso que no es exactamente igual, pero, es parecido. Además, es posible que no tengas que construir todo un "Serializador de objetos", sino algo que te apañe de momento, al menos.

[[Al González]]

Empezado por Al González

[...] sea cual sea el mecanismo que uses, es menester que la información de las propiedades esté disponible mediante reflexión (RTTI), lo cual hace que tengas que declarar dichas propiedades con visibilidad publicada (published).

Eso último se flexibiliza a partir de Delphi 2010, y el artículo que refiere dec va muy bien con el tema.

Empezado por dec

Al, por lo poco que sé, me parece que, a partir de Delphi 2010, no es necesario para trabajar con RTTI declarar propiedades "published", puesto que antes de Delphi 2010 sí que era como dices.

Tienes razón, David. Por eso lo de: «Eso último se flexibiliza a partir de Delphi 2010».

[[Delphius]]

Sea cual fuese el camino que elijas Neftali, todo te llevará a hacer uso de RTTI... es inevitable.
Ya sea que derives de TPersistent, TComponent y/o diseñes tus propios métodos (fuera de la jerarquía de clases de las anteriores) para llevar a cabo esto.. te toparás con RTTI.
No conozco el método WriteComponent que comentan pero estoy casi segurísimo que por dentro todo, de uno u otro modo, lo que hace es valerse de la RTTI (ya sea la básica, o la extendida desde la salida de 2010) para tener acceso a las propiedades del componente para guardar los datos en algún archivo.

Lo que habría que estudiar es el problema que pudiera afectar al anidamiento. Partamos de lo fundamental ¿Que sucede, por defecto, con el writeComponent cuando uno guarda el objeto? En base a eso ya se podría saber si es viable esta opción... O si se deberá irse a los palos e ingeniárselas para implementar algo propio que vaya leyendo el objeto en cuestión y definir algún formato/estructura propia para el archivo.

La otra posibilidad es ver si de por casualidad no hay algún motor de persistencia que tenga la posibilidad de "exportar" a archivos los objetos y no a bases de datos.

Saludos,

[roman]

Empezado por Delphius

Sea cual fuese el camino que elijas Neftali, todo te llevará a hacer uso de RTTI... es inevitable.

Bueno, yo creo que esto es demasiado tajante. No veo porqué no pueda volcarse la estructura en un archivo XML, por ejemplo, sin utilizar ni un gramo de RTTI. Otra cosa es que [muy] posiblemente el uso de RTTI pueda facilitar el trabajo.

// Saludos

[Neftali [Germán.Estévez]]

Empezado por dec

Germán, me extraña que no tengas tú sobrada experiencia recorriendo objetos y posibles propiedades luego de tu proyecto GLibWMI.
...Además, es posible que no tengas que construir todo un "Serializador de objetos", sino algo que te apañe de momento, al menos.

Si no es por no ir, si hay que ir, se va...
Pero es que me daba mandra y me entró la curiosidad...

Al final estoy viendo que es bastante problabe que tenga que hacer algún recorrido.

[[Delphius]]

Empezado por roman

Bueno, yo creo que esto es demasiado tajante. No veo porqué no pueda volcarse la estructura en un archivo XML, por ejemplo, sin utilizar ni un gramo de RTTI. Otra cosa es que [muy] posiblemente el uso de RTTI pueda facilitar el trabajo.

// Saludos

Podrá haber parecido un tanto tajante pero es que a mi modo de ver (y hasta donde llegan mis conocimientos) no hay otra forma.
Si en verdad se puede volcar un objeto, de forma genérica, a un archivo XML (o uno cualquiera) sin usar RTTI ¿puedo pedir una muestra de tu parte?

Porque a menos que el árbol de jerarquía al que se enfrente Neftali sea pequeño y sus clases no tengan demasiada complejidad pues allí si podría imaginarme una alternativa casera, y sin usar RTTI... pero a la larga me sentiría como que estoy haciendo doble (o triple) trabajo.
Mi versión casera sería la siguiente:
1) En la clase base de mis clases "persistentes" (si es que la hay) declaro un método Materialize abstracto.
2) Luego en cada clase concreta le doy la implementación adecuada y me pongo como loco, propiedad a propiedad, o atributo por atributo a pasar los datos al archivo. Algo como:

Código Delphi [-]
writeln('NombrePropiedadN');
writeln(PropiedadN);
writeln('NombrePropiedadN');
writeln('NombrePropiedadMTipoRegistro');
writeln('NombreCampoZDeLaPropiedadMdeTipoRegistro');
write(PropiedadMTipoRegistro.CampoZ);

Y si... no hay un gramo de RTTI pero, ¿En serio consideras algo práctico esto? Y Mira que entiendo que podría ser una salida muy fácil y simple (y hasta cierto punto, "económica")... ¡De veras estoy intentandolo llegar al principio KIS!

De poder se puede... pero, hasta donde tengo entendido me parece que esto es justamente lo que quiere evitar Neftali y busca algo que sea más genérico y le haga más directa la cosa. De allí que a que yo diga... "Pos, no queda otra... todo apunta a roma".

Saludos,
PD: No se porqué pero si escribo dentro de las etiquetas delphi las < y /> me elimina el texto interno. Seguramente es por una cuestión de seguridad En mi código debiera leerse '<Algo>' y '</Algo>'. Como si estuviera escribiendo un XML a los pelos.

[ecfisa]

Empezado por Delphius

...
PD: No se porqué pero si escribo dentro de las etiquetas delphi las < y /> me elimina el texto interno. Seguramente es por una cuestión de seguridad En mi código debiera leerse '<Algo>' y '</Algo>'. Como si estuviera escribiendo un XML a los pelos.

Hola Delphius.

Se debe a un problema existente en la interface del editor de mensajes cuando tenes seleccionado "Interfaz Mejorada - Edición con WYSIWYG". También suele descolocar los códigos Delphi en el mensaje cuando haces "Vista previa del Mensaje" antes de publicarlo.

Por ese motivo me he acostumbrado a usar el modo "Editor Estándar - Controles de Formato Extra", que aunque un tanto espartano, no presenta ningún problema.

Saludos.

[Neftali [Germán.Estévez]]

Estoy en ello.... En breve espero presentar resultados.
Mi intención es intentar conseguirlo haciendo lo que os comenté; Utilizando los métodos que trae Delphi para volcar componentes en un Stream y recuperarlos.

Se puede hacer, como bien habéis dicho volcando a XML (o JSON) haciendo un "parser" (ya sea específico para estas clases o genérico para todas -que viene a ser algo similar al link que me puso David al principio-), pero como también comenté, la gracia está en conseguirlo sin eso.

Un saludo.

[roman]

Empezado por Delphius

Podrá haber parecido un tanto tajante pero es que a mi modo de ver (y hasta donde llegan mis conocimientos) no hay otra forma.

Veamos...

Empezado por Delphius

Si en verdad se puede volcar un objeto, de forma genérica, a un archivo XML (o uno cualquiera) sin usar RTTI ¿puedo pedir una muestra de tu parte?

¿Quién habló de genericidad? Hasta donde colijo de lo decrito por Neftalí en un principio, se trata de clases específicas de su aplicación.

Empezado por Delphius

Porque a menos que el árbol de jerarquía al que se enfrente Neftali sea pequeño y sus clases no tengan demasiada complejidad pues allí si podría imaginarme una alternativa casera, y sin usar RTTI... pero a la larga me sentiría como que estoy haciendo doble (o triple) trabajo.

¿Acaso mencioné que sería fácil? Justamente mencioné que otra cosa sería que el uso de RTTI pueda facilitar el trabajo.

Empezado por Delphius

Mi versión casera sería la siguiente:
1) En la clase base de mis clases "persistentes" (si es que la hay) declaro un método Materialize abstracto.
2) Luego en cada clase concreta le doy la implementación adecuada y me pongo como loco, propiedad a propiedad, o atributo por atributo a pasar los datos al archivo. Algo como:

Código Delphi [-]
writeln('NombrePropiedadN');
writeln(PropiedadN);
writeln('NombrePropiedadN');
writeln('NombrePropiedadMTipoRegistro');
writeln('NombreCampoZDeLaPropiedadMdeTipoRegistro');
write(PropiedadMTipoRegistro.CampoZ);

No entiendo por qué hay que ponerse como loco. Para eso se programan las cosas. Digo, creo que recorrer estructuras de datos tampoco es que sea uno de los doce trabajos de Hércules.

Empezado por Delphius

Y si... no hay un gramo de RTTI pero, ¿En serio consideras algo práctico esto? Y Mira que entiendo que podría ser una salida muy fácil y simple (y hasta cierto punto, "económica")... ¡De veras estoy intentandolo llegar al principio KIS!

¿En qué momento dije que fuera práctico? De todas formas habría que ver el problema específico para determinar su grado de practicidad. Que tampoco es que me parezca tarea titánica.

Empezado por Delphius

De poder se puede... pero, hasta donde tengo entendido me parece que esto es justamente lo que quiere evitar Neftali y busca algo que sea más genérico y le haga más directa la cosa. De allí que a que yo diga... "Pos, no queda otra... todo apunta a roma".

¡Ah! Bueno, pero es muy distinto decir "Sea cual fuese el camino que elijas Neftali, todo te llevará a hacer uso de RTTI... es inevitable."

a matizarlo con "me parece que esto es justamente lo que quiere evitar Neftali y busca algo que sea más genérico y le haga más directa la cosa."

// Saludos

[[Delphius]]

A ver Roman, yo releo el hilo y lo que estoy entendiendo es que si bien su diseño parece obedecer a algo como:

ClaseA <>--- ClaseB <>--- ClaseC <>--- TPoint

El mismo señala que es una aproximación y no una idea de que son únicamente 3 clases.

Creo que si vino con la duda es porque el trabajo no es tan directo, y si digo que al final va a llegar a trabajar con RTTI o que los caminos conducen a Roma es porque justamente si la intención es evitar algunas opciones, las que quedan de una u otra llevan a otro camino que igualmente no lleva a una solución tan directa como para hacer el trabajo de un tirón a como le gustaría.
Que será trabajoso seguro.

Y si te pedí un ejemplo que no fuera RTTI lo decía con buena manera, y yo me imaginaba algo que no fuera algo como lo que "pseudo" propuse. Te juro que quizá me imaginé que tenías (y quizá si lo tienes) algún haz en tu manga que sea NO-RTTI y sin llegar a ese enjendro que he propuesto. De allí que te preguntaba si tienes algo en mente.
En mi propuesta es lo más KIS que me vino ... Yo no te lo decía a ti en forma despectiva.
¿Hay algo más simple? ¿Que trucos tienes? En verdad quisiera saberlo; que me pica la curiosidad... tu me conoces . Yo no lo decía en mal plan. Es que me asombró que tu digas de que se puede. En serio, yo al leer tus palabras me dije: "¡No jodas! ¿Y sin hacer el mavarracho que me mandé?. Tengo que saberlo"

Si yo tuviera que implementar algo como mi propuesta, al llegar a la 4ta clase me volvería loco (más de lo que estoy). Aún para clases con pocos atributos. Es un diseño que llevaría muy posiblemente a metidas de dedos y problemas que vaya a saber cuando se los descubriría... si te digo que hasta confundo filas con columnas de una matriz al implementar algunas funciones algebraicas.

Esto me llevó al planteo de la posibilidad de si se puede contar con alguna forma genérica de llevar esto. Mis pensamientos me decían de que podría concebirse de alguna clase tipo XML-Parser que cuente con la funcionalidad de escribir/leer un XML de forma más cómoda. Algo como:

Código Delphi [-]
XMLParser.writeNode(NombreEtiqueta, Valor);

Pero inmediatamente me dije, segurísimo que ya existe una... creo que hasta tiene un nombre parecido. ¿Por casualidad no hay ya un TXMLParser en la VCL? No tengo Delphi a mano, como para comprobarlo.

Y bueno, a pesar de esta clase... mi cabeza me sigue diciendo que aún así no está resuelta la pregunta. ¿Y ahora? Me mando un método y pongo tanto "WriteNode" o "WriteSubNode" como propiedades tenga? Esa solución me lleva a que me estoy complicando, mejor tiro a RTTI y "automatizo".

Saludos,

[roman]

Empezado por Delphius

El mismo señala que es una aproximación y no una idea de que son únicamente 3 clases.

Eso no indica que quier hacer algo genérico, simplemente que no pone todos los detalles. Si las clases son conocidas por él de antemano no veo porqué no ha de poder hacerse un volcado a XML que, justamente, es una estructura jerárquica.

¿Código? No. No tengo ni una sóla línea. Pero estoy seguro que lo podría hacer. Claro, no sin antes buscar alguna opción que facilite las cosas, tal cómo hace Neftalí .

Y si lo hiciera con XML, desde luego usaría algo hecho para crear/leer archivos xml, no reinventaría la rueda.

// Saludos