flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ent <p...@adobe.com>
Subject Re: [FlexJS] Setting background colour at run time fails
Date Thu, 16 Feb 2017 15:22:42 GMT

I've pushed the following changes:

Core package: added StyleChangeNotifier and StyleChange event.
StyleChangeNotifier listens for ValueChangeEvents on its strand's style. I
decided to park this in Core because it seems listening for style changes
would be more universal than just HTML package. On the SWF side, the
StyleChangeNotifier simply detects a change in the style and dispatches a
new, StyleChangeEvent.STYLE_CHANGE event for anything that might be
interested. On the JS side, StyleChangeNotifier updates its strand's
wrapped element's style directly.

HTML package: I changed SolidBackgroundWithChangeListenerBead to be
SWF-only and to listen for STYLE_CHANGE events. When it sees such an
event, it causes the background of the strand to refresh.

I felt, after with Alex, that since SolidBackgroundBead is SWF-only, its
derivative, SolidBackgroundWithChangeListenerBead should also be SWF-only
which left few places for the JS side to actually change the style, so I
stuck that in the StyleChangeNotifier; it seems to work well.

To use this:

    @namespace js "library://ns.apache.org/flexjs/basic";
    @media -flex-flash {
       js|Container {

<js:Container id="box">
        <js:BindableCSSStyles backgroundColor="blue" />
        <js:StyleChangeNotifier />

You can change the Container's background:  box.style.backgroundColor =

I will do the same for the border styles and then roll it into the Express
package Container element.


On 2/15/17, 2:48 PM, "Peter Ent" <pent@adobe.com> wrote:

>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:style>
>        <js:BindableCSSStyle backgroundColor="blue" />
>     </js:style>
>     <js:beads>
>         <js:StyleChangeNotifierBead />
>         <js:SolidBackgroundWithChangeListenerBead />
>     </js:beads>
>Does this sound more on the right track?
>On 2/15/17, 1:23 PM, "Alex Harui" <aharui@adobe.com> wrote:
>>On 2/15/17, 10:04 AM, "piotrz" <piotrzarzycki21@gmail.com> wrote:
>>>Yes settings "style" wouldn't change some style property itself, but
>>>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
>>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
>>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,

View raw message