Accordioning views in Flex Repeater

I am trying to make a page which shows multiple instances of a view stacked on top of each other, and able to dynamically accordion each instance when clicked. Because the number of instances depends on user input, a Flex Repeater with a bound instances property seems like a natural fit. But I’m finding that I can’t control the size each instance takes up in the parent view.

The view in the repeater has a header and a body; when you click the header, you toggle the display of the body. I would expect that when the body of the first instance disappears, the second instance would move up the screen and be directly below the first instance’s header. Here’s a picture of how I was able to get it to look in ASP.NET, using bootstrap components and javascript.

Capture

Instead, the second instance stays right where it is, with the undisplayed portion of the first instance taking up the space it would have if it were being displayed.

Capture

I found a post on the forum ([Question] Collapsing and Expanding views in perspective) about manually coding the accordioning behavior by modifying a view’s basis when part of it is hidden, but that solution doesn’t appear to be available to the Flex Repeater. Even if I give each instance its own basis property, I can’t bind that to the basis of the instance so it updates when it changes. Or at least I don’t see a way to do so.

Is there a simpler way to get the effect I’m going for here? And if not, is there some way that I can make instances inside a Flex Repeater dynamically update their basis based on the properties of the view they contain?

A co-worker and I just spent a little more time on this, and found the solution: I had to set the Flex Repeater’s useDefaultViewHeight property to true, and set the height property of the collapsible element to “auto”.

I’ve come across this a couple of times, where properties like basis or height are documented as taking an integer, and the designer gives you a warning if you use a string instead of the expected integer, but it works perfectly well with the right string, like “auto”. Am I missing the place where these cases are documented?

1 Like

No, it’s just a known (low-priority) bug on our side that they’re designated as strictly numeric, when other properties (such as auto) clearly work. For now, safe to ignore, and expect those warnings to disappear in some future version once we fix the pattern matching.

1 Like