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+FlexJ >S+Framework >2. https://cwiki.apache.org/confluence/display/FLEX/Creating+Components
