Flex 4 spark list scrollbar skin?

[Silver_Surfer]

Moin Freunde,

seit gestern versuche ich den vscroller einer spark list zu skinnen, leider ohne erfolg.

meine css sieht aus wie folgt:

PHP-Code:

s|List s|VScrollBar
{
thumb-skin: Embed(source="skins/vscroller_thumb.png",scaleGridLeft="5",scaleGridTop="5",scaleGridRight="9",scaleGridBottom="15");    
} 


es tut sich einfach nichts. was kann ich noch versuchen?
danke euch.

[Nico B.]

Muss es per CSS sein? Sonst würde ich evtl. einfach mal ne CustomSkin machen.

[Silver_Surfer]

was meinst du mit customskin? bzw habe ich versucht: skin-class: "skins.Scroller";

aber da hagelt es fehler.

.lstStatus.ListSkin98.scroller.ScrollerSkin101.ver ticalScrollBar kann nicht gefunden werden.

[Nico B.]

Ich meine eine eigene SkinKlasse?

Ich gehe im Moment so vor, dass ich meine Komponente in catalyst skinne und mir den Code dann rausziehe (aber voher noch unnötige Sachen lösche!). Funktioniert super gut, ist kaum Fehleranfällig und Animationen sind (dank Catalyst) auch mit drin. Ohne den ganzen Schreibaufwand den man damit sonst immer hat.

Mit css mache ich eigentlich gar nix, aber mal sehen, ob sich das in Zukunft ändert. Die Diskussion hatte ich mit Omega schon. (Ich sehe den Vorteil noch nicht ganz.)


Edit: Ich meinte sowas:

Ist der Skin für ein Thumb einer ScrollBar.

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:s="library://ns.adobe.com/flex/spark"
        xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:fc="http://ns.adobe.com/flashcatalyst/2009"
        fc:resizable="false">
    <fx:Metadata>[HostComponent("spark.components.Button")]</fx:Metadata>
    <s:states>
        <s:State name="up"/>
        <s:State name="over"/>
        <s:State name="down"/>
        <s:State name="disabled"/>
    </s:states>
    <s:Rect x="0" y="0" width="30" height="60" radiusX="5">
        <s:fill>
            <s:SolidColor color="#FF9300"/>
        </s:fill>
    </s:Rect>
</s:Skin> 

Oder rede ich gerade an Deinem Problem vorbei?

[Omega Psi]

@silversurfer: wo hast du den CSS Code her?
@nico: recht guter Workflow, wenn du die Skins aber zum Beispiel via CSS setzt und nicht im Quellcode, bist du flexibler, kannst leichter iterativ arbeiten und wenn du zudem noch mit styles arbeites (Implementierung der Logik in der Skin), hast du gleich parametrisierbare Komponenten. Ich finde das super.

[Nico B.]

Was genau meinst Du mit "Skins im Quellcode setzen" ?

Nur den Verweis auf die Klasse meinst Du mit Sicherheit nicht, oder? Bzw. Ist es wirklich gut die Logik in die Skins einzubauen?

Ich arbeite mit Presentation-Models und wollte in Zukunft mal versuchen nicht nur die View darüber zu handhaben sondern eben auch die Skins.

Oder macht die Trennung "view" (Skin) und Logik keinen Sinn?

<?xml version="1.0" encoding="utf-8"?>
<s:Skin xmlns:s="library://ns.adobe.com/flex/spark"
        xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:fc="http://ns.adobe.com/flashcatalyst/2009"
        xmlns:d="http://ns.adobe.com/fxg/2008/dt"
        fc:resizable="false">
    <fx:Metadata>[HostComponent("spark.components.List")]</fx:Metadata>
    <s:states>
        <s:State name="normal"/>
        <s:State name="disabled"/>
    </s:states>
    <s:VScrollBar x="404" y="0" fixedThumbSize="true" 
                  skinClass="irgendein.geheimer.pfad.TwitterResultScrollbar"
                   
                  viewport="{dataGroup}"
                  
                  snapInterval.normal="5" stepSize.normal="1"/>
 
// ..... 
 

So habe ich es in einem aktuellen Projekt gelöst... Das würdest Du dann per CSS zuweisen?

Ironie: Immer wenn etwas für mich gerade Sinn macht & ich es gut nutzen kann, kommst Du wieder mit was anderem um die Ecke, was in 90% der Fälle "cooler" ist... Was soll das?

[Omega Psi]

Logik != Logik. Business Logik gehört in keine View Klasse, Verhalten hingegen schon. Das muss man nun mal programmieren.

Die skinClass für den Scrollbar kannst du via CSS setzen. Das würde ich so machen. So bist du für Änderungen in der Zukunft offener. Ganz zu schweigen vom Aspekt der Wiederverwendbarkeit.

[Nico B.]

Hm - ok. Aber für mein Verständnis: Außer der Schreibarbeit (dass ich es dann in der CSS ändern kann und nicht erst im Code die Zeile suchen muss, pfade abändern etc...) ändert sich nix oder?


Was zählt für Dich zum Verhalten? Im Moment injecte ich das PresentationModel in die View und lasse alles darüber laufen. Auch Listener von Komponenten die bsp. nur Funktionen aufrufen, die sich im PresentationModel befinden.

Heißt, alles was bei mir in der View an "code" steht ist auf "model.irgendwas" begrentzt.

Nicht gut?

[Omega Psi]

Thema CSS: ja
Thema PM: Das kann man so machen und ist nicht falsch. So lange du eine saubere Trennung von View und Model hast.

[Nico B.]

Allet kloar. Das hoffe/denke ich doch, sauberer geht's ja eigentlich nicht mehr.^^

@ Silversurfer: Sorry, dass ich Dein Thema "vergewaltigt" habe. Poste mal, ob Dir das obrige helfen konnte.

[Omega Psi]

Doch, das geht noch sauberer

[Nico B.]

Wie denn? Jetzt bin ich gespannt

[Omega Psi]

Ohne zu weit auszuholen: wenn man Model (der Applikationszustand) und die Services trennt, dann hat man in der Regel mehr an Struktur gewonnen. Ich arbeite beispielsweise gerne mit spezialisierten Mediatoren, die für einen View Typ implementiert sind. Da ich auf Interfaces typisiere und nicht nach Klassen, kann ich so sehr flexibel arbeiten, Funktionalitäten austauschen oder Stub/Mocks verwenden. In deiner Implementierung ist alles noch etwas härter verdrahtet.

[Nico B.]

Hm eigentlich doch nicht? Ich nutze ja mit Flex im Moment Swiz, da ist das genauso aufgebaut. Jedenfalls in meiner Implementation.
Sprich bsp. ein Service implementiert bei mir auch immer ein Interface. Die eigentliche "Hardcore"Logik der Applikation steht im Controller, der wiederum mit ganz bestimmten Events verknüpft ist usw.

(Oder ich verstehe gerade was falsch)

[Omega Psi]

Vielleicht verstand auch ich was falsch. Es las sich so, als würde das PM auch Services kapseln.