scrollable attribute is on this component (for now) and may be removed if deemed unecessary, however in order for the inner panel to be scrollable, may require some styling on this component so left it in for now.
Also, for now it extends UIPanel, but may be changed to UIComponent if no requirement to be a panel.
just has a div for the "mobi-panel-stack" base class, but Patrick can decide if he wants that there as he may want to do his styling outside of this component.

http://wiki.icesoft.com/display/mobile/Manipulating+Content+within+various+mobile+components

is the link with the latest approach to this component in regards to containerLayout, accordion and tabSet

this component is waiting for tagHandler. I have renamed the accordionTitle to just "title" for use with tablet as well and will check this in when I have tabSet working.

Will use a custom TagHandler to optimise the construction of the contentPane such that if the contentPane children won't be rendered, then they won't be constructed either. The TagHandler will decide that given:

pane.getCacheType().equals("tobeconstructed") && ((ContentPaneController)parent).getSelectedId().equals(pane.getId())

ACE will need to be augmented to added support for specifying the custom TagHandler on the @Component annotation, and making that take precedence over any generated TagHandler.

ContentPaneController.getSelectedId() can't access the ContentPane components, since it's called while the ContentPane is being constructed.

In the ContentPaneHandler, onComponentCreated is called on GET and POST restore view, but not POST render. In applyNextHandler, on GET and POST restore view, c.parent is null, but in POST render c.parent is non-null. So for POST render, check if should skip in applyNextHandler, using the non-null parent as the switch.

Works with ContentStack, but when testing with Accordion and TabSet, when changing current contentPane, since they use @PostConstruct, selectedId is null on restore view construction, so doesn't break but not optimised.

Made the ContentPaneHandler work when contentPane is in a contentStack parent. Tested with a c:forEach of contentPane(s) and also tested with the whole contentStack within an h:dataTable although can't use the dataTable var to drive the relevant properties of course since everything needs to be available in construction.

Subversion 29233

Changed Accordion and TabSet to use currentId instead of their indexing for determining the selected pane/tab.

Subversion 29270

Made TabSet only set currentId in decode, removing the redundant call in broadcast. Added more tests.

Subversion 29280

Accordion:- javascript wasn't allowing for removal of contentPane by application using c: forEach, so fixed that and cleaned up the test pages a bit for accordion. Now works in all current tests as of rev 29284

Request that attributes for the cacheType be modified to add:-

facelet = "true" ....means to use the tag handler to NOT add the children of the contentPane to the server component tree. Default will be false.
clientSide= "true" ....meaning that facelet attribute MUST be false and the contentPane is always rendered on the client.
clientSide="false" ...meaning that if the facelet attribute is true, the handler will determine whether the children are added to the component server tree (if "selected" then the children are added) and the Renderer will only render the children of the selected contentPane.

client="true/false" should be sufficient.

client="true" causes the faclet attribute to effectively be ignored. If this is difficult to implement, then it can just be an error to use client="true" facelet="true".

I have made the changes locally and in the tag handler, I read the 2 TagAttributes "client" and "facelet" and do the following:-
boolean overridden = false;
if (client != null && client.getValue(ctx).trim()=="true")

// System.out.println(" remove key");
if (facelet == null || facelet.getValue(ctx).trim()!="true" || overridden==true)

//System.out.println(" cacheType is tobeconstructed");
if (!(parent instanceof ContentPaneController))

//System.out.println(" parent is ContentPaneController");
String selectedId = ((ContentPaneController)parent).getSelectedId();
if (selectedId == null || selectedId.length() == 0)

//System.out.println(" selectedId is set");
if (selectedId.equals(c.getId()))

// System.out.println(" selectedId not equal to id => SKIP");
return true;
}

///
in this way, if client is true, then facelet (tobeconstructed) is disregarded as it is overridden by the other attribute. I can't leave it in the renderer to resolve, so had to place it all here.
Am testing now, but it appears that this does work. Any gotchas I need to watch for?

You can just call getBoolean(ctx) on client and facelet, since they're boolean properties now.

I was thinking that maybe ContentPaneMeta should be changed to make the @Property annotations for cache and facelet to have an Implementation of Implementation.EXISTS_IN_SUPERCLASS so that no getter or setter will be made in the component itself, since the component properties aren't used and the tag attributes are used directly, instead.

the client attribute is used in the Renderer. If you have facelet="false", then client makes a difference on whether the children are rendered or not --if client="true", they are always rendered on client, if client="false" then, the children are only rendered when the pane is selected.
I can see doing this with the facelet attribute though as the Renderer doesn't care about this one at all. I can put that in if you like (since I am working on it now).

Ok then we should let it generate all the code for isClient() and setClient(), but then override the methods in ContentPane so make them not use the clientId and not try to set or get it per row. Just copy and paste the generated methods in, and strip out the row related stuff.

this component was completed for 1.1 Beta release. Any further work should be done on new jira