Spark vs. Halo

[Janoscharlipp]

Moin,
wir sind hier grade am grübeln, welche Komponenten wir nun nehmen sollen. Die aktuelle Lage ist sehr verwirrend, angeblich sind Spark-Komponenten toll, allerdings gibt es nicht zu allen Halo-Komponenten entsprechende Spark-Geschwister, so dass man letzten Endes mit einer Mischung aus Spark und Halo Komponenten endet, kann das gut sein?

Absurd zum Beispiel, wenn man in MXML eine Verschachtelung in der Art Panel -> Form -> FormItem -> TextInput hat. Da mischen sich die Namespaces bunt, aber irgendwie arbeitet doch noch alles zusammen, wie es scheint.

Wie haltet ihr das mit Spark?
Habt ihr schonmal von der Umstellung profitiert?
Wie geht ihr mit dieser Mischung von Spark und Halo um?

Gruß
Janosch

[Nico B.]

Da ich damit auch das Ein oder Andere Problem hatte, bin ich erstmal bei den alten geblieben.

[Janoscharlipp]

Mein Mitarbeiter hat mir grade gezeigt, wie das neue Skinning läuft, und ich muss sagen, das ist wirklich nice. Alles kann in MXML definiert werden, verschiedene Zustände (beim Button z.B.) werden direkt vom Compiler verstanden, und man kann die Elemente elegant pro Zustand konfigurieren.

[Omega Psi]

Ein Mix zwischen Spark und Halo ist vollkommen ok. Spark Komponenten erweitern den LiveCycle wie gesagt nur ums Skinning.

[mildesign]

Ja Skinning und das Layout als Composition Element ist echt nett in Flex4.

Allerdings ist die Entwicklung für Flex4 nicht gerade angenehm. FlashBuilder4 ist noch buggy und langsam, und im FlexBuilder3 bekommt der SyntaxHighlighter und die Codevervollständigung Probleme wenn man mit <fx:Script > arbeitet.

Mischen von Halo und Spark ist eigentlich ohne weiters möglich.
SkinableComponent der Spark Architektur implementiert ja IUIComponent und kann somit in Halo Container gesteckt werden.
Weiter informationen hier:
http://blog.benstucki.net/?p=56

Die ganze Api Dopplung ist allerdings anfangs etwas unübersichtlich.

z.B.
override addChild vs addElement
siehe:
http://opensource.adobe.com/wiki/dis...o+DOM+Tree+API

Das BaseLayout ist mir momentan auch noch nicht mächtig genug.
Ich steh gerade von der Aufgabe ein Hierarchisches Radialmenü zu erstellen. Dabei muss logischerweise die höhere Ebene der niedrigere Ebene Parameter für die Darstellung mitgeben. Diese Vorgabe mit der Trennung von Datenmodel und Skin und Layout zu vereinbaren ist nicht ganz einfach.
Einen Container mit einem Radialen Layout zu versehen ist dank der Spark Architektur sehr elegant umzusetzen. Sobald aber Hierarchien ins Spiel kommen wird es wieder sehr eng gekoppelt, bzw. es müssen mächtigere Interfaces definiert werden.

In der Spark Architektur steht leider noch keine Tree-Komponente zur Verfügung sonst wäre die Implementierung vermutlich recht einfach über das austauschen der Layoutklasse möglich.

Wenn jemand Ideen hat immer her damit ;o)


Zu Flex4 hat InsideRIA nette Tutorials.
http://blogs.oreilly.com/cgi-bin/mt/...4&search=flex4

[Nico B.]

Allerdings ist die Entwicklung für Flex4 nicht gerade angenehm. FlashBuilder4 ist noch buggy und langsam, und im FlexBuilder3 bekommt der SyntaxHighlighter und die Codevervollständigung Probleme wenn man mit <fx:Script > arbeitet.

Gibt es eigentlich mittlerweile konkrete Angaben zu einem Release-Termin? (Die Bugs nerven wirklich sehr, daher bin ich wieder mit Fb3 unterwegs)

[Janoscharlipp]

Danke für die Kommentare und die guten Links!

Hier Funktioniert der FlashBuilder soweit akzeptabel (schwerfällig und buggy, aber keine Abstürze).

Auf ein konkretes Problem sind wir jetzt gestoßen. Und zwar wollen wir weiterhin in unseren Skins auf Styles setzen, an zig verschiedenen Stellen die gleiche Farbe hardcoded anzugeben kann ja nicht die Lösung sein.

Der naheliegende Versuch, einfach im Skin die jeweiligen Gestaltungselemente per MXML inline-Binding mit einem getStyle-Aufruf zu konfigurieren schlägt aber leider fehl, wie es scheint sind die Style-Informationen zu der Zeit, zu der die Bindings ausgeführt werden, noch nicht verfügbar. (in creationComplete funktioniert es).

PHP-Code:

<s:Rect ...> 
    <s:fill> 
        <s:SolidColor color="{getStyle('lalala')}" /> 
    </s:fill> 
</s:Rect> 


Ich bin mir dessen bewusst, das es nicht schön ist, Bindings für sowas zu verwenden, aber der Vorteil soll ja grade sein, dass jetzt alles wunderbar kompakt und MXMLish geht, wenn ich jetzt wieder mit override updateDisplayList anfangen muss, kann ich auch gleich bei Halo bleiben.

[Omega Psi]

Zitat von mildesign

Das BaseLayout ist mir momentan auch noch nicht mächtig genug.
Ich steh gerade von der Aufgabe ein Hierarchisches Radialmenü zu erstellen. Dabei muss logischerweise die höhere Ebene der niedrigere Ebene Parameter für die Darstellung mitgeben. Diese Vorgabe mit der Trennung von Datenmodel und Skin und Layout zu vereinbaren ist nicht ganz einfach.
Einen Container mit einem Radialen Layout zu versehen ist dank der Spark Architektur sehr elegant umzusetzen. Sobald aber Hierarchien ins Spiel kommen wird es wieder sehr eng gekoppelt, bzw. es müssen mächtigere Interfaces definiert werden.]

Auch die Halo Tree Komponente ist nicht trivial implementiert. Sie arbeitet letzten Endes auch mit einer ITreeDataDescriptor um die Hierarchien abzubilden. Deine Komponente macht also mindesten genauso viel.

@Janosch: ich sehe das nicht ganz so. Seine Skins deklarativ zu bauen ist schick und so. Aber ganz ohne Code läuft es nicht, bzw kann auch unangenehme Seiteneffekte triggern, wie in deinem Beispiel. Du gehst davon aus, so hat es den Anschein, dass die Bindings und Styles zur Initialisierungszeit korrekt ziehen - das ist aber auch bei Halo nicht der Fall.

[Janoscharlipp]

Zitat von Omega Psi

... dass die Bindings und Styles zur Initialisierungszeit korrekt ziehen - das ist aber auch bei Halo nicht der Fall.

Jep, aber bei Halo käme ich auch nie auf die Idee, Bindings dafür zu verwenden, da ich entweder ohnehin Code schreiben muss (commitProperties, updateDisplayList), oder vorhandene Skins verwende, die schon auf Styles basieren.

So wie es jetzt ist, habe ich dämliche Skins, die ich mit Styles nicht auf ein erträgliches Aussehen bringen kann, kann mit den neuen Bordmitteln keine coolen (MXML) und brauchbaren (stylebaren) Skins erstellen, sondern muss wieder auf guten alten Code zurückfallen. Ich sehe keinen Vorteil.

Vielleicht übersehe ich auch einfach was, korrekt wäre eigentlich, der jeweiligen Eigenschaft mitzuteilen, dass sie sich aus dem und dem Style bedienen soll, und zwar nicht über ein normales Binding, sondern über was stylishes

[Omega Psi]

Hi Janosch, es ist in der Tat so, dass du wie gewohnt mit den Template Methoden von UIComponent/SkinnableComponent arbeiten musst, um die Styles "richtig" setzen zu können. Ich habe noch einmal nachgeschaut und so sollte es dann passen.

Aber ich glaube, du erkennst keine Vorteile, weil du das Skinning in einem anderen Kontext betrachtest. Skinning ist ja eigentlich Sache das Designers. Das heisst er malt eine Skin, wir benutzen sie nur. Das Styling einer Skin, die ja eigentlich schon durch den Designer gestyled wurde, erscheint in meinen Augen daduch erstmal als doppeltgemoppelt/redundante Arbeit.

Wenn man aber nun doch den Wunsch hengt, eine Skin zu stylen kommt man um programmatischen Aufwand nicht herum. Das heisst im Minimalfall Properties oder Styles anbieten und deren Werte dann via Bindings an die SkinParts oder Primitive weitergeben. Sauberer ist natürlich der Gang über die LiveClycle Methoden.

Trotzdem sollte man an dieser Stelle erwähnen, dass die Vorteile der Sparc Architektur in erster Linie Abspaltung von Darstellung und Komponentenlogik sind. Es war meines Erachtens nie gedacht vollständig programmatisch konfigurierbare Komponenten zu bauen - also nicht mehr oder weniger konfigurabel als es mit Halo der Fall ist. Auch hier kannst du die Skins beispielsweise mit Degrafa deklarativ erstellen und wenn du die Referenz hast auch stylen über Style-Mechanismus von Flex oder Properties.

[Janoscharlipp]

Zitat von Omega Psi

Das Styling einer Skin, die ja eigentlich schon durch den Designer gestyled wurde, erscheint in meinen Augen daduch erstmal als doppeltgemoppelt/redundante Arbeit.

Mir geht es weniger um die Möglichkeit toll per CSS alles anzupassen, sondern nicht x mal im Skin-Code irgendwelche Farben hardzucoden, damit der Designer dann irgendwann mit sowas wie "hey, ich habs mir überlegt, wir machen das doch überall bissel heller" daher kommt.

Zitat von Omega Psi

Es war meines Erachtens nie gedacht vollständig programmatisch konfigurierbare Komponenten zu bauen - also nicht mehr oder weniger konfigurabel als es mit Halo der Fall ist.

Halo Skins sind Code, und der ist nunmal so flexibel wie es eben geht.
Für mich ist und bleibt es ein Mangel an der Umsetzung von FXG, man gibt mir eine neue (wirklich nette) Syntax, unterstützt sogar States (ein neues Konzept), Styles fallen aber unter den Tisch.

Eine einfache Lösung erstmal ist einfach in einer AS-Datei Konstanten für die Farben zu definieren, und diese Datei dann in allen Skins per include reinzuholen. include an sich ist zwar nicht grade schön, aber dafür sind die Werte zentral abgelegt und das Binding wird schlank (wegen const) und funktioniert auch noch
Wenn man Assets verwenden möchte, wäre statt include vielleicht eine Klasse sinvoll, die die ganzen Konstanten enthält, dann wird das Asset nix zig mal eingebunden. (ein paar Farben fallen wohl nicht ins Gewicht)

Edit: einen anderen Ansatz bietet Flash Catalyst, aber damit komme ich auch nicht klar, wie schon im entsprechenden Thread bemängelt.

[mildesign]

Zitat von Janoscharlipp

damit der Designer dann irgendwann mit sowas wie "hey, ich habs mir überlegt, wir machen das doch überall bissel heller" daher kommt.

Dann kannst du in Zukunft sagen: "Schick mir die neuen FXG/SkinDateien Dateien wenn du sie fertig bearbeitet hast" ;o)

Roundtripping zwischen FlashBuilder und Catalyst ist ja erst mal vom Tisch aber irgendwann soll so ein Workflow ja möglich sein.

Catalyst ist echt ein schönes Spielzeug allerdings wäre es Klasse wenn Adobe eine Schnittstelle zur Entwicklung eigener Komponenten anbieten würde. Somit könnte man eventuell sogar durch MetaTags im AS Code Komponenten für Catalyst erstellen die der Designer verwenden kann.