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-fle
>x-development.2333347.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p6200
>8.html&data=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b3443
>8794aed2c178decee1%7C0%7C0%7C636319378749470812&sdata=I%2BJ9TjnMxtY8VD4b4h
>6ljmTghd1Wy8yG8xo2eR9s6OY%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
