Re: [FlexJS] Accordion broken
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"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=02%7C01%7C%7Cdfe8b2d30dc44076114908d4aca2fece%7Cfa7b1b >5a7b34438794aed2c178decee1%7C0%7C0%7C636323263446558116=g0Pmu%2B4Hxz >6UTkQDr9UFrY99G5iWFW%2BoM6GaQYQpDsU%3D=0 > > > >-- >View this message in context: >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle >x-development.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p6213 >2.html=02%7C01%7C%7Cdfe8b2d30dc44076114908d4aca2fece%7Cfa7b1b5a7b3443 >8794aed2c178decee1%7C0%7C0%7C636323263446558116=nIdep75b00l93OzUSqjK >w86fgi48S6H4ktZhLFFHXKs%3D=0 >Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
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.247.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62132.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
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"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 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 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 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" 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 > 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: > > > > > > > > > > > The Accordion + AccordionView would create 2 children for each > AccordionSection in the Accordion's space: an AccordionHeader + > child>. > > The model would indicate which is being viewed and the > layout, such as OneFlexibleChildVerticalLayout or > OneFlexibleChildHorizontalLayout, would take care of sizing and > positioning the AccordionHeader and elements. The > 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 with four >children > and not have any deep nesting unless that what the > produces. The that's visible would have overflow:auto >or > overflow:hidden while the other elements would have > display:none set. > > Merely a suggestion, and could probably use some refinement. > > ‹peter > > > On 6/1/17,
Re: [FlexJS] Accordion broken
On 6/3/17, 2:10 PM, "Harbs"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
Thanks. I'll look into this today if I get a chance and definitely tomorrow. Peter > On Jun 4, 2017, at 6:05 AM, yishaywwrote: > > 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=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477479646=0qp76vTwMIdyOnFnuFZh1CPn62T3ALjIvYV47j3Aqvs%3D=0 > [2] > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2FFlexJS-DataBinding-Problem-td62073.html=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477489658=1y0o9R2qZWimrsFH%2FTyU%2B5061RVbnFQgpRsQ5CKtmfc%3D=0 > > > > > -- > View this message in context: > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-flex-development.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p62080.html=02%7C01%7C%7Cb335b9934ee44b3faf9d08d4ab3143ce%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636321675477489658=s3BPfklP65X5fXGknNX0ZB%2FfREeToXzsiGhKV%2BSpSJo%3D=0 > Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
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.247.n4.nabble.com/FlexJS-DataBinding-Problem-td62073.html -- View this message in context: http://apache-flex-development.247.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62080.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
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, Harbswrote: > > 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 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 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" 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 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: The Accordion + AccordionView would create 2 children for each AccordionSection in the Accordion's space: an AccordionHeader + >>> child>. The model would indicate which is being viewed and the layout, such as OneFlexibleChildVerticalLayout or OneFlexibleChildHorizontalLayout, would take care of sizing and positioning the AccordionHeader and elements. The >>> 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 with four children and not have any deep nesting unless that what the produces. The that's visible would have overflow:auto or overflow:hidden while the other elements would have display:none set. Merely a suggestion, and could probably use some refinement. ‹peter On 6/1/17, 2:03 PM, "yishayw" 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.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p620 > 0 > 8.html=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b344 > 3 >
Re: [FlexJS] Accordion broken
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, Harbswrote: > > 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 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" 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 >>> 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: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> The Accordion + AccordionView would create 2 children for each >>> AccordionSection in the Accordion's space: an AccordionHeader + >> child>. >>> >>> The model would indicate which is being viewed and the >>> layout, such as OneFlexibleChildVerticalLayout or >>> OneFlexibleChildHorizontalLayout, would take care of sizing and >>> positioning the AccordionHeader and elements. The >> 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 with four children >>> and not have any deep nesting unless that what the >>> produces. The that's visible would have overflow:auto or >>> overflow:hidden while the other elements would have >>> display:none set. >>> >>> Merely a suggestion, and could probably use some refinement. >>> >>> ‹peter >>> >>> >>> On 6/1/17, 2:03 PM, "yishayw" 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.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p620 0 8.html=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b344 3 8794aed2c178decee1%7C0%7C0%7C636319378749470812=I%2BJ9TjnMxtY8VD4b4 h 6ljmTghd1Wy8yG8xo2eR9s6OY%3D=0 Sent from the Apache Flex Development mailing list archive at Nabble.com. >>> >> >
Re: [FlexJS] Accordion broken
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 Entwrote: > > 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" 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 >> 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: >> >> >> >> >> >> >> >> >> >> >> The Accordion + AccordionView would create 2 children for each >> AccordionSection in the Accordion's space: an AccordionHeader + > child>. >> >> The model would indicate which is being viewed and the >> layout, such as OneFlexibleChildVerticalLayout or >> OneFlexibleChildHorizontalLayout, would take care of sizing and >> positioning the AccordionHeader and elements. The > 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 with four children >> and not have any deep nesting unless that what the >> produces. The that's visible would have overflow:auto or >> overflow:hidden while the other elements would have >> display:none set. >> >> Merely a suggestion, and could probably use some refinement. >> >> ‹peter >> >> >> On 6/1/17, 2:03 PM, "yishayw" 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.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p620 >>> 0 >>> 8.html=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b344 >>> 3 >>> 8794aed2c178decee1%7C0%7C0%7C636319378749470812=I%2BJ9TjnMxtY8VD4b4 >>> h >>> 6ljmTghd1Wy8yG8xo2eR9s6OY%3D=0 >>> Sent from the Apache Flex Development mailing list archive at Nabble.com. >> >
Re: [FlexJS] Accordion broken
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"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 > 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: > > > > > > > > > > >The Accordion + AccordionView would create 2 children for each >AccordionSection in the Accordion's space: an AccordionHeader + child>. > >The model would indicate which is being viewed and the >layout, such as OneFlexibleChildVerticalLayout or >OneFlexibleChildHorizontalLayout, would take care of sizing and >positioning the AccordionHeader and elements. The 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 with four children >and not have any deep nesting unless that what the >produces. The that's visible would have overflow:auto or >overflow:hidden while the other elements would have >display:none set. > >Merely a suggestion, and could probably use some refinement. > >‹peter > > >On 6/1/17, 2:03 PM, "yishayw" 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.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p620 >>0 >>8.html=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b344 >>3 >>8794aed2c178decee1%7C0%7C0%7C636319378749470812=I%2BJ9TjnMxtY8VD4b4 >>h >>6ljmTghd1Wy8yG8xo2eR9s6OY%3D=0 >>Sent from the Apache Flex Development mailing list archive at Nabble.com. >
Re: [FlexJS] Accordion broken
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 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: The Accordion + AccordionView would create 2 children for each AccordionSection in the Accordion's space: an AccordionHeader + . The model would indicate which is being viewed and the layout, such as OneFlexibleChildVerticalLayout or OneFlexibleChildHorizontalLayout, would take care of sizing and positioning the AccordionHeader and elements. The elements not visible would simply have visible=false set; the layout will then ignore them. For the HTML side, this example would create a with four children and not have any deep nesting unless that what the produces. The that's visible would have overflow:auto or overflow:hidden while the other elements would have display:none set. Merely a suggestion, and could probably use some refinement. ‹peter On 6/1/17, 2:03 PM, "yishayw"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.247.n4.nabble.com%2FFlexJS-Accordion-broken-tp61937p6200 >8.html=02%7C01%7C%7C9b640697ac694828308808d4a91a8573%7Cfa7b1b5a7b3443 >8794aed2c178decee1%7C0%7C0%7C636319378749470812=I%2BJ9TjnMxtY8VD4b4h >6ljmTghd1Wy8yG8xo2eR9s6OY%3D=0 >Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
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.247.n4.nabble.com/FlexJS-Accordion-broken-tp61937p62008.html Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: [FlexJS] Accordion broken
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"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 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" 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 wrote: Something like this: This is the markup of an Accordion which used to work, which doesn’t anymore. > On May 30, 2017, at 4:54 PM, Peter Ent >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" 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
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 Entwrote: > > 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" 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 wrote: >>> >>> Something like this: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> This is the markup of an Accordion which used to work, which doesn’t >>> anymore. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On May 30, 2017, at 4:54 PM, Peter Ent 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" 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
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"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 wrote: >> >> Something like this: >> >> >> >> >> >> >> >> >> >> >> This is the markup of an Accordion which used to work, which doesn’t >>anymore. >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On May 30, 2017, at 4:54 PM, Peter Ent 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" 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
OK, thanks. Alex some alternative layouts I can try. —peter On 5/30/17, 11:35 AM, "Harbs"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 wrote: >> >> Something like this: >> >> >> >> >> >> >> >> >> >> >> This is the markup of an Accordion which used to work, which doesn’t >>anymore. >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On May 30, 2017, at 4:54 PM, Peter Ent 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" 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
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, Harbswrote: > > Something like this: > > > > > > > > > > > This is the markup of an Accordion which used to work, which doesn’t anymore. > > > > > > > > > > > > > >> On May 30, 2017, at 4:54 PM, Peter Ent 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" 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
Something like this: This is the markup of an Accordion which used to work, which doesn’t anymore. > On May 30, 2017, at 4:54 PM, Peter Entwrote: > > 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" 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
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"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
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"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
[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