I'm going to try to incorporate this discussion into the Express package;
seems like a great candidate for inclusion there.

Peter Ent
Adobe Systems/Apache Flex Project

On 2/14/17, 12:54 AM, "Alex Harui" <aha...@adobe.com> wrote:

>
>
>On 2/13/17, 9:40 PM, "Justin Mclean" <jus...@classsoftware.com> wrote:
>
>>Hi,
>>
>>> IMO, that isn't PAYG.  Container shouldn't need to carry around such
>>>code
>>> unless the app developer needs to changes styles at runtime.
>>> 
>>> Whatever code you needed to make this work should be wrapped up as a
>>>bead
>>> so folks can add the code if they need it.
>>
>>OK.
>>
>>Let's say the have a bead called UpdateStyleBead that updates styles in
>>that way (1 line of code).
>>
>>What shoudl trigger that call when a style changes happens? As far as I
>>can see there's no ³styleChange² event. There is a ³valueChanged" event
>>but that fires for binding which seem too heavyweight for me.
>
>I think if you used BindableCSSStyles instead of SimpleCSSStyles, then
>BindableCSSStyles would dispatch a change event.  So, a
>BackgroundColorChangeBead could listen for valueChange.
>
>If that is too inefficient for you, we could have BindableCSSStyles or a
>subclass dispatch a styleChange event.
>
>>
>>Is there a guide to writing beed anywhere that more more detail than
>>these? [1][2]
>
>Probably not.  Again, the functional code in a bead is meant to be an
>encapsulation of a code snippet.  Beads get hung on strands, and we
>encourage composition more than subclassing, but there should be very few
>rules on what a bead can do.
>
>>
>>Thanks,
>>Justin
>>
>>1. 
>>https://cwiki.apache.org/confluence/display/FLEX/Contributing+to+the+Flex
>>J
>>S+Framework
>>2. https://cwiki.apache.org/confluence/display/FLEX/Creating+Components
>

Reply via email to