Ich würd es gern "Frankensteins Monster" nennen - muss mal die Rechte checken.
Im Allgemeinen geht es darum, eine Möglichkeit zu haben, Web-Apps einfach und extrem flexibel zu erstellen. Das ganze sollte so trocken sein wie möglich. Wiederverwertbarkeit sollte sich direkt aus der Architektur ergeben (O.K. es gibt ein paar harmlose "guidlines").
Was schonmal geht:
Eigenschaft "fit" zur Bestimmung von Höhe und Breite von Objekten, ein Objekt wird von einem Kind-Objekt komplett ausgefüllt.
Gibt es mehre Kind-Objekte, wird der zur Verfügung stehenede Platz gleichmäßig aufgeteilt. Diese Eigenschaft wird in einem Objekt gesetzt,
nicht in einem Eltern-Objekt (wie XUL flex), obwohl dies auch gemacht werden kann (s.u. "force")
Ein riesen Sack weitere Eigenschaften für die Größen- und Positionsbestimmung von Objekten z.B relative Positionierung, ausgerichtete Positionierung etc.
Größen und Positionsangaben können berechnet werden (entspricht CSS calc())
Eltern-Objekte können Kind-Objekten Eigenschaften "aufzwingen" (force)
Docking, beliebige Verschachtelung von Objekten, die per Drag und Drop verändert werden kann.
Positionierte Objekte ("docked out"), im Kontext der kompletten Oberfläche oder im Kontext des übergeordneten positionierten Objekts.
Objekte sind selektierbar, schließbar und können hervorgehoben werden, wenn die entsprechenden Parameter bei der Klassendefinition bzw. Objektdefinition angegeben werden ("states").
Objekte wahlweise "life" oder per "Gummiband" vom Benutzer in der Größe verändert werden. Hierbei kann angegeben werden ob Seitenverhältnisse erhalten werden sollen.
Objekte können eine beliebige Anzahl von benannten Eigenschafts-Sets ("stores") besitzen die jeder Zeit "aktiviert" werden können.
Zusammenstellung beliebiger Klassen zu neuen Klassen:
Ich benutze Javascript-Prototype-Chains zusammen mit Namespaces was einige Konsequenzen hat. Die einfache "." Notation reicht nicht mehr
aus und somit hab ich "[]" eingeführt. Es sind also Klassen-Namen wie "box.form[form.input][form.submit]" möglich. Wieso und Warum und wie das Ganze funktioniert erklär ich dann in der Dokumentation...
Alias-Klassen um "heavy namespaced classchains" den Schrecken zu nehmen...
Objekte die durch prototype-chains verbunden sind teilen ebenfalls ihre Unterobjekte. Ich nenns mal "prototype-grid". Dadurch sind saubere und verschachtelte Eigenschaftsangaben realisierbar...
Die erstellte Web-App kann an beliebiger Stelle in eine Webseite eingebettet werden.
Die erstellte Web-App kann einen beliebigen Namen im windows Namensraum haben oder komplett unsichtbar sein. Kollisionen mit anderen JS-Bibliotheken sind somit vermeidbar.
In allen Browsern können die Web-App Skripte asyncron geladen werden, als Konsequenz daraus ist es möglich Klassen zu definieren, deren Superklassen noch nicht definiert sind,
diese können (und müssen) zu einem späteren Zeitpunkt definiert werden.
Hierzu:
Die erstellte Web-App kann natürlich eine Klasse sein. Des weiteren kann sie "inline" in der Webseite stehen oder geladen werden.
Und noch ein Beispiel. Dies ist ein sehr großes UI und zur Zeit meine Haupt-Test-App, also bitte nicht abschrecken lassen. Zu mehr als damit rumzuspielen taugt sie nicht. Schickeres und mehr sinnvolles kommt später. Internet-Explorer 6 und Firefox 2 werden nicht unterstützt (das tu ich mir nicht an, sorry), die Geschwindigkeiten von IE 7 und 8 sind grottig, keine Frage. Ich werde noch "Google Chrome Frame" Unterstützung einbauen. IE9, Firefox >=3.x, Safari, Chrome, Iron, Opera >=10.x sollten auch auf langsameren Rechnern gut funktionieren.
Heulsuse
Wie oben erwähnt, kann man bei meinem App-Ui diverse Zustände (states) angeben. Ausgehend von der Annahme, dass der Browser alles was er kann, schneller kann als jedes Skript das es ihm beizubringen versucht, wollte ich folgendes tun: Vorraussetzungen:
Ich möchte ein Icon haben, das mir den Docked-In / Docked-Out Zustand anzeigt.
Ich setze in dem HTML-DIV Element, das die Representation meines Objekts auf der HTML-Seite darstellt, die Style-Klasse "dockedIn" oder "dockedOut". Irgendwo in der DOM-Hierarchie "innerhalb" der DOM-Representation befindet sich mein IMG-Element. In der Hoffnung das die CSS Implementierung schlau genug ist, packe ich folgende CSS Selektoren in mein Stylesheet:
Und? Es funktioniert nicht, sobald ich meine Objekte weiter verschachtele.
Also hab ich mal nachgeschaut und folgendes entdeckt: Test 1 Test 2 Test 3
Da dieses "Verhalten" alle Browser zeigen, bin ich also gezwungen die Style-Klassen "dockedIn" und "dockedOut" in mein Icon-IMG zu schreiben und die Selektoren umzuändern.
Nachteile: ich muss in meiner Objektdefinition angeben in welche Elemente die Styleklassen eingetragen werden sollen, und mein Skript kommt nicht mit "nur einmal" setzen aus. Schön daran ist natürlich auch, dass ich bei jedem Setzen mit einem Reflow rechnen kann. Was das für die Geschwindigkeit bedeutet, dürfte klar sein.