News-Foren

• Startseite
• > heise Developer News-Foren
• > Eclipse 4 ist eine Meile weiter
• > Re: Sieht nach Murks aus...

• Vorheriger
• Nächster
• Thread
• Beantworten
• E-Mail
• Neues Thema

Re: Sieht nach Murks aus...

Olaf Klischat schrieb am 25. November 2009 21:13

> Dein
> <Shell irgendwas="layout"> entspräche <Label Text="First Name:"/>,
> d.h. das wäre eine Unterkomponente der äußeren Shell, und würde in
> sowas wie Shell comp = new Shell(); comp.setIrgendwas("layout"); 
> outerComponent.addComponent(comp); umgesetzt werden.

Wenn man die vorhandene Parselogik gleich behält, aber das ist doch
kein Argument für irgendwas. Mir ging es doch gerade darum, dass man
das von Anfang in saubereres XML hätte packen können, aber nicht
wollte.

> Klar, man hätte
> in Regel (2.) als Syntax sowas wie <property
> name="bla">[Objektdefinition]</> [Objektdefinition]</property>
> verwenden können, aber wo soll da der große Unterschied sein?

Shell.layout ist eine in einem Tagnamen abgebildete Hierarchie und
widerspricht der bei Button angewandten Logik, bei der jedes Attribut
auf einen Setter gemapped wird. Shell.layout wird auf Shell.setLayout
gemünzt, ebenso wie Button Text="xy" auf Button.setText. Wo soll hier
der Vorteil an unterschiedlicher Syntax liegen? Wenn man schon eine
Sonderlocke für Shell strickt, hätte man auch einfach nur layout
nehmen können, wozu bedarf es da Shell.layout? Shell.layout in
Shell.setLayout zu wandeln wäre genauso eindeutig, wie einfach nur
layout in setLayout des Elterntags zu wandeln.

> Ja, das ist gut. Die Idee hat sich seit Jahrzehnten in verschiedenen
> äußerst erfolgreichen und teilweise auch wirklich Neuland
> erschließenden Toolkits bewährt. Um das zu verstehen, solltest du am
> besten eines davon ausprobieren. Seitenlang darüber zu reden ist eher
> ineffektiv.

Ich gehöre eher zu denen, die erstmal verstehen wollen, worin denn
die Vorteile solcher Technologien liegen, bevor ich jeden Krempel,
der auf den Markt kommt, ausprobiere. Aber ich habe auch nicht
unendlich Zeit. ;-) Mir leuchtet der Vorteil einer strikten
Serialisierung von Objekten durch ein neues Toolkit, das nichts
anderes tun soll, als zu serialisieren, ohne logische Bedeutungen
abzubilden, auch nicht Recht ein. Warum nimmt man dann nicht gleich
reine XML-Serialisierung der Objekte? Darum allein kann es also nicht
gegangen sein, sondern schon darum, den Benutzern die einfache
Erstellung von Oberflächen durch Fokussierung auf die wesentlichen
Aspekte zu ermöglichen und solche Dinge. Wenn man aber genau das zum
Ziel hat, kann man auch gleich vorsehen, dass der Benutzer die GUI
nicht nur optisch, sondern auch logisch beschreiben kann, in dem
logische Abhängigkeiten zwischen Elementen ebenfalls modelliert
werden können.

> HTML ist was völlig anderes. Im Gegensatz zu einem Webbrowser weiß
> der XWT-Parser nicht, dass er GUIs zusammenbaut, und enthält deswegen
> auch keine Layout-Algorithmen oder sonst irgendwas derartiges.

Wenn ich mir den Namen des Toolkit ansehe, ist sien Fokus doch
eigentlich klar: Eclipse XML Windowing Toolkit Das XML-Markup soll
eindeutig eine GUI beschreiben, aus meiner Sicht ist der Vergleich
mit HTML, welches ja auch nur logische Zusammenhänge von Inhalten
auszeichnen soll, also nicht soo abwegig. Auch GUI-Elemente haben
logische Zusammenhänge und wenn ich mich schon hinsetze, eine neues
Toolkit für GUIs zu entwerfen, warum lasse ich solche Aspekte dann
raus? Dafür brauchts auch gar keine Layoutalgorithmen, es geht nur
darum, dass das Toolkit den Layoutalgorithmen höherer Ebenen diese
Informationen des Benutzers aber zur Verfügung stellen könnte, was
jetzt offensichtlich im Gegensatz zu HTML nicht vorgesehen ist. HTML
wird auch von zig verschiedenen Rendering Engines umgesetzt, manche
nutzen bestimmte Informationen nicht, andere schon. Rauslassen sollte
mans ie aber nur, wenn sie nicht sinnvoll sind und/oder die Sache
extrem verkomplizieren.

> Das
> steckt alles im drunterliegenden Toolkit; XWT ist bloß eine
> Markup-Sprache, um Objektgraphen von Instanzen der Toolkitklassen
> serialisieren/deserialisieren und hinschreiben zu können. Das ist
> Absicht, und es ist sinnvoll.

Dann habe ich den Ansatz des Toolkit, dem Endanwender einfachere
GUI-Erstellung zu ermöglichen, wohl gründlich missverstanden. Bleibt
die Frage, was genau ein neues Toolkit dann bringen soll, wenn es nur
die ohnehin vorhandenen XML-Serialisierungsmöglichkeiten für Objekte
bietet? Wo liegen dann die Stärken und Einsatzgebiete, wenn es
offensichtlich nicht der Endanwender ist?

• Nutzungsbedingungen
• Vorheriger
• Nächster
• Thread
• Beantworten
• E-Mail
• Neues Thema

• In Thread-Darstellung zeigen
• In Eingangsreihenfolge zeigen