I worked around the Promise issue (by copying js.swc to my project and not using the one in the SDK).
There’s at least 2 issues still: 1. The title property from the model is not being applied to the view of the item renderer. 2. The collapsed height of the collapsed items are 0 instead of the title bar height. > On Jun 4, 2017, at 12:10 AM, Harbs <harbs.li...@gmail.com> wrote: > > 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. >>> >> >
