I haven't sync'd anything since Friday, but I don't seem to be having the
measurement problem you are talking about.

I changed the Accordion children to VContainer and added the
TitleBarModel. Now I see the TitleBar (although it is blank) and the
segment contents. When I expose or hide the segments, I see all of the
bars stacked above and below the opened segment.

On SWF, the title bars are blank; on HTML the title bars are "undefined"
(as expected and noted in another thread on null vs undefined).

—peter

On 6/4/17, 5:57 AM, "Harbs" <harbs.li...@gmail.com> wrote:

>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 <harbs.li...@gmail.com> 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 <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%2Fapach
>>>>>>e-fl
>>>>>> e
>>>>>> 
>>>>>>x-development.2333347.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937
>>>>>>p620
>>>>>> 0
>>>>>> 
>>>>>>8.html&data=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7
>>>>>>b344
>>>>>> 3
>>>>>> 
>>>>>>8794aed2c178decee1%7C0%7C0%7C636319378749470812&sdata=I%2BJ9TjnMxtY8V
>>>>>>D4b4
>>>>>> h
>>>>>> 6ljmTghd1Wy8yG8xo2eR9s6OY%3D&reserved=0
>>>>>> Sent from the Apache Flex Development mailing list archive at
>>>>>>Nabble.com.
>>>>> 
>>>> 
>>> 
>> 
>

Reply via email to