On 11/16/16, 10:33 AM, "Yishay Weiss" <yishayj...@hotmail.com> wrote:
>That’s basically what happens. I decided to separate the collapse >mechanism from the view, thinking that it’s an isolated enough concern to >warrant a separate bead. The default implementation uses CollapseBead, >which does not depend on Effects. OK, but in my theoretical world, the coupling would be one step looser. The Accordion and maybe even AccordionView really wouldn't know about a Collapse bead. It would either just set size/visibility or warn anybody that is listening that it is setting size/visibility and be done. That would allow folks to add any sort of listener for the right events at any level, not just as a bead. Some folks are going to need choreography between effects on different components and may have a single instance of an effect manager somewhere that is listening to multiple components. The most basic Accordion would simply switch children by setting size and/or visibility. DropDownList's dropDown just shows up without any effect right now. But hopefully all sorts of effects implementations can introduce effects, some by dropping beads on the strand. Your app probably wants to use AccordionWithEasingCollapseEffect which would aggregate the EasingCollapseBead with the basic Accordion. My 2 cents, -Alex > >>IOW, the basic implementations should not assume there are an effects and >>just instantaneously change the view. But a bead should be able to alter >>that without any tight coupling other than events (or some sort of >>notification). >> >>My 2 cents, >>-Alex > >
