I suppose it could go the other way too. Create ExpanderGroup as an equivalent of a ButtonGroup, and just use that to manage 0 or more Expanders. If you want an Accordion like effect, you would stack multiple Expanders together and add them to the same ExpanderGroup.
That would be far simpler. The only thing I can think of that would be needed with this approach is some sort of HeaderDataRender mechanism to allow the header of an Expander to be rendered as the user desires. On 15 July 2011 23:15, Chris Bartlett <[email protected]> wrote: > 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 >
