You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2017/05/30 10:39:04 UTC
[FlexJS] Accordion broken
It seems like the new layouts totally broke Accordion.
Accordion relied on absolute sizing to handle expanding and collapsing of content. I tried to add a new layout which is basically a copy of the old OneFlexibleVerticalLayout and use that for accordion, but that does not seem to work either due to changes in containers (I think).
Peter, do you thin you could look into this?
Thanks,
Harbs
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
OK, thanks. Alex some alternative layouts I can try.
—peter
On 5/30/17, 11:35 AM, "Harbs" <ha...@gmail.com> wrote:
>The reasons it’s broken is (at least) thee-fold:
>
>1. Panels contain content and need to be collapsed despite the fact that
>content exists.
>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.
>3. The title must be measured to set the collapsed height correctly.
>
>> On May 30, 2017, at 6:21 PM, Harbs <ha...@gmail.com> wrote:
>>
>> Something like this:
>>
>> <js:Accordion selectedIndex="0">
>> <js:dataProvider>
>> <fx:Array>
>> <js:Panel id="panel1" title="Panel 1"/>
>> <js:Panel id="panl2" title="Panel 2"/>
>> </fx:Array>
>> </js:dataProvider>
>> </js:Accordion>
>>
>> This is the markup of an Accordion which used to work, which doesn’t
>>anymore.
>>
>> <js:Accordion id="accordion" width="100%" height="100%">
>> <js:dataProvider>
>> <fx:Array>
>> <view:SetupPanel/>
>> <view:PackagePanel/>
>> <view:TemplatePanel/>
>> <view:FontPanel/>
>> </fx:Array>
>> </js:dataProvider>
>> </js:Accordion>
>>
>>
>>> On May 30, 2017, at 4:54 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>>>
>>> Hi,
>>>
>>> Do you have a quick example of how to use the FlexJS Accordion? The
>>>ASDoc
>>> on it is thin. The children of the Flex SDK Accordion were navigation
>>> components that supported things like title so each section could be
>>> labeled. I don't see an AccordionChild or something similar that can be
>>> used with Accordion. I took a guess and made Container a child of it,
>>>but
>>> it just blew up.
>>>
>>> Thanks,
>>> ‹peter
>>>
>>> On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> It seems like the new layouts totally broke Accordion.
>>>>
>>>> Accordion relied on absolute sizing to handle expanding and
>>>>collapsing of
>>>> content. I tried to add a new layout which is basically a copy of the
>>>>old
>>>> OneFlexibleVerticalLayout and use that for accordion, but that does
>>>>not
>>>> seem to work either due to changes in containers (I think).
>>>>
>>>> Peter, do you thin you could look into this?
>>>>
>>>> Thanks,
>>>> Harbs
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
Thanks. I'll look into this today if I get a chance and definitely tomorrow.
Peter
> On Jun 4, 2017, at 6:05 AM, yishayw <yi...@hotmail.com> wrote:
>
> Here's [1] an example app.
>
> The 2 problems I see:
>
> 1) DataBinding problems [2] cause titles to be undefined. I hacked a fix on
> TLF branch, but this should probably addressed differently.
> 2) TitleBar.height returns 0, even though the measured height is 30. I think
> this is a bug, am I wrong?
>
> Thanks.
>
> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apache.org%2FQUj1&data=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477479646&sdata=0qp76vTwMIdyOnFnuFZh1CPn62T3ALjIvYV47j3Aqvs%3D&reserved=0
> [2]
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-DataBinding-Problem-td62073.html&data=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477489658&sdata=1y0o9R2qZWimrsFH%2FTyU%2B5061RVbnFQgpRsQ5CKtmfc%3D&reserved=0
>
>
>
>
> --
> View this message in context: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.2333347.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p62080.html&data=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477489658&sdata=s3BPfklP65X5fXGknNX0ZB%2FfREeToXzsiGhKV%2BSpSJo%3D&reserved=0
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
Posted by yishayw <yi...@hotmail.com>.
Here's [1] an example app.
The 2 problems I see:
1) DataBinding problems [2] cause titles to be undefined. I hacked a fix on
TLF branch, but this should probably addressed differently.
2) TitleBar.height returns 0, even though the measured height is 30. I think
this is a bug, am I wrong?
Thanks.
[1] https://paste.apache.org/QUj1
[2]
http://apache-flex-development.2333347.n4.nabble.com/FlexJS-DataBinding-Problem-td62073.html
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62080.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
Posted by Alex Harui <ah...@adobe.com.INVALID>.
I just pushed changes that make Accordion look ok to me on both SWF and
JS.
This is the test case I used.
https://paste.apache.org/ELvN
-Alex
On 6/5/17, 10:57 PM, "yishayw" <yi...@hotmail.com> wrote:
>Not sure I understand. Is release Accordion working with the example I
>posted
>[1]?
>
>I just fetched and logged flex-asjs and couldn't see any accordion related
>changes. Can you send a commit id?
>
>Thanks.
>
>[1]
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FQUj1&data=02%7C01%7C%7Cdfe8b2d30dc44076114908d4aca2fece%7Cfa7b1b
>5a7b34438794aed2c178decee1%7C0%7C0%7C636323263446558116&sdata=g0Pmu%2B4Hxz
>6UTkQDr9UFrY99G5iWFW%2BoM6GaQYQpDsU%3D&reserved=0
>
>
>
>--
>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-tp61937p6213
>2.html&data=02%7C01%7C%7Cdfe8b2d30dc44076114908d4aca2fece%7Cfa7b1b5a7b3443
>8794aed2c178decee1%7C0%7C0%7C636323263446558116&sdata=nIdep75b00l93OzUSqjK
>w86fgi48S6H4ktZhLFFHXKs%3D&reserved=0
>Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
Posted by yishayw <yi...@hotmail.com>.
Not sure I understand. Is release Accordion working with the example I posted
[1]?
I just fetched and logged flex-asjs and couldn't see any accordion related
changes. Can you send a commit id?
Thanks.
[1] https://paste.apache.org/QUj1
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62132.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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" <ha...@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 <ha...@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 <ha...@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 <pe...@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" <pe...@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" <yi...@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.
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <ha...@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 <pe...@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" <pe...@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" <yi...@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.
>>>>
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Harbs <ha...@gmail.com>.
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 <ha...@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 <pe...@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" <pe...@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" <yi...@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.
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Alex Harui <ah...@adobe.com.INVALID>.
On 6/3/17, 2:10 PM, "Harbs" <ha...@gmail.com> wrote:
>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.
My recommendation, as an alternative to an interface, would be to have an
"AccordionInfoBead" that the Accordion expects to find on each child.
That way, just about anything can be an Accordion child without having to
always carry around a title property. And fancier versions of Accordion
could have fancier AccordionInfoBeads that might dictate close and open
effects, maybe minimum sizes, label sizes, and more.
Food for thought for the next release,
-Alex
Re: [FlexJS] Accordion broken
Posted by Harbs <ha...@gmail.com>.
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 <pe...@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" <pe...@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" <yi...@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.
>>
>
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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" <pe...@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" <yi...@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.
>
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
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" <yi...@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.
Re: [FlexJS] Accordion broken
Posted by yishayw <yi...@hotmail.com>.
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: http://apache-flex-development.2333347.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62008.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
With some guidance from Alex, I have the Accordion "working". The problem
now is that it appears as a Panel-in-Panel for each item. For example,
with two Panels in the dataProvider, there are two bars and whichever is
"open" or "selected" shows the Panel from the dataProvider along with its
title bar. I understand using a Panel as the itemRenderer, but I don't see
how there cannot be two title bars. I will continue to sort this out.
—peter
On 5/31/17, 2:47 PM, "Harbs" <ha...@gmail.com> wrote:
>Yishay had some code to handle the cases where it’s not set via MXML
>which you removed.
>
>I changed his code to simply intialize the document if it was not set by
>MXML like this:
>
> //Needed if the layout is not declared using MXML
> private function initializeDocument(contentView:ILayoutView):void
> {
> document = {};
> for (var i:int = 0; i < contentView.numElements; i++)
> {
> var child:IStyleableObject = contentView.getElementAt(i) as
>IStyleableObject;
> document[child.id] = child;
> }
> }
>
>and in layout():
> if(document == null)
> initializeDocument(contentView);
>
>An AccordionLayout might make sense though. And switching to selection
>rather than checking collapsed might make sense as well.
>
>Thanks for working on this.
>
>> On May 31, 2017, at 7:47 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>>
>> I'm still working on this and ran into a couple of issues.
>>
>> The flexible child layouts no longer provide a way to explicitly set a
>> child; instead they rely in the child's id being used to retrieve the
>> child from the document. Unfortunately, a layout that is not referenced
>>in
>> MXML will not get its document set.
>>
>> Perhaps a better solution is to write "AccordionLayout" that will expand
>> the child selected by the model, but I'm still looking at making use of
>> what is already there.
>>
>> —peter
>>
>>
>>
>> On 5/30/17, 11:35 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> The reasons it’s broken is (at least) thee-fold:
>>>
>>> 1. Panels contain content and need to be collapsed despite the fact
>>>that
>>> content exists.
>>> 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.
>>> 3. The title must be measured to set the collapsed height correctly.
>>>
>>>> On May 30, 2017, at 6:21 PM, Harbs <ha...@gmail.com> wrote:
>>>>
>>>> Something like this:
>>>>
>>>> <js:Accordion selectedIndex="0">
>>>> <js:dataProvider>
>>>> <fx:Array>
>>>> <js:Panel id="panel1" title="Panel 1"/>
>>>> <js:Panel id="panl2" title="Panel 2"/>
>>>> </fx:Array>
>>>> </js:dataProvider>
>>>> </js:Accordion>
>>>>
>>>> This is the markup of an Accordion which used to work, which doesn’t
>>>> anymore.
>>>>
>>>> <js:Accordion id="accordion" width="100%" height="100%">
>>>> <js:dataProvider>
>>>> <fx:Array>
>>>> <view:SetupPanel/>
>>>> <view:PackagePanel/>
>>>> <view:TemplatePanel/>
>>>> <view:FontPanel/>
>>>> </fx:Array>
>>>> </js:dataProvider>
>>>> </js:Accordion>
>>>>
>>>>
>>>>> On May 30, 2017, at 4:54 PM, Peter Ent <pe...@adobe.com.INVALID>
>>>>>wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Do you have a quick example of how to use the FlexJS Accordion? The
>>>>> ASDoc
>>>>> on it is thin. The children of the Flex SDK Accordion were navigation
>>>>> components that supported things like title so each section could be
>>>>> labeled. I don't see an AccordionChild or something similar that can
>>>>>be
>>>>> used with Accordion. I took a guess and made Container a child of it,
>>>>> but
>>>>> it just blew up.
>>>>>
>>>>> Thanks,
>>>>> ‹peter
>>>>>
>>>>> On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>>
>>>>>> It seems like the new layouts totally broke Accordion.
>>>>>>
>>>>>> Accordion relied on absolute sizing to handle expanding and
>>>>>> collapsing of
>>>>>> content. I tried to add a new layout which is basically a copy of
>>>>>>the
>>>>>> old
>>>>>> OneFlexibleVerticalLayout and use that for accordion, but that does
>>>>>> not
>>>>>> seem to work either due to changes in containers (I think).
>>>>>>
>>>>>> Peter, do you thin you could look into this?
>>>>>>
>>>>>> Thanks,
>>>>>> Harbs
>>>>>
>>>>
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Harbs <ha...@gmail.com>.
Yishay had some code to handle the cases where it’s not set via MXML which you removed.
I changed his code to simply intialize the document if it was not set by MXML like this:
//Needed if the layout is not declared using MXML
private function initializeDocument(contentView:ILayoutView):void
{
document = {};
for (var i:int = 0; i < contentView.numElements; i++)
{
var child:IStyleableObject = contentView.getElementAt(i) as IStyleableObject;
document[child.id] = child;
}
}
and in layout():
if(document == null)
initializeDocument(contentView);
An AccordionLayout might make sense though. And switching to selection rather than checking collapsed might make sense as well.
Thanks for working on this.
> On May 31, 2017, at 7:47 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>
> I'm still working on this and ran into a couple of issues.
>
> The flexible child layouts no longer provide a way to explicitly set a
> child; instead they rely in the child's id being used to retrieve the
> child from the document. Unfortunately, a layout that is not referenced in
> MXML will not get its document set.
>
> Perhaps a better solution is to write "AccordionLayout" that will expand
> the child selected by the model, but I'm still looking at making use of
> what is already there.
>
> —peter
>
>
>
> On 5/30/17, 11:35 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> The reasons it’s broken is (at least) thee-fold:
>>
>> 1. Panels contain content and need to be collapsed despite the fact that
>> content exists.
>> 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.
>> 3. The title must be measured to set the collapsed height correctly.
>>
>>> On May 30, 2017, at 6:21 PM, Harbs <ha...@gmail.com> wrote:
>>>
>>> Something like this:
>>>
>>> <js:Accordion selectedIndex="0">
>>> <js:dataProvider>
>>> <fx:Array>
>>> <js:Panel id="panel1" title="Panel 1"/>
>>> <js:Panel id="panl2" title="Panel 2"/>
>>> </fx:Array>
>>> </js:dataProvider>
>>> </js:Accordion>
>>>
>>> This is the markup of an Accordion which used to work, which doesn’t
>>> anymore.
>>>
>>> <js:Accordion id="accordion" width="100%" height="100%">
>>> <js:dataProvider>
>>> <fx:Array>
>>> <view:SetupPanel/>
>>> <view:PackagePanel/>
>>> <view:TemplatePanel/>
>>> <view:FontPanel/>
>>> </fx:Array>
>>> </js:dataProvider>
>>> </js:Accordion>
>>>
>>>
>>>> On May 30, 2017, at 4:54 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Do you have a quick example of how to use the FlexJS Accordion? The
>>>> ASDoc
>>>> on it is thin. The children of the Flex SDK Accordion were navigation
>>>> components that supported things like title so each section could be
>>>> labeled. I don't see an AccordionChild or something similar that can be
>>>> used with Accordion. I took a guess and made Container a child of it,
>>>> but
>>>> it just blew up.
>>>>
>>>> Thanks,
>>>> ‹peter
>>>>
>>>> On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> It seems like the new layouts totally broke Accordion.
>>>>>
>>>>> Accordion relied on absolute sizing to handle expanding and
>>>>> collapsing of
>>>>> content. I tried to add a new layout which is basically a copy of the
>>>>> old
>>>>> OneFlexibleVerticalLayout and use that for accordion, but that does
>>>>> not
>>>>> seem to work either due to changes in containers (I think).
>>>>>
>>>>> Peter, do you thin you could look into this?
>>>>>
>>>>> Thanks,
>>>>> Harbs
>>>>
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
I'm still working on this and ran into a couple of issues.
The flexible child layouts no longer provide a way to explicitly set a
child; instead they rely in the child's id being used to retrieve the
child from the document. Unfortunately, a layout that is not referenced in
MXML will not get its document set.
Perhaps a better solution is to write "AccordionLayout" that will expand
the child selected by the model, but I'm still looking at making use of
what is already there.
—peter
On 5/30/17, 11:35 AM, "Harbs" <ha...@gmail.com> wrote:
>The reasons it’s broken is (at least) thee-fold:
>
>1. Panels contain content and need to be collapsed despite the fact that
>content exists.
>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.
>3. The title must be measured to set the collapsed height correctly.
>
>> On May 30, 2017, at 6:21 PM, Harbs <ha...@gmail.com> wrote:
>>
>> Something like this:
>>
>> <js:Accordion selectedIndex="0">
>> <js:dataProvider>
>> <fx:Array>
>> <js:Panel id="panel1" title="Panel 1"/>
>> <js:Panel id="panl2" title="Panel 2"/>
>> </fx:Array>
>> </js:dataProvider>
>> </js:Accordion>
>>
>> This is the markup of an Accordion which used to work, which doesn’t
>>anymore.
>>
>> <js:Accordion id="accordion" width="100%" height="100%">
>> <js:dataProvider>
>> <fx:Array>
>> <view:SetupPanel/>
>> <view:PackagePanel/>
>> <view:TemplatePanel/>
>> <view:FontPanel/>
>> </fx:Array>
>> </js:dataProvider>
>> </js:Accordion>
>>
>>
>>> On May 30, 2017, at 4:54 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>>>
>>> Hi,
>>>
>>> Do you have a quick example of how to use the FlexJS Accordion? The
>>>ASDoc
>>> on it is thin. The children of the Flex SDK Accordion were navigation
>>> components that supported things like title so each section could be
>>> labeled. I don't see an AccordionChild or something similar that can be
>>> used with Accordion. I took a guess and made Container a child of it,
>>>but
>>> it just blew up.
>>>
>>> Thanks,
>>> ‹peter
>>>
>>> On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> It seems like the new layouts totally broke Accordion.
>>>>
>>>> Accordion relied on absolute sizing to handle expanding and
>>>>collapsing of
>>>> content. I tried to add a new layout which is basically a copy of the
>>>>old
>>>> OneFlexibleVerticalLayout and use that for accordion, but that does
>>>>not
>>>> seem to work either due to changes in containers (I think).
>>>>
>>>> Peter, do you thin you could look into this?
>>>>
>>>> Thanks,
>>>> Harbs
>>>
>>
>
Re: [FlexJS] Accordion broken
Posted by Harbs <ha...@gmail.com>.
The reasons it’s broken is (at least) thee-fold:
1. Panels contain content and need to be collapsed despite the fact that content exists.
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.
3. The title must be measured to set the collapsed height correctly.
> On May 30, 2017, at 6:21 PM, Harbs <ha...@gmail.com> wrote:
>
> Something like this:
>
> <js:Accordion selectedIndex="0">
> <js:dataProvider>
> <fx:Array>
> <js:Panel id="panel1" title="Panel 1"/>
> <js:Panel id="panl2" title="Panel 2"/>
> </fx:Array>
> </js:dataProvider>
> </js:Accordion>
>
> This is the markup of an Accordion which used to work, which doesn’t anymore.
>
> <js:Accordion id="accordion" width="100%" height="100%">
> <js:dataProvider>
> <fx:Array>
> <view:SetupPanel/>
> <view:PackagePanel/>
> <view:TemplatePanel/>
> <view:FontPanel/>
> </fx:Array>
> </js:dataProvider>
> </js:Accordion>
>
>
>> On May 30, 2017, at 4:54 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>>
>> Hi,
>>
>> Do you have a quick example of how to use the FlexJS Accordion? The ASDoc
>> on it is thin. The children of the Flex SDK Accordion were navigation
>> components that supported things like title so each section could be
>> labeled. I don't see an AccordionChild or something similar that can be
>> used with Accordion. I took a guess and made Container a child of it, but
>> it just blew up.
>>
>> Thanks,
>> ‹peter
>>
>> On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> It seems like the new layouts totally broke Accordion.
>>>
>>> Accordion relied on absolute sizing to handle expanding and collapsing of
>>> content. I tried to add a new layout which is basically a copy of the old
>>> OneFlexibleVerticalLayout and use that for accordion, but that does not
>>> seem to work either due to changes in containers (I think).
>>>
>>> Peter, do you thin you could look into this?
>>>
>>> Thanks,
>>> Harbs
>>
>
Re: [FlexJS] Accordion broken
Posted by Harbs <ha...@gmail.com>.
Something like this:
<js:Accordion selectedIndex="0">
<js:dataProvider>
<fx:Array>
<js:Panel id="panel1" title="Panel 1"/>
<js:Panel id="panl2" title="Panel 2"/>
</fx:Array>
</js:dataProvider>
</js:Accordion>
This is the markup of an Accordion which used to work, which doesn’t anymore.
<js:Accordion id="accordion" width="100%" height="100%">
<js:dataProvider>
<fx:Array>
<view:SetupPanel/>
<view:PackagePanel/>
<view:TemplatePanel/>
<view:FontPanel/>
</fx:Array>
</js:dataProvider>
</js:Accordion>
> On May 30, 2017, at 4:54 PM, Peter Ent <pe...@adobe.com.INVALID> wrote:
>
> Hi,
>
> Do you have a quick example of how to use the FlexJS Accordion? The ASDoc
> on it is thin. The children of the Flex SDK Accordion were navigation
> components that supported things like title so each section could be
> labeled. I don't see an AccordionChild or something similar that can be
> used with Accordion. I took a guess and made Container a child of it, but
> it just blew up.
>
> Thanks,
> ‹peter
>
> On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> It seems like the new layouts totally broke Accordion.
>>
>> Accordion relied on absolute sizing to handle expanding and collapsing of
>> content. I tried to add a new layout which is basically a copy of the old
>> OneFlexibleVerticalLayout and use that for accordion, but that does not
>> seem to work either due to changes in containers (I think).
>>
>> Peter, do you thin you could look into this?
>>
>> Thanks,
>> Harbs
>
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
Hi,
Do you have a quick example of how to use the FlexJS Accordion? The ASDoc
on it is thin. The children of the Flex SDK Accordion were navigation
components that supported things like title so each section could be
labeled. I don't see an AccordionChild or something similar that can be
used with Accordion. I took a guess and made Container a child of it, but
it just blew up.
Thanks,
‹peter
On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>It seems like the new layouts totally broke Accordion.
>
>Accordion relied on absolute sizing to handle expanding and collapsing of
>content. I tried to add a new layout which is basically a copy of the old
>OneFlexibleVerticalLayout and use that for accordion, but that does not
>seem to work either due to changes in containers (I think).
>
>Peter, do you thin you could look into this?
>
>Thanks,
>Harbs
Re: [FlexJS] Accordion broken
Posted by Peter Ent <pe...@adobe.com.INVALID>.
I am looking into it. I will also create an example for Accordion so it
will be easier to test it in the future.
‹peter
On 5/30/17, 6:39 AM, "Harbs" <ha...@gmail.com> wrote:
>It seems like the new layouts totally broke Accordion.
>
>Accordion relied on absolute sizing to handle expanding and collapsing of
>content. I tried to add a new layout which is basically a copy of the old
>OneFlexibleVerticalLayout and use that for accordion, but that does not
>seem to work either due to changes in containers (I think).
>
>Peter, do you thin you could look into this?
>
>Thanks,
>Harbs