1. Seems to be a data binding problem. (See other thread.) Yishay committed a
temporary work-around, but we don’t think that’s the right way to fix the
problem.
2. seems to be a measurement problem. The titleBar height is not being measured
correctly. This is a workaround (in a custom item renderer)
override public function get collapsedHeight():Number{
return 30;
}
> On Jun 4, 2017, at 12:41 AM, Harbs <[email protected]> wrote:
>
> 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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" <[email protected]> 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.
>>>>
>>>
>>
>
