Verify feature gap between new deliteful containers and their dijit counterparts

[pruzand]

We need to be sure we don't drop features that were available in 1.x when switching to deliteful. Or at least, that the features that are dropped, if any, were the results of a decision or expected. @dmandrioli could you make a comparaison of the new deliteful containers capabilities vs their dijit counterparts ? (ex: LinearLayout vs BorderContainer, ViewStack vs StackContainer?)

[dmandrioli]

StackContainer / ViewStack http://dojotoolkit.org/reference-guide/1.9/dijit/layout/StackContainer.html

1. StackContainer children have properties related to the container: selected, disable, closable, iconClass, showTitle. ViewStack only controls size (100%) and visibility of its children.
2. StackContainer supports persistance of the selected child across session.
3. StackContainer can take the size of its children (doLayout = false). ViewStack must be sized then children take 100%.
4. Existence of StackController component to control the StackContainer.

[dmandrioli]

TabContainer (use internal TabController, ScrollingTabController and TabButton) http://dojotoolkit.org/reference-guide/1.9/dijit/layout/TabContainer.html

1. Basically a StackContainer with Tab Buttons.
2. Manage the "too many tabs" case with useMenu and useSlider.
3. Closable tabs feature

[dmandrioli]

LayoutContainer https://dojotoolkit.org/reference-guide/1.9/dijit/layout/LayoutContainer.html

1. Nesting LinearLayouts seems to cover features of LayoutContainer.

BorderContainer (LayoutContainer + splitters) https://dojotoolkit.org/reference-guide/1.9/dijit/layout/BorderContainer.html

1. Nothing equivalent in deliteful for now.

ContentPane http://livedocs.dojotoolkit.org/dijit/layout/ContentPane

1. Like for dojox.mobile.View: seems useless for now.

[dmandrioli]

AccordionContainer https://dojotoolkit.org/reference-guide/1.9/dijit/layout/AccordionContainer.html

1. Nothing equivalent in deliteful for now.

[wkeese]

I want to emphasize two main gaps from StackContainer and TabContainer:

1. Synchronization between the controller and the main container: When the app adds/deletes/changes the label or icon of a TabContainer/StackContainer pane, all the controller widgets are automatically updated. The controllers also automatically get the initial list of children in the StackContainer/TabContainer. Contrast this with dojox/mobile/TabBar, where the app must manually set the TabBar buttons to match the ViewStack's children.
2. Resizing: all dijit layout widgets have a resize() method that trickles down to it's children. This is covered in ibm-js/deliteful#22. Speaking of which, I'm not sure why you wrote this comment above:

StackContainer can take the size of its children (doLayout = false). ViewStack must be sized then children take 100%.

I was assuming that the app didn't need to specify a size on the ViewStack, and that ViewStack's children could all be different sizes. I guess not?

Another thing is that (by design) ViewStack does not handle user interaction, i.e. swiping to move between panes. So we'll need to implement that eventually. Contrast with SwapView + PageIndicator from dojox/mobile (or Carousel embeds both).

[wkeese]

About ContentPane: ViewStack (well actually, DisplayContainer) emits events when displaying a child, allowing a framework to load that child. But there's no built-in code to do an XHR and get the data, plus display a "Loading..." type message while the XHR is in progress.

Maybe that code should be somewhere, either a ContentPane widget or part of the parent widget. I'm not sure. In any case, this a gap compared to dijit/dojox.mobile where you could just say <div dojoType=dijit/layout/ContentPane href=...>.

[wkeese]

About Accordion: presumably we need one. A few issues to consider when implementing are:

1. Should it be a fixed height like in dijit's AccordionContainer, where only one pane is open at a time, or more like dojox/widget/TitleGroup where the height matches to whatever pane is being shown, and you can optionally open multiple panes at once?
2. Should you be able to easily add/remove children (like in dijit), and the accordion automatically creates the corresponding title bar? I.E. basically the same as dijit/layout/TabContainer works.

[cjolif]

From off line discussions:

• persistence across session is low priority, probably more for dapp
• splitters are low priority (probably left for another release)
• the way we will design tab containers (either tab container or view stack + tab bar) should be similar for swapable view (i.e. swap container or view stack + page indicator), not sure yet what the best design will be
• sizing issue still to be answered
• content pane (i.e. loading of child) medium/high priority, dapp deals with this but we probably need something for delite(ful) as well, not top priority we have other things to deal with first.
• we need an accordion container

[sbrunot]

About the accordion container: it might (should ?) be possible to implement it using the List widget (categorized list, with a category renderer that displays / hide its content when clicked / actioned).

[cjolif]

I think investigation side is done here.