XML - ein Erklärungsversuch

[Florian Hämmerle]

Hi!

Also mir gefällts . Das hin und wieder was nicht gleich klappt macht auch nichts - im Gegenteil finde ich. Dadurch wird man auf diese Fehler aufmerksam und macht sie selbst eher nicht mehr.

Schöne Grüße,
Florian

[Neumann]

Hallo,

hab mir 2 Videos angesehen; durchaus interessant. Wie und womit sind die Videos gemacht? So etwas könnte ich auch gut gebrauchen.

Gruß

Ralf

[Florian Hämmerle]

Camtasia 6

[stahli]

Also erst mal danke für die positive Resonanz!
Ich denke, Videos an sich sind immer ein ganz gutes Mittel für solche Infos - jedenfalls besser als seitenlange Erklärungen...
Leider habe ich zum Thema (insbesondere zu dem "XML-Experten") nur ein engl. gefunden.


@XHelp:
Ich wollte nur kurz einen Chrash-Einstieg erklären, was XML überhaupt ist und wie man das grundsätzlich unter Delphi nutzen kann.
Und mehr als das Gesagte weiß ich auch nicht wirklich (habe allerdings schon über beide Themen mal etwas gelesen )
Der wichtigste Aspekt ist sicher, dass man in die XML beliebigen Kram schreiben kann. Ob das dann letztlich einer zuvor geplanten Struktur entspricht, KANN man ggf. über eine Schema-Datei abprüfen lassen. Das ist halt ein völlig anderer Ansatz als mit "richtigen" Datenbanken.

@omata:
Das ist der dritte Weg und ich hoffe sehr, dass er mich glücklich macht! Also ich will meine Turnierverwaltung umstellen. Grundsätzlich arbeitet der Nutzer (Turnierveranstalter) mit meinem Programm mit Objekten. Er kann Spieler in Spiele ziehen, Spiele auf Felder etc, alles "haptisch".

Mein erster Versuch lief komplett mit Objekten. Datenobjekte haben Daten verwaltet, visuelle Objekte haben sie gebunden und die Daten angezeigt. Für das Speichern habe ich mir so eine Art erweiterte Ini erstellt. Zumindest konnte man mehr oder weniger strukturierte Daten in eine Textdatei schreiben. Das Problem wurden letztlich die Beziehungen der Datenobjekte untereinander. War ein Spiel fertig, mussten alle anderen Objekte ggf. ebenfalls Änderungen veranlassen, was (durch ... ähh ... unglückliche Umstände oft Probleme in Form von Rückkopplungen verursacht hat). Da die Daten im Speicher lagen und das Schreiben und Lesen von der Platte mehrere Sekunden dauerte, war ein Verbinden zweier Rechner (ein Rechner hätte als Auskunftssystem für die Spieler dienen sollen) nicht möglich.
Auf meiner Homepage sind ein paar Screenshots meiner Projekte, da ist die Objektnutzung schnell zu erkennen.

Der zweite Versuch: Firebird. Ich will also letztlich so etwas ähnliches wie die Delphi-IDE anbieten. Der Nutzer soll nicht mit Tabellen arbeiten, sondern mit Objekten, die er dynamisch erstellen kann (weiteres Turnier, Gruppe Mannschaft, Spieler etc) und die letztlich direkt in der Datenbank abgebildet werden. In der Datenbank sind auch die Wege abgebildet, die z.B. ein Sieger geht. Auch das wird bei der Konstruktion eines Turniers vom Nutzer vorab durch Klicks festgelegt. Hier kam ich im Moment mit meiner Firebird-Version nur sehr schwer weiter, da es viele unterschiedliche Möglichkeiten des Turnieraufbaus gibt. Ich denke mir, dass das mit einer definierten Baum-Objektstruktur in der Datenbank selbst einfacher wird.
Mein Hauptproblem waren aber gerade die Änderungen der Datenbank. Ich habe eine DB-Versionsnummer mitgeführt. Bei jedem geänderten Feld musste ich das an mehreren Stellen berücksichtigen. In der DB, im DB-Script für neue Turniere, in einem Differenzscript für ältere zu öffnende Turniere, in den DB-Schnittstellen usw.
Hier sollte die XML-Lösung toleranter sein, denke ich. Die Verbindung eines Auskunfts-PC ist natürlich unter Firebird gar kein Problem.

Die XML-Lösung: Bin ich gerade am Testen, aber sehr zuversichlich. Im Grunde ist das genau die Lösung zwischen den beiden obigen. Eine Anbindung eines Auskunfts-PC ist grundsätzlich möglich, indem am Arbeitsrechner bei erfolgten Änderungen das XML-File zyklisch gespeichert wird und die Datei von dem Auskunftssystem daraufhin neu geladen wird. Grundsätzlich funktioniert das (habe ich getestet), es bleibt nur die Frage, ob das für ein gesamtes Turnier noch schnell genug läuft. Es werden keine Millionen Datensätze verwaltet aber einige zig-Tausend Knoten werden es schon werden...
Alles weitere muss die Praxis zeigen, im Moment bin ich erst mal zuversichtlich (muss ja!)
Im Moment teste ich aus, ob die Schnittstellen des Experten auch für mein aktuelles Projekt taugen. Evtl. ist die Nutzung einer xsd etwas problematisch, zumindest habe ich den Verdacht, da im Gegensatz zu meinen bisherigen xml-Nutzungen einige komische Probleme auftreten. Grundsätzlich hatte ich mir vorgestellt, die xsd mit einem XML-Editor (testweise Altova) grafisch zu erstellen und davon dieSchnittstellen zu erzeugen - das wäre natürlich sehr komfortabel (und wäre mir auch die 400 Eu wert)!
Es gibt dabei allerdings (bisher) schwer einzuordnende Problemchen, wobei ich auch keine Infos finde, welche xsd.Strukturen der Experte eigentlich genau erlaubt und verkraftet...
Wenn es funktionieren würde, wäre es eine sehr komfortable Lösung: Die Struktur wird grafisch erstellt (Baumstruktur), die Schnittstellenobjekte erzeugt Delphi automatisch, eine direkte Knotenanbindung erlauben meine xmlControls (xmlEdit etc) und bestimmte Ereignisse (Ergebnisberechnungen, Spieler weiter schicken, Platzierungen berechnen usw) kann ich über Prozeduren anschieben, die die vom Experten erzeugten Knoten benutzen... Was will der Delphianer mehr?

@ Neumann:
Genau, Camtasia - kostet etwas ist aber genial! Ebenso SnagIt für ScreenShots.
Getestet hatte ich auch HyperCam und StreamCatcher (klein aber fein).

[stahli]

Auf Wunsch einer einzelnen Dame habe ich die Videos nochmal rausgekramt:
(Ich lehne aber jede Verantwortung ab! )

Schule0: http://youtu.be/yBCOFGIWM7Y
Schule1: http://youtu.be/XwaMDAMwK1M
Schule2: http://youtu.be/tZX6fXzyEE8
Schule3: http://youtu.be/K979tyzULqs
Schule4: http://youtu.be/udchH94uz3A

Statt dessen sollte man sich die Erklärung von Alister ansehen:
http://www.youtube.com/watch?v=l1Hs67jAcYE

Insgesamt sehe ich jedoch wenige Anwendungsgebiete, bei denen ich auf direkten XML-Zugriff setzen würde.

[hoika]

Hallo,

Wenn ein neues/geändertes Feld an vielen Stellen zu Anpassungen führt,
liegt doch nicht an FB, sondern am Programmierer ?

Heiko

[Hansa]

Der Spagat ist mir etwas zu gewagt. Zuerst richtige Datenbank (nicht mal nur Access ) und dann back to the roots, also Textdatei? Was soll denn besser werden, wenn auf alle DB-Features verzichtet wird ? Das könnte zwar besser werden, sofern man bei dem XML-Kram die Fehler beim DB-Design nicht macht. Richtigen Sinn macht das aber nicht wirklich.

Egal wie, es gibt da noch einen eventuell goldenen Mittelweg. Und der wäre TClientDataset. Damit lässt sich relativ leicht aus der DB lesen (quasi wie gewohnt beim Dataset), das Teil lässt sich allerdings u.a. (es gibt da einge Formate) wiederum so als XML abspeichern :

CdsDM.CDS.SaveToFile('C:\test\test.xml',dfXML); D.h., die Datenbank-Daten können per XML bearbeitet werden.