Archivos INI vs XML

[MAXIUM]

Hola, ¿que sería más adecuado para guardar las configuraciones de mi aplicación?, ¿en que me beneficiarían los archivos XML?

Saludos y gracias

[[nlsgarcia]]

MAXIUM,

Empezado por MAXIUM

...¿que sería más adecuado para guardar las configuraciones de mi aplicación INI vs XML?, ¿en que me beneficiarían los archivos XML?...

Pregunto:

1- ¿Tiene algún sentido compartir la configuración de tu aplicación con terceros vía archivos XML?.

2- ¿Que es más fácil para tu aplicación : El manejo de archivos XML o INI?, ¿Como manejas los archivos XML?.

En mi opinión personal, si no tienes que compartir la configuración de tu aplicación con terceros lo más práctico es que uses el formato que te sea más versátil de manejar.

Espero sea útil

Nelson.

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

Personalmente prefiero los INI.
Son más fáciles de modificar por código, más fáciles de modificar manualmente, más claros para leer y posiblemente ocupan menos espacio que los XML.
No se me ocurre ninguna ventaja de los XML respecto a los INI.

Es más, antes que los XML, creo que optaría por los JSON.

[Casimiro Notevi]

Empezado por Neftali

Personalmente prefiero los INI.
Son más fáciles de modificar por código, más fáciles de modificar manualmente, más claros para leer y posiblemente ocupan menos espacio que los XML.
No se me ocurre ninguna ventaja de los XML respecto a los INI.
Es más, antes que los XML, creo que optaría por los JSON.

[[newtron]]

...pues si yo os contara que una gran parte de mis programas están en ficheros de texto .txt o .ini ...

[Casimiro Notevi]

Empezado por newtron

...pues si yo os contara que una gran parte de mis programas están en ficheros de texto .txt o .ini ...

Es lo más cómodo y simple, para qué complicarse

[[newtron]]

Empezado por Casimiro Notevi

Es lo más cómodo y simple, para qué complicarse

Pues si, bueno...tú has visto algo. Ahí tengo la definición de tablas y campos, triggers, los campos de los grids con sus propiedades, personalización de campos de las pantallas, etc.

[pacopenin]

No me gusta nada el XML. Sólo lo uso cuando es exclusivamente necesario (WebServices, intercambio de información con otras aplicaciones, etc). Para guardar mi propia información uso INIs. De hecho arrastro un XML (en realidad es un ClientDataSet) de hace tiempo para guardar las cadenas de traducción y llevo años con ganas de cambiarlo. Quizás con los propósitos de año nuevo....

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

Empezado por newtron

...pues si yo os contara que una gran parte de mis programas están en ficheros de texto .txt o .ini ...

Cuenta, cuenta...
¿Cual es el problema?

No digo que sirvan para todo, tal vez en determinadas circunstancias no sean lo más conveniente y estaría bien saber algunas de esas "situaciones".

[dec]

Hola,

En mi opinión los archivos XML ofrecen más posibilidades que los archivos INI, en el momento en que necesitemos cierta complejidad. Estoy pensando en los componentes I18n de Delphi Area, por ejemplo. Estos componentes guardan los datos "de lenguaje" de nuestra aplicación en un archivo XML. Ahora bien, echando un vistazo a este archivo, parece complicado hacer lo mismo usando un solo archivo INI que no se volviese tan incomprensible o más para un humano que el propio archivo XML de que hablo.

Personalmente guardo la configuración de mis aplicaciones en el Registro de Windows o en archivos INI. He usado también archivos XML, pero, reconozco que sin llegar a comprender en su momento su verdadera falta: seguramente los usé siguiendo cierta moda. El formato JSON que menciona Germán suena tentador, y, lo que hace tiempo me planteo es usar bases de datos SQLite. Las bases de datos SQLite podría superar al resto de formato, por ejemplo, por su facilidad para almacenar algún que otro archivo binario.

[[newtron]]

Empezado por Neftali

Cuenta, cuenta...
¿Cual es el problema?

No digo que sirvan para todo, tal vez en determinadas circunstancias no sean lo más conveniente y estaría bien saber algunas de esas "situaciones".

No hombre, ya he comentado algo alguna vez en otros hilos. Algunos ejemplos:

- Las tablas y los campos de cada una de las tablas las tengo en un archivo llamado Dbges.ini y es común a todas las instalaciones que hago de un programa determinado. Por otro lado, si hace falta crear tablas o campos personalizados para una instalación determinada los creo en un fichero llamado DbgesLocal.ini. Cuando hay una actualización del programa se ejecuta un proceso que lee primero el archivo Dbges.ini y a eso le añade lo que lee del DbgesLocal.ini (si existe) y adapta las tablas en función a esos archivos. De esta manera al actualizar el programa se sobreescribe el Dbges.ini con nuevos campos "estandar" y al mismo tiempo se mantienen los campos personalizados porque el DbgesLocal.ini no se toca.

- La definición de los campos de la mayoría de grids del programa está también en ficheros de texto con sus propiedades. Cada vez que se abre un formulario se lee un fichero de texto con el que se "montan" el/los posibles grids e igualmente hay ficheros de texto "estandar" y también puede haberlos personalizados para una instalación determinada con lo cual un mismo programa puede tener grids distintos dependiendo de la configuración del cliente. Igualmente se pueden añadir, modificar o quitar labels, edits, combobox, etc. de la mayoría de las pantallas del programa con ficheros de texto personalizados.

- Los informes los creamos con un diseñador propio y guardamos en ficheros de texto las propiedades del impreso, tablas afectadas, campos, etc. Posteriormente para emitirlos se llama a una función que lee ese fichero y ejecuta el informe. Igualmente se pueden personalizar informes localmente y dependiendo de la instalación que lo lance con un formato u otro.

Basicamente es esta la idea, tener la posibilidad de personalizar un programa dependiendo de la instalación y sin tocar el código fuente. Esto es porque en los programas de gestión en particular siempre te plantean poner, quitar o modificar campos y de esta manera podemos en un porcentaje elevado modificar el funcionamiento del programa y personalizarlo en función a los requerimientos del cliente.

Saludos

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

Empezado por newtron

No hombre, ya he comentado algo alguna vez en otros hilos. Algunos ejemplos:

Vale, vale,...
Había entendido mal la respuesta (eso pasa por que a veces leemos en diagonal... ).

Yo también los he utilizados por ejemplo, en configuraciones de formularios y DBGrids, y es el único caso en que tal vez no los volvería a usar o lo haría de otra forma, porque al crear el formulario y acceder a las configuraciones se "notaba" cierto retardo al acceder a disco.

Tamaño y posición de los formularios, configuración de columnas según las había dejado el usuario (visibles, orden de columnas en el grid y anchos de cada una de ellas), por otro lado estaban los filtros y ordenaciones definidas por el usuario, valorespor defecto definidos por el usuario,... Al final se juntaban unos cuantos ficheros que se cargaban al crear el formulario.

Ese es el único caso en que me he planteado no usarlos o hacerlo de otra manera. Pero por lo demás nunca me han dado ningún problema.

[elrayo76]

Alguien acá comento que se podría usar SQLite para almacenar la configuración. Con respecto a esto podría decir que es perfecta para este propósito.

Algunas aplicaciones como Firefox utilizan esta base de datos de escritorio. Firefox se que la usa para almacenar los marcadores, cookies, historial y otras cosas de configuración interna.

Si uno empieza a ver las carpetas de los distintas aplicaciones se darán cuenta que muchas usan esta base de datos.

Por eso mi opinión es porque complicarse con los XML o usar los INI si la tendencia es usar SQLite para guardar configuración. Además no hace falta usar un solo archivo de base de datos para guardar las cosas y para trabajar es mas fácil como usar las sentencia de base de datos que todos conocemos.

Este es mi humilde aporte.

Saludos,
El Rayo