qtforum.de

Hi allerseits!

Ich möchte es schaffen, bestehende Widget-Object-Hirarchien (also z.B. ein Fenster mit deren Elementen) mit Hilfe von DOM in einer XML Datei abzulegen. Natürlich ist der Rückweg ebensowichtig - also eine GUI oder zumindest teile davon aus einer XML Datein laden und die Objekte zu laufzeit erzeugen. Das ganze will ich mit Qt 4 realisieren, das heißt mit der Qt DOM Implementierung und Qt Widgets.

So weit ich weiß sind die Qt Objekte nicht dafür ausgelegt als XML abgelegt und daraus konstruiert zu werden. Darum frage ich mich, wie man sowas am effizientesten angeht.

Das größte Problem scheint mir zu sein, daß die DOM-Objekthirarchie und die Qt-Widget-Hirarchie zwei völlig unterschiedliche Konstrukte sind. Das heißt es gibt eine Objekt-Hirarchie mit Widgets (Fenster, Buttons usw.) die vom Framework verwaltet wird und eine Hirarchie von DOM-Objekten die getrennt erzeugt und verwaltet wird.

Ich müßte also vor dem Speichern (oder auch während der gesamten Programmlaufzeit) die Widget-hirarchie auf die DOM-hirarchie umständlich abbilden.
Beim laden dagegen müßte ich aus der DOM-Hirarchie ebenso umständlich widget-Objekte erzeugen und mit den geladenen Attributen ausstatten.

Im Augenblick scheint mir eine Lösung mit DOM wegen dieser getrennten Daten-Hirarchien in der Praxis fast so komliziert wie die Verwendung eines 'primitiven' SAX Parsers und eines handgeschriebenen XML-generators. Es muß doch irgendwie möglich sein, aus der objektorientierung und der Mächtigkeit DOM's zu profitieren?

Hat jemand Ideen, oder sogar Erfahrung damit, wie man sowas elegant lösen kann?

Entweder ich habe Dein Posting völlig missverstanden, oder Du möchtest QT's .ui Dateien neu erfinden?! Oder vielleicht doch nicht. Geht es um GUI's, die Du zur Laufzeit verändern möchtest?

Dann schau Dir mal KXMLGui in den KDE-Bibliotheken an. Mir ist das allerdings zu hoch, ich bin froh, es nur anzuwenden. Ich muss nicht wissen, wie es im Detail funktioniert

XUL verfolgt wohl den gleichen Ansatz, damit kenne ich mich aber noch weniger aus.

taki hat geschrieben:Entweder ich habe Dein Posting völlig missverstanden, oder Du möchtest QT's .ui Dateien neu erfinden?! Oder vielleicht doch nicht. Geht es um GUI's, die Du zur Laufzeit verändern möchtest?

Nein, nein. Die .ui Dateien werden compiliert. Wie du schon bemerkst, soll das ganze zur Laufzeit möglich sein.

taki hat geschrieben:Dann schau Dir mal KXMLGui in den KDE-Bibliotheken an. Mir ist das allerdings zu hoch, ich bin froh, es nur anzuwenden. Ich muss nicht wissen, wie es im Detail funktioniert

Danke für den Hinweis. Reinschauen werde ich mal. Ob ich allerding etwas vorgefertigtes ohne Hilfe verstehen werde ist auch noch nicht gesagt

taki hat geschrieben:XUL verfolgt wohl den gleichen Ansatz, damit kenne ich mich aber noch weniger aus.

Ja, das scheint auch in die Richtung zu gehen, allerdings benötige ich etwas, das auf Qt spezialisiert ist.

Ich denke auch nicht, daß ich eine fertige Lösung dazu finden werde. Ich hoffe nur daß ich einen möglichst eleganten Lösungsweg finde, schließlich kann/will ich die Qt Klassen nicht verändern, das macht einiges schwieriger.

Der einzige Weg, der mir im Augenblick einfällt, ist, sämtliche GUI-Klassen durch Vererbung zu kapseln und mir praktisch eine neues Interface zu schaffen, das alle Veränderungen an den Objekten an einen DOM Baum überträgt. Das ist aber saumäßig viel Arbeit, insbesonders weil sich diese Lösung auf viele Klassen verteilt.

Eine andere Möglichkeit wäre, einfach eine zentrale Funktion zum Speichern der XML Dateien zu schreiben, die in der Lage ist, die Qt Hirarchie zu verstehen, abzuschreiten und alle wichtigen Objektattribute im XML Format zu speichern. Zudem eine Funktion zum Laden (per SAX) die dann entsprechend der XML Datei Objekte konstruiert und zu einer Qt Hirarchie zusammenfügt. Das scheint mir einfacher als die erste Lösung, von den Fähigkeiten DOMs könnte ich aber kaum profitieren, allenfalls um mir die Abreit zu sparen, XML selber zu erzeugen (was aber das geringste Problem sein dürfte).

Was mir bisserl dazu fehlt, iss der praktische Nutzen der sache ...

So voll dynamisch macht nur sinn, wenn sich deine QT-WidgetHirarchie auch voll dynamisch per usereingabe erstellen liese ....
Aber wozu sollte der usser sich childfenster und menues und buttons zusammenclicken ... ?
Was soll in den Widgets spaeter fuer daten angezeigt werden ?

Naja, bei ner Makro / script schnittstelle koennt ichs mir vielleicht vorstellen ...wo dem user bei nem programm die moeglichkeit gegeben wird, da zur laufzeit interaktion zu mit gui elementen zu bieten, die er selbst entworfen hat ....

Also prinzipiell wirst zu erzeugen ne etwas aufwendigerere Objectfabrik brauchen .... da die widgets untereinander bezihungen haben ....

Uberall ne zwischenklasse in die hirarchie schieben, wo du die serialisierung implementierst wuerd ich vielleicht nicht machen, lieber in ne helper funktion auslagern, welche selber hirarisch sein koennten ....

Nen komoplett voll generischen ansatzt wirst da kaum finden, was von welchen widget gespeichert werden muss, musst selber irgendwo manuell hinterlegen ....
Ganz kompliziert wird es sicher, wenn der user selber abgeleitete klassen auch serializieren koennen soll

Wie gesagt schau dir das Besuchermuster und Objectfabriken an ... das sollte dir am meisten stoff zum nachdenken liefern ...

Ciao ..

RHBaum hat geschrieben:Was mir bisserl dazu fehlt, iss der praktische Nutzen der sache ...

So voll dynamisch macht nur sinn, wenn sich deine QT-WidgetHirarchie auch voll dynamisch per usereingabe erstellen liese ....

Und genau das ist auch der Sinn der Sache. Ob letztendlich wirklich Child-Fenster notwendig sind, sei mal dahin. Auf jeden Fall auf der ebene eines Fenster, muss das auf jeden Fall möglich sein.

RHBaum hat geschrieben:Was soll in den Widgets spaeter fuer daten angezeigt werden ?

Importierte informationen einer Simulation. Das ist etwas komliziert zu erklären, aber glaub mir, es macht durchaus Sinn.

RHBaum hat geschrieben:Naja, bei ner Makro / script schnittstelle koennt ichs mir vielleicht vorstellen ...wo dem user bei nem programm die moeglichkeit gegeben wird, da zur laufzeit interaktion zu mit gui elementen zu bieten, die er selbst entworfen hat ....

Das kommt später noch dazu...

RHBaum hat geschrieben:Also prinzipiell wirst zu erzeugen ne etwas aufwendigerere Objectfabrik brauchen .... da die widgets untereinander bezihungen haben ....

Objectfabrik? Sollte mir der Begriff etwas sagen?

RHBaum hat geschrieben:Uberall ne zwischenklasse in die hirarchie schieben, wo du die serialisierung implementierst wuerd ich vielleicht nicht machen, lieber in ne helper funktion auslagern, welche selber hirarisch sein koennten ....

Nen komoplett voll generischen ansatzt wirst da kaum finden, was von welchen widget gespeichert werden muss, musst selber irgendwo manuell hinterlegen ....

Sehe ich alles auch so. Da die Widgets vom Benutzer verändert werden sollen (und dementsprechend zusätzliche Attribute brauchen (z.B. woher die angezeigt Information kommen soll) werde ich vermutlich sowieso jedes Widget wrappen (sprich ableiten) müssen.

Trotzdem scheint mir im Augenblick am einfachsten zu sein, tatsächlich die bestehende Qt Hirarchie abzulaufen, die enthaltenen Objekte dynamisch in meine eigenen Klassen zu casten und dann die zugehörigen Attribute zu speichern. Hier wäre eventuell noch die Frage: Lohnt sich DOM wenn ich es nur zum Erzeugen von XML benutze, ohne seine Hirarchie weiter zu verwenden?.

Beim Laden wäre dann auch Handarbeit angesagt, die Objecte zu erzeugen und in die Qt Hirarchie einzufügen. Aber auch hier bin ich mir nicht ganz schlüssig ob mir SAX oder DOM bessere Dienste leisten wird.

Ich habe weder SAX noch DOM für Projekte verwendet. Hast du ein Gefühl dafür, welches hier unterm Strich besser geeignet ist (zum Laden bzw. zum Speichern)?

RHBaum hat geschrieben:Ganz kompliziert wird es sicher, wenn der user selber abgeleitete klassen auch serializieren koennen soll

Uff, nein, Das lassen wir mal

RHBaum hat geschrieben:Wie gesagt schau dir das Besuchermuster und Objectfabriken an ... das sollte dir am meisten stoff zum nachdenken liefern ...

Besuchermuster? Objectfabriken? Irgendwie stehe ich auf dem Schlauch

such mal ueber google nach design pattern

Da sind so standardisierte vorgehensweissen zu immer wieder kehrenden problemen beschrieben ....
In Buechern dazu wird sich grundlegend mit den Techniken zu befasst, also mit vor und nachteilen bestimmter implementierungen / muster ....

nen Wrapper zum beispiel iss auch nen sehr gern benutztes pattern

Besuchermuster beispielsweisse isss ganz ganz grob gesagt ne Technik, wo eine iterierbare hirachie ne funktion bekommt, wo sich eben mal nen besucher vorbeischaut ... der besucher iss sowas wie'n zentraler manager ...
Fuer unterschiedliche taetigkeiten, kann es eben dann unterschiedliche besucher geben ... etc ...
Also was, was du beim erzeugen deines XML sicher gut gebrauchen koenntest

Objectfabriken (manchmal auch virtuelle konstruktoren genannt )
Sind techniken, wo man anhand von verschiedenen eingangsparametern unterschiedliche klassen (aber gleicher Basis) erstellt, und von diesen klassen nur noch (die allgemeingueltige) schnittstelle nach aussen gibt ... der anwender also meist gar nich wissen muss, was genau fuern object er da bekommen hat ...
Also was, was fuer das Erzeugen deiner Widgets ausm XML nutzen koenntest ...

werde ich vermutlich sowieso jedes Widget wrappen (sprich ableiten) müssen.

Wrappen != ableiten !
ob du von QWidget ableiten musst oder gar solltest, mag ich an der stelle sogar anzweifeln ... ableiten iss nich immer das mittel der Wahl. Der nachteil des Ableitens sind die extrem starken abhaengigkeiten die man damit erzeugt ...

Ich habe weder SAX noch DOM für Projekte verwendet. Hast du ein Gefühl dafür, welches hier unterm Strich besser geeignet ist (zum Laden bzw. zum Speichern)?

Dom verwendet intern sicher auch SAX

also isst es eher ne frage, wie du das parsen gestalten willst .... beim DOM liegt dein ergebniss im Speicher in ner form, die du nicht beeinflussen kannst (naja nur mit der XML struktur selber) ... beim SAX hingegen baust deine eigene struktur auf, die auch gleich die als ergebniss gewuenschte Struktur sein kann ....

Bei DOM sparst dir eigentlich nur das implementieren der Event schnittstelle, nimmst dafuer aber mehr speicherverbrauch und iteration in ner von dir im parser nicht beeinflussbaren Struktur in kauf ....

DOM nimmt ma eher bei wenig daten, die man eh allgemeingueltig zwischenspeichern muss ... gleich im speicher bearbeiten ... und dann wieder ablegen ...
Bietet sich also an, wenn du statt eigenstaendigen lese und schreiboperationen ne Synchronisation zwischen deiner objectStructur und dom bauen willst. Wenndas fuer dich wesentlich einfacher ist ... dann DOM.

SAX ist immer effizienter, aber meistens auch aufwendiger in der programmierung ...
bei SAX ist lese und schreibvorgang immer getrennt ... SAX kann nicht schreiben ... also musst das selber soweiso unabhaengig implementieren ...

DOM kann schreiben, erzeugt aber je nach Impl nich wirklich "schoenes" XML (wenns wen drauf ankommt )

Ich verwend immer nur SAX, aber daran solltest dich ned orientieren ...

Ciao ...

RHBaum hat geschrieben:Da sind so standardisierte vorgehensweissen zu immer wieder kehrenden problemen beschrieben ....
In Buechern dazu wird sich grundlegend mit den Techniken zu befasst, also mit vor und nachteilen bestimmter implementierungen / muster ....

Was ein design pattern ist, war mir klar. Ich muss aber gestehen, daß ich mich nie speziell damit auseinandergesetzt habe.

RHBaum hat geschrieben:Besuchermuster beispielsweisse isss ganz ganz grob gesagt ne Technik, wo eine iterierbare hirachie ne funktion bekommt, wo sich eben mal nen besucher vorbeischaut ... der besucher iss sowas wie'n zentraler manager ...

Fuer unterschiedliche taetigkeiten, kann es eben dann unterschiedliche besucher geben ... etc ...
Also was, was du beim erzeugen deines XML sicher gut gebrauchen koenntest

Im Moment schwer vorzustellen, aber ich werds mir ansehen. Danke!

RHBaum hat geschrieben:Objectfabriken (manchmal auch virtuelle konstruktoren genannt ) Sind techniken, wo man anhand von verschiedenen eingangsparametern unterschiedliche klassen (aber gleicher Basis) erstellt, und von diesen klassen nur noch (die allgemeingueltige) schnittstelle nach aussen gibt ... der anwender also meist gar nich wissen muss, was genau fuern object er da bekommen hat ...
Also was, was fuer das Erzeugen deiner Widgets ausm XML nutzen koenntest ...

Ja, das klingt vernünftig. Auch wenn ich mir im Augenblick nicht sicher bin, wie das in Verbindung mit XML aussehen wird, wie also z.B. die XML Parameter am besten an die Objectfactory übergeben werden.

RHBaum hat geschrieben:Wrappen != ableiten !
ob du von QWidget ableiten musst oder gar solltest, mag ich an der stelle sogar anzweifeln ... ableiten iss nich immer das mittel der Wahl. Der nachteil des Ableitens sind die extrem starken abhaengigkeiten die man damit erzeugt ...

Ableiten ist aber *eine* der möglichen Methoden, einen Wrapper zu erzeugen.

Wenn ich die bestehenden Widgets generell um bestimmte Attribute erweitern möchte (z.B. die Datenquelle) dann bleiben mir nicht viele Alternativen. Immerhin kann in den Widgets keine frei definierte referenz von mir mitgeben.
Entweder jedes Widget ableiten oder eventuell ein entsprechendes Template, das ich für jede Widgetklasse instanzieren kann.
Eine Ableitung hätte IMHO aber einen riesen Vorteil: Ich könnte aus einem Widget-zeiger durch einen dynamischen cast auf das abgeleitete Objekt zurückschliessen. Das wäre enorm nützlich. Wenn der Benutzer z.b. ein Widget auswählt, um dieses zu verändern, könnte ich sofort auf das zugehörige Verwaltungsobjekt casten.

Wie würdest du denn bestehende Objekte verschiedener Klassen-Typen mit Verwaltungobjekten verknüpfen?

RHBaum hat geschrieben:DOM nimmt ma eher bei wenig daten, die man eh allgemeingueltig zwischenspeichern muss ... gleich im speicher bearbeiten ... und dann wieder ablegen ...
Bietet sich also an, wenn du statt eigenstaendigen lese und schreiboperationen ne Synchronisation zwischen deiner objectStructur und dom bauen willst. Wenndas fuer dich wesentlich einfacher ist ... dann DOM.

SAX ist immer effizienter, aber meistens auch aufwendiger in der programmierung ...
bei SAX ist lese und schreibvorgang immer getrennt ... SAX kann nicht schreiben ... also musst das selber soweiso unabhaengig implementieren

Letzteres wäre für mich ein gewichtiges Argument für DOM. Ich würde nur ungern eigene Schreibroutinen basteln. Bis das mal alles passt %-/
Wäre für mich ein hauptargument DOM zu verwenden, auch wenn es irgendwie mit Kanonen auf Spatzen geschossen ist.

Die Idee mit der ständigen Synchronisation zwischen der Widget-Hirarchie und der XML Hirarchie gefällt mir immer weniger. Das müßte mich aber nicht hindern DOM zu verwenden. Ich könnte den DOM Tree ja auch nur temporär aufbauen, zum Speichern und Laden. Würde sich vermutlich immernoch lohnen.

RHBaum hat geschrieben:DOM kann schreiben, erzeugt aber je nach Impl nich wirklich "schoenes" XML (wenns wen drauf ankommt )

Hups? Wie ist das gemeint. Wie sieht den "unschönes" XML aus?!

RHBaum hat geschrieben:Ich verwend immer nur SAX, aber daran solltest dich ned orientieren ...

Naja, vielleicht schon

schoenes XML:

Code: Alles auswählen

<Messages>
    <Message ID=100>
        <Name>Message WasWeisIch</Name>
    </Message>
</Messages>

Unschoenes XML :

Code: Alles auswählen

<Messages><Message ID=100><Name>Message WasWeisIch</Name></Message></Messages>

Zur Vererbung noch:

In irgend nem wichtigen Buch (ich hab viele wichtige C++ Buecher, aber verwechsel die titel immer

) steht:

vererbe nie um wiederzuverwenden, vererbe nur, um wiederverwendet zu werden !

Naeher beleuchtet wird das dann noch und am ende kommt man zum schluss, das es bei C++ nur 2 wirklich driftige gruende gibt, um zu vererben :

- wenn du Zugriff auf protected members einer klasse brauchst, diese klasse aber nich deiner verwaltung unterliegt (sonst gaebs die friend methode)
- wenn deine klasse sich als andere Ausgeben soll (hier faellt eigentlich alles rein).

Also wenn du X von Y public ableitest, und X niemals ueber nen Y zeiger oder Y referenz oder ner noch generischeren Basis drauf zugreifst, war deine Vererbung eigentlich der falsche weg ....

Ich könnte aus einem Widget-zeiger durch einen dynamischen cast auf das abgeleitete Objekt zurückschliessen.

dynamic cast braucht RTTI, RTTI ist verrufen ... und teilweise nicht unproblematisch ... (wenn du statische libs hasst und von klassen darin ableitest, muess die lib auch mit RTTI infos ubersetzt sein )
zu viele dynamic casts, bzw dynamic casts allgemein sind eigentlich nen zeichen auf schlechtes design ....

bei wrapper nimm lieber aggregation (members)
wiederverwendung von code -> templates / aggregation
Hirarchien flach halten ... in bestehende Hirarchien zur eigenen Abstraktion noch ne Schicht durch ableitung hineinziehen -> meist boese Sackgasse ....

Gute buecher zum Thema :
Modern c++
execptional C++
more exceptional c++
design pattern
Die C++ Programmiersprache (Bjarne Stroustrup)

Man kann mit C++ alles realisieren ... das kann auch fast jeder ... nur ob der code wiederverwendbar iss, und von anderen gewartet werden kann, und man sich nach ner pause selbst noch reinfindet ... iss ne komplett andere Frage

Obig genannte Buecher helfen da immens !

Ciao ...

RHBaum hat geschrieben:
Ich könnte aus einem Widget-zeiger durch einen dynamischen cast auf das abgeleitete Objekt zurückschliessen.
dynamic cast braucht RTTI, RTTI ist verrufen ... und teilweise nicht unproblematisch ... (wenn du statische libs hasst und von klassen darin ableitest, muess die lib auch mit RTTI infos ubersetzt sein )
zu viele dynamic casts, bzw dynamic casts allgemein sind eigentlich nen zeichen auf schlechtes design ....

bei wrapper nimm lieber aggregation (members)
wiederverwendung von code -> templates / aggregation
Hirarchien flach halten ... in bestehende Hirarchien zur eigenen Abstraktion noch ne Schicht durch ableitung hineinziehen -> meist boese Sackgasse ....

Naja, die Alternative zu Ableitungen und dynamischen casts wäre in meinem Fall, die Qt Widgets über einen pointer-member in der Verwaltungsklasse zu referenzieren (pfad vom verwaltungsobject zum widget) und einen zweiten, hirarchischen Baum für die Verwaltungsobjekte aufzubauen, den ich durchsuchen kann, wenn ich zu einem Widget das zugehörige Verwaltungsobjekt benötige (pfad vom widget zum verwaltungsobject). Das ist recht aufwändig und eine andere lösung kenne ich nicht um zwischen beiden Objekttypen eine bidirektionale verbindung herzustellen.

Im Augenblick gefällt mir die aggregative Lösung keinesfalls besser als die vererbende (auch wenn RTTI etwas verrufen sein mag). Eine völlig redundante Objekthirarchie ist jedenfalls auch nicht so schön. oder was meinst du?

schoen und schoen sind eben relativ ....

mit vererbung bindet man sich sehr stark ...
auf der anderen seite, kann man das vererbte object genau wie ein Basisobject behandeln, und sogar in der vorhandenen Umgebung integrieren ...
Aber bist du sicher dass es genau das ist was du brauchst ?

Das ist recht aufwändig

das sollte immer gut in erwaegung mit einbezogen werden ... ein gutes design iss goldwert, und rechtfertigt fast immer den mehraufwand.

Das sehe ich aber nich so als problem an, ich schaetze vielmehr, dass du mit deiner Vererbungshirarchie schnell ins ueferlose geraetst.
Alle klassen ableiten, fuer die grundfunktionalitaet fuer deine XML-Serialize kommt vielleicht noch ne 2te generelle Basisklasse hinzu -> mehrfachvererbung . Die beziehungen zwischen den einzelnen Klassen sind auch nich unproblematisch, weil die eine Klasse zumeist Parent fuer die andere klasse ist ... also auch nich ohne abhaengigkeit ....
iss nich ganz unproblematisch .

Ich wuerd, so ausm Bauch raus, zu ner Parallelen Hirarchie tendieren ...
Wobei natuerlich Aufwand und nutzen nich ausm auge gelassen werden sollten. Vielleicht schiess ich auch mit kanonen auf spatzen, wenn z.B. sich deine zugelassen QWidget klassen in grenzen halten ... etc ...
und ne spaetere Erweiterung Adaption etc ... gar und nie nimmer nich ueberhaupt zur debatte steht ....

Ciao ...

RHBaum hat geschrieben:mit vererbung bindet man sich sehr stark ...
auf der anderen seite, kann man das vererbte object genau wie ein Basisobject behandeln, und sogar in der vorhandenen Umgebung integrieren ...
Aber bist du sicher dass es genau das ist was du brauchst ?

Das ist recht aufwändig
Das sehe ich aber nich so als problem an, ich schaetze vielmehr, dass du mit deiner Vererbungshirarchie schnell ins ueferlose geraetst.
Alle klassen ableiten, fuer die grundfunktionalitaet fuer deine XML-Serialize kommt vielleicht noch ne 2te generelle Basisklasse hinzu -> mehrfachvererbung.

Ja, Mehrfachvererbung (zumindest zwei basisklassen) würde es geben.

RHBaum hat geschrieben:Ich wuerd, so ausm Bauch raus, zu ner Parallelen Hirarchie tendieren ...
Wobei natuerlich Aufwand und nutzen nich ausm auge gelassen werden sollten. Vielleicht schiess ich auch mit kanonen auf spatzen, wenn z.B. sich deine zugelassen QWidget klassen in grenzen halten ... etc ...
und ne spaetere Erweiterung Adaption etc ... gar und nie nimmer nich ueberhaupt zur debatte steht ....

Die Anzahl zugelassener Klassen wäre schon begrenzt. Änderungen sind im Nachhinein natürlich nie auszuschliessen.

qtforum.de

Abbildung von GUI Qt-Objektstrukturen mit DOM

Abbildung von GUI Qt-Objektstrukturen mit DOM

.ui neu erfinden?

Re: .ui neu erfinden?