This is what I have at the moment:
SolidBackgroundWithChangeListenerBead (extends SolidBackgroundBead) grabs
the style from its strand and sets up a listener for ValueChangeEvent. If
the style dispatches it, SBWCLB then invokes its super class's methods,
setupStyles and handleChange (both of which I made protected functions so
the code could be reused with little effort.
Changing the style involves: container.style.backgroundColor = 0xDD0000;
This works fine for SWFs. It does not work for JS. There's no code on the
JS side to transfer the container.style.backgroundColor to the
container.element.style.backgroundColor. I think the SBWCLB needs a JS
side to do that. Or, as you say, have BindableCSSStyle do it.
However, what I read below was that my
SolidBackgroundWithChangeListenerBead should really be StyleChangeNotifier
that dispatches a more generic "styleChanged" event (which might be an
extension of ValueChangeEvent). Then SolidBackgroundWithChangeListener
would listen for that event and then trigger a refresh of its background.
Then other beads, like SolidBoarderWithChangeListenerNotifierBead would do
the same for borders.
Then the application MXML becomes (you can't actually write this due to
the fact that SolidBackgroundWithChangeListenerBead would only be
available on SWF side so it would really go into a CSS with a media-query
set for flash):
<js:Container>
<js:style>
<js:BindableCSSStyle backgroundColor="blue" />
</js:style>
<js:beads>
<js:StyleChangeNotifierBead />
<js:SolidBackgroundWithChangeListenerBead />
</js:beads>
</js:Container>
Does this sound more on the right track?
‹peter
On 2/15/17, 1:23 PM, "Alex Harui" <aha...@adobe.com> wrote:
>
>
>On 2/15/17, 10:04 AM, "piotrz" <piotrzarzyck...@gmail.com> wrote:
>
>>Alex,
>>
>>Yes settings "style" wouldn't change some style property itself, but will
>>register couple of times listener - shouldn't we avoid it ?
>>
>>What do you mean saying "IMO, styleChangeHandler should be removed from
>>UIBase." - Where it should be placed exactly ?
>
>Maybe in a bead that looks for changes. That's sort of how
>LayoutChangeNotifier attempts to work. Another possibility is that a bead
>could encapsulate the changing of the styles.
>
>The host strand in theory only contains code for convenience. The beads
>should be talking to each other. In this case, the BindableCSSStyles bead
>and on the AS side a SolidBackgroundBead need to have a conversation. On
>the JS side, maybe BindableCSSStyles should just write to the element's
>style object.
>
>We tried to purposefully leave out a lot of dynamic behavior in order to
>see how small and fast Basic could be and if we can then add on dynamic
>behavior some other way. The Express package should bundle the dynamic
>behavior. So we are only now getting serious about how to implement this
>dynamic behavior, so there is definitely room for improvement.
>
>My 2 cents,
>-Alex
>
