Thanks, I was not thinking this from that point of view. Maybe in MDL has sense to include majority of beads since it's a concrete implementation of visuals: Material Design Lite But don't know if we could have a base control (ButtonBase...for example but doesn't like too much that name) and then another (the Button *actual class*) that instantiates ButtonEffect and Disable beads
btw, if you notice, I remove the "Bead" ending in my beads, since I think is less verbose and the mxml is pretty descriptive (those are parte of js:beads). As well I implemented effects with boolean flags. I have to make different beads for different controls since are effect "per-control", with some to them common and available in an MDLEffect bead that the rest extend from. 2016-10-27 8:26 GMT+02:00 yishayw <yishayj...@hotmail.com>: > Another advantage of beads, as I see it, is that they can be modular. The > way > I implemented DisableBead it does the minimum, which is to change > style.pointerEvents to 'none', but it also dispatches a 'disabledChange' > event on the strand. The latter allows an additional bead, e.g. BlurBead, > to > listen to 'disabledChanged' and change opacity. Then you get the default > behavior, which is to disable pointer events, and an added effect where > necessary, reusing code. > > To minimize verboseness I suppose you could have 'DisableAndBlurBead' which > adds 'DisableBead' and 'BlurBead'. Of course, baking it in in advance is > the > least verbose and could work for a non-basic component set. > > > > > -- > View this message in context: http://apache-flex- > development.2333347.n4.nabble.com/FlexJS-When-to-Bead-was- > Re-FlexJS-enabled-property-tp56044p56049.html > Sent from the Apache Flex Development mailing list archive at Nabble.com. > -- Carlos Rovira Director General M: +34 607 22 60 05 http://www.codeoscopic.com http://www.avant2.es Este mensaje se dirige exclusivamente a su destinatario y puede contener información privilegiada o confidencial. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC S.A. La finalidad de dicho tratamiento es facilitar la prestación del servicio o información solicitados, teniendo usted derecho de acceso, rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación necesaria.
