Yishay did the implementation of this so I was a bit shaky on the details. I just looked at our code, and it appears that we did not actually use panels for the children.
It turns out the children are actually Containers which have a TitleBarModel bead. Sorry about the confusion. It might make sense to have an interface for an accordion-compatible container. We will put together an example which should work better in the morning. I cannot test my app which uses the Accordion right now because Promise is currently broken (like I wrote in my other email). Harbs > On Jun 2, 2017, at 7:01 PM, Peter Ent <p...@adobe.com.INVALID> wrote: > > Hi, > > It looks like this is the last thing to be resolved before we can make > FlexJS 0.8 release. > > I'm seeing two title bars per item in the Accordion. Any suggestions for > how to resolve this, based on the information I've given below? > > Thanks, > Peter > > On 6/1/17, 3:49 PM, "Peter Ent" <p...@adobe.com> wrote: > >> I've checked in my changes to the Accordion components. It still is not >> working correctly and I cannot figure out what is happening. The >> <js:Panel> used as the data to the Accordion are being placed as children >> of AccordionItemRenderers which are themselves Panels. So there are two >> TitleBars present per Accordion section. >> >> The layout mechanism changed so that the GroupView (the base view bead for >> all container-type view beads) no longer controls when layouts run; that >> is done by the layouts themselves. GroupView et al has a beforeLayout() >> and afterLayout() functions called by the layout classes which might be >> helpful, I'm not sure. >> >> Panel also changed quite a bit. A Panel is now a Group with its own layout >> that controls the placement of the TitleBar and Container which is its >> content area. When you specify a layout bead on a Panel, the Panel >> actually moves it to the content area Container. Perhaps this has >> something to do with the behavior we are now seeing. >> >> Please let me know if you have any suggestions on how to handle the >> Accordion as it now sits and I'll be happy to answer any questions about >> how the current view/layout system works now. >> >> If I may, perhaps Accordion could be changed as follows: >> >> <js:Accordion selectedIndex="0"> >> <js:AccordionSection title="Panel 1"> >> <!‹ a single child here, such as a Group, Container, or List ‹> >> </js:AccordionSection> >> <js:AccordionSection title="Panel 2"> >> <!‹ a single child here, such as a Group, Container, or a List ‹> >> </js:AccordionSection> >> </js:Accordion> >> >> The Accordion + AccordionView would create 2 children for each >> AccordionSection in the Accordion's space: an AccordionHeader + <single >> child>. >> >> The model would indicate which <single child> is being viewed and the >> layout, such as OneFlexibleChildVerticalLayout or >> OneFlexibleChildHorizontalLayout, would take care of sizing and >> positioning the AccordionHeader and <single child> elements. The <single >> child> elements not visible would simply have visible=false set; the >> layout will then ignore them. >> >> For the HTML side, this example would create a <DIV> with four children >> and not have any deep nesting unless that what the <single child> >> produces. The <single child> that's visible would have overflow:auto or >> overflow:hidden while the other <single child> elements would have >> display:none set. >> >> Merely a suggestion, and could probably use some refinement. >> >> ‹peter >> >> >> On 6/1/17, 2:03 PM, "yishayw" <yishayj...@hotmail.com> wrote: >> >>> Harbs wrote >>>> \2. The Collapse bead can only infer that it¹s collapsed by the fact >>>> that >>>> the size is the collapsed size ‹ which only makes sense if the size is >>>> set. >>> >>> Shouldn't .height return the measured height, regardless of whether it >>> was >>> explicitly set? >>> >>> >>> >>> >>> -- >>> View this message in context: >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fl >>> e >>> x-development.2333347.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p620 >>> 0 >>> 8.html&data=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b344 >>> 3 >>> 8794aed2c178decee1%7C0%7C0%7C636319378749470812&sdata=I%2BJ9TjnMxtY8VD4b4 >>> h >>> 6ljmTghd1Wy8yG8xo2eR9s6OY%3D&reserved=0 >>> Sent from the Apache Flex Development mailing list archive at Nabble.com. >> >
