ich programmiere ein Programm, dessen Verhalten von Konfigurationsdateien gesteuert wird. Die Konfigurationen sind im XML-Format beschrieben, aber mit dem Aufbau bin ich ueberhaupt nicht zufrieden. In einer Konfiguration(sdatei) ist z.B. beschrieben, wie eine Pipeline aufzubauen ist, welche Eigenschafte die einzelnen Pipeline-Stationen erhalten und so weiter. Hier ist ein Beispiel einer Konfiguration (es gibt leider keinen XML-Tag, also HTML):

<pipeline_modules>
	<module> <!-- das erste Modul ist immer die Datenquelle 
		(es gibt unterschiedliche) -->

		<!-- type weist auf die Pipeline-Station/Modul hin, 
		das gebaut werden soll -->
		<type>FlatFileSource</type>

		<!-- Wenn hier ein Pfad zu einer Datei steht, wird  
		das Modul mit diesem Pfad initialisiert, wenn der 
		Knoten leer bleibt, wird der Pfad in der GUI angegeben -->
		<data_source></data_source> 
	</module>
	<module>
		<type>CSVParser</type>

		<!-- es koennen mehrere, unterschiedliche Trennzeichen zur 
		gleichen Zeit verwendet werden -->
		<delimiter>
			<character>;</character>
			<hexadecimal>09</hexadeciaml> <!-- Tab-Trennzeichen -->	
		</delimiter>
	</module>
	<module>
		<type>TextFilter</type>
		<filter>
			<content>blank</content>
			<content>12345</content>
			<line>1</line> <!-- das ist nicht immer erforderlich -->
		</filter>
	</module>
	<module>
		<!-- andere -->
	</module>
</pipeline_modules>

Es ist irgendwie Chaotisch. Noch deutlicher wird es, wenn in einer anderen Konfiguration andere Module erforderlich sind, und die Parameter sich aendern:

<pipeline_modules>
	<module> <!-- Datenquelle -->
		<type>SqlServerTableSource</type>
		<connection_string>ConnectionString</connection_string>
		<data_source>EinTabellenName</data_source> 
	</module>
	...
</pipeline_modules>

Das alles in die Konfig zu tippen ist ja leicht, aber es ist schwierig, einen sauberen Parser zu schreiben (ich meine keinen XML-Parser, sondern einen, der mithilfe eines XML-Parsers die Struktur parst). Habe da noch nicht viel Erfahrung mit Konfigurationen.

Momentant verwende ich eine switch- und if-Orgie, und das ist schrecklich. Das liegt eben daran, dass sich die die Knoten-Namen von Konfig zu Konfig aendern, und meist oft verschachtelt sind, wo sich auch wieder die Namen der Knoten aendern. Den kleinsten gemeinsamen Nenner kann ich fuer die Knoten-Namen nicht finden, die Konfigurationen muessen flexibel sein.

Kennt jemand vielleicht einen sauberen Weg und hat Erfahrung, was flexible Konfigurationen anbelangt?

Soooo schlecht sieht das gar nicht aus was Du da machst.

Um Baumstrukturen vernünftig abzufragen, siehe Dir doch mal das Kompositum (Composite) Pattern der GoF an
http://de.wikipedia.org/wiki/Kompositum_(Entwurfsmuster)

Um endlose Routinen zu vermeiden, um die Baumstrukturen zu parsen, nutze den das DOM Model (Parser)
http://en.wikipedia.org/wiki/Document_Object_Model

und den Standard XPath:
http://www2.informatik.hu-berlin.de/~obecker/obqo/w3c-trans/xpath-de/

Nicht die Konfig war das Problem, sondern was Du damit machst.

cu
P84

Hallo Welt,

ich programmiere ein Programm, dessen Verhalten von Konfigurationsdateien gesteuert wird. Die Konfigurationen sind im XML-Format beschrieben, aber mit dem Aufbau bin ich ueberhaupt nicht zufrieden.

Hallo endline,

ist XML àls Format vorgegeben?

Um Baumstrukturen vernünftig abzufragen, siehe Dir doch mal das Kompositum (Composite) Pattern der GoF an
http://de.wikipedia.org/wiki/Kompositum_(Entwurfsmuster)

Was meinst du denn damit?

Prof84 schrieb:

Um endlose Routinen zu vermeiden, um die Baumstrukturen zu parsen, nutze den das DOM Model (Parser)
http://en.wikipedia.org/wiki/Document_Object_Model

und den Standard XPath:
http://www2.informatik.hu-berlin.de/~obecker/obqo/w3c-trans/xpath-de/

Was spricht hier gegen SAX? Wenn ich das richtig verstanden habe wird das Dokument einmal durchlaufen, die Pipeline aufgebaut und fertig.

endline schrieb:

Hallo Welt,

ich programmiere ein Programm, dessen Verhalten von Konfigurationsdateien gesteuert wird. Die Konfigurationen sind im XML-Format beschrieben, aber mit dem Aufbau bin ich ueberhaupt nicht zufrieden.

Hallo endline,

ist XML àls Format vorgegeben?

Nein. Ich kann benutzen, was ich will...
Ich hab XML genommen, weil es einfach zu parsen ist, mit gegebenen Libraries.

Was spricht hier gegen SAX?

Ich schau mir das mal an.

<pipeline_modules>

    <FlatFileSource datasource=true>  <!-- "datasource=true" gibt an, dass es die Datenquelle ist -->
        <!-- Wenn hier ein Pfad zu einer Datei steht, wird  
        das Modul mit diesem Pfad initialisiert, wenn der
        Knoten leer bleibt, wird der Pfad in der GUI angegeben -->
        <data_source></data_source>
    </FlatFileSource>

    <CSVParser>
        <delimiter character=';'/>
        <delimiter hexadezimal='09'/>
    </CSVParser>

    <TextFilter>
        <content>blank</content>
        <content>12345</content>
        <line>1</line> <!-- das ist nicht immer erforderlich -->
    </TextFilter>

    <moduleXY>
        <!-- andere -->
    </moduleXY>

    <SqlServerTableSource> <!-- Datenquelle -->
        <connection_string>ConnectionString</connection_string>
        <data_source>EinTabellenName</data_source>
    </module>

</pipeline_modules>

Finde ich persönlich jedenfalls übersichtlicher, und dann halt noch genau spezifizieren, welche Inhalte drin sein müssen/dürfen.

finix schrieb:

ist XML àls Format vorgegeben?

Nein. Ich kann benutzen, was ich will...
Ich hab XML genommen, weil es einfach zu parsen ist, mit gegebenen Libraries.

Dann wären vielleicht YAML, JSON oder gar - - SEXPs eine Alternative.

Was natürlich nicht automatisch das Problem deiner "switch- und if-Orgie"^* löst.

endline schrieb:

Was spricht hier gegen SAX?

Ich schau mir das mal an.

SAX ist kein Format, sondern einfach eine andere Variante XML-Dateien einzulesen.

^* Wie sieht dein Parser denn derzeit aus? Das sieht doch aus als ließe es sich perfekt modularisieren.

Dann wären vielleicht YAML JSON SEXPs eine Alternative.

oder das hier: http://en.wikipedia.org/wiki/Type-length-value
ist eben nur kein textformat.

Was meinst du denn damit?

Wenn er ein variables Konfigurationsschema hat, muss er naturlich in seiner Applikation ein variables Parse- und Build-Model bauen. So kann man eine Ausrollung des Baumes verhindern, was dann zu unzähligen Fallunterscheidungen führen würde.

finix schrieb:

Was spricht hier gegen SAX? Wenn ich das richtig verstanden habe wird das Dokument einmal durchlaufen, die Pipeline aufgebaut und fertig.

Das Problem bei SAX ist, dass er das Parse- und Build-Modell gleichzeitig umsetzen muss während er die Konfig durchläuft. Das führt im Regelfall zur Redundanz und fordert ein sauberes 'Design by Contract' im System Engineering. D.h.: Wenn sich Abhängigkeiten zwischen Modulen ergeben kannst Du jene mit SAX nicht nutzen ohne das Parsen wieder von Vorne zu beginnen. Deshalb meine Empfehlung zu DOM.

<pipeline_modules>
	<module> <!-- Datenquelle -->
		<type>SqlServerTableSource</type>
        <params>
		     <connection_string>ConnectionString</connection_string>
		     <data_source>EinTabellenName</data_source> 
        </params>
	</module>
	...
</pipeline_modules>

Dann würde ich type und die params an ne Factory übergeben. Die Factory hat ne Map mit key = type und value = Utilityklasse die das Modul erstellt. Die params übergibst du dann an die Utilityklasse und die erstellt damit das entsprechende Modul.

Nehmen wir an du hast eine einfache .ini-Datei mit folgendem Eintrag:

farbe = rot

Dann liest du das ein, und speicherst das Paar ("farbe" , "rot") ab.

Über die Klasse bietest du dann eine Funktion an, mit der du den Wert eines bestimmten Konfigurationseintrages erhälst.
Also so etwas:

std::string getValue(std::string conf);

Dann greift der Rest deines Codes halt nicht auf irgendwelche Variablen zu, sondern auf die Konfigurationsklasse.

Könnte so funktionieren.

Viele Grüße

EDIT:
Vielleicht war das sowas Ähnliches, wie mein Vorposter mit seiner Factory-Lösung meinte...

finix schrieb:

Was meinst du denn damit?

Wenn er ein variables Konfigurationsschema hat, muss er naturlich in seiner Applikation ein variables Parse- und Build-Model bauen. So kann man eine Ausrollung des Baumes verhindern, was dann zu unzähligen Fallunterscheidungen führen würde.

Ich weiß dass du gerne mit Fachwörtern und Buzzwörtern und Phrasen hantierst, aber könntest du dich einen Augenblick zügeln?

Deine Ausführung verrät mir kein bisschen worin du das Problem eines "variables Konfigurationsschemas" siehst, was du überhaupt mit "Ausrollung des Baumes" meinst bzw. wo die "unzähligen Fallunterscheidungen" herkommen oder wie das Composite Pattern hier Abhilfe schafft.

Prof84 schrieb:

finix schrieb:

Was spricht hier gegen SAX? Wenn ich das richtig verstanden habe wird das Dokument einmal durchlaufen, die Pipeline aufgebaut und fertig.

Das Problem bei SAX ist, dass er das Parse- und Build-Modell gleichzeitig umsetzen muss während er die Konfig durchläuft. Das führt im Regelfall zur Redundanz und fordert ein sauberes 'Design by Contract' im System Engineering. D.h.: Wenn sich Abhängigkeiten zwischen Modulen ergeben kannst Du jene mit SAX nicht nutzen ohne das Parsen wieder von Vorne zu beginnen. Deshalb meine Empfehlung zu DOM.

Inwieweit ist ein Single Pass Modell ein Problem (sicher nicht wegen "Abhängigkeiten zwischen Modulen")? Wegen der SAX-spezifischen Redundanz (was meinst du damit, und wo kommt die her)?

Also wenn ich dich richtig verstanden hab, dann hat jedes module nen type und dann unterschiedliche parameter.
Dann würde ich es so machen.

<pipeline_modules>
	<module> <!-- Datenquelle -->
		<type>SqlServerTableSource</type>
        <params>
		     <connection_string>ConnectionString</connection_string>
		     <data_source>EinTabellenName</data_source> 
        </params>
	</module>
	...
</pipeline_modules>

Dann würde ich type und die params an ne Factory übergeben. Die Factory hat ne Map mit key = type und value = Utilityklasse die das Modul erstellt. Die params übergibst du dann an die Utilityklasse und die erstellt damit das entsprechende Modul.

Die Idee gefällt mir gut. Es gab noch andere hilfreiche Tips, ich hab schon eine Vorstellung davon, wie ich das kombiniere und wie das Endprodukt aussieht

Danke an alle!