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. >
