On 15 July 2011 22:30, Greg Brown <[email protected]> wrote: >>> I have actually started wondering about the overall usefulness of Accordion >>> given that most UIs seem to prefer multiple expander-like behavior. >> As just mentioned in my last email, I see a lot of similarity between the >> two. >> An Accordion is kind of a managed group of Expanders. >> Consolidating them might be an option. > > Possibly. I'd want to see what the consolidated component ("ExpanderGroup"?) > looked like. (I'll continue to use the ExpanderPane name for the rest of this email in an effort to make it a little clearer, but I am not opposed to another name)
I don't think you are being literal, but that is maybe the easiest way to start describing my current thoughts (based on about an hours worth of unstructured thinking). It would look much like an Accordion currently does (with its HeaderDataRender to tweak the looks), but have the selection flexibility described in my earlier mail that talked about SelectMode enums. If you wanted to display a single 'Expander' you would just create the 'ExpanderPane' and add a single 'panel', much the same as when working with a TabPane. (You can't create a Tab without a TabPane) If you wanted multiple 'Expanders' you would add multiple 'panels' to the 'ExpanderPane'. The 'panels' here would just be the root Component to show when the Expander was in an expanded state. Just as a TabPane creates the actual tab, a ExpanderPane might create an Expander internally that is capable of being collapsed independently of any other Expanders. (ie, leave the Expanders to manage themselves as far as possible) Actually, the multiple selection side of things might even be simplified by continuing the principle of grouping Buttons with a ButtonGroup. Expanders (panels) that share a ExpanderGroup would potentially cause other panels to expand or collapse as selection changes (depending on some properties of the ExpanderGroup). Panels that are not part of a ExpanderGroup, or are in a ExpanderGroup on their own, could be expanded/collapsed independently of any other panels. In general use, that would amount to adding all the panels to a ExpanderGroup to get the current Accordion behaviour (which might occur automatically, by default). Likewise, ensuring that no panels are grouped would provide my desired, fully flexible, completely independent panels. It would probably be enforced that there can only be a single ExpanderGroup per ExpanderPane (most likely owned by the ExpanderPane itself). I doubt there would be a use for multiple groups of panels within the same ExpanderGroup. That could be achieved by just stacking multiple ExpanderPane's together. >> I think SplitPane represents a well known UI staple, and shouldn't >> just be discarded, but agree that it is a but clunky to use. > > Maybe. I think the ability to resize panes is a requirement. An actual > "SplitPane" component may not be. Yeah, I think SplitPane is used now as it is the only supplied method of resizing, but might well be easily replaced with a simple Resizer. >>> A Resizer component (or "Sash") could potentially provide the resizing >>> capability, and these could be used within different layout containers >>> (primarily BoxPane and TablePane, I would imagine) to create various >>> configurable layouts. >> Once it becomes established, SplitPane could probably be retired. > > Right - that is what I was thinking. I'd have no problems with that course of action. Create the Resizer Container, promote its use over SplitPane in demos, 'deprecate', wait a release or so, and then remove. It could optionally be retired earlier if the code was just pushed to an ApacheExtras project (or similar) and labeled as no longer supported. Chris
