Hey > a while ago, I've looked over the Accordion from "adobe.next" branch, > having the same intention on my mind. What I found out is that they went > all the way down, modifying UIComponent to add elementCreationPolicy and > elementDestructionPolicy to the NavigatorContent, in order to make the > Accordion support creation and destruction policies. > > Since Accordion component seems the only one who needs that, my approach > (which remained an experiment that I haven't had time to finish), was to > create a class named NavigatorContentWithPolicies that extends > SkinnableContainer, so UIComponent doesn't need to be altered.
@Alex or Carol do you know if there were any reason why elementDestructionPolicy was added in UIComponent and not in a way as Bogdan describes? > Besides a bug about specifying width / height on AccordionContent that > produces malfunction (never closes), the Accordion component seems > compliant to pairing the MX one. Yes .. until now I have the same impression that it brings everything that the mx one does. Just having some issue with the icon attribute I'm trying to figure out. I haven't look at tink's source code yet just at his examples [1] .. but I definitely look also at his source code. If we choose the Accordion in adobe.next branch I would suggest following steps: 1) Moving all relevant classes to develop branch direct in spark project (not experimental project). 2) Writing mustella tests for accordion. Or would you prefer the experimental project? [1]http://www.tink.ws/examples/apache-flex/
