r4260: committed fix to allow updating the active index programmatically.

Since the hidden input that contains the active index has its own client id, it was being updated by itself without reinitializing the component. However, a dynamic script was added to only set the new tab index in the jQuery widget, in order to avoid re-creating the entire component.

Tested with ICEfaces 4 r42615, Tomcat 7 and all browsers.
Using Chrome and IE 11, the accordion does get opened after selecting a demo from the search field but not on the first attempt. Second and subsequent attempts will go to the proper accordion panel. The first attempt leaves the ACE Overview accordion panel selected. Occasionally FF will open the relevant panel the first time through.

Verified resolved ICEfaces 4 trunk r42629. Tomcat 7 , FF 31, Chrome 37, IE 11.

Re-opening as the original fix was backed out to resolve ICE-10266.

I found out the reason why a request was being made when updating the active index in the accordion component. In the jQuery UI code, changing the active index programmatically also triggers the 'accordionchangestart' event, which is the one we use to attach our own event handler to make a request to the server after clicking on an accordion pane. So the solution for ICE-10261 would consist in finding a way to expand the corresponding accordion pane, without triggering any event.

Committed new fix at revision 42643. The fix consists in modifying the jQuery UI code to add an 'activeNoEvent' option to the Accordion widget to allow activating an accordion pane without triggering the 'changestart' event (which caused sending an additional request) and without focusing on the pane header (which caused the page to scroll down).

Rev. 42651/ testing in FF31, Chrome37, IE10
showcase > Overview demo does not work properly in FF31/Chrome37 (tabs cannot be opened up after collapsing the accordion panes).

Steps:
Initially when coming to this demo, all tab panes are closed.

• click Tab1 to open it -> Tab1 opened.
• click Tab1 to close it -> Tab1 closed, but Tab3 opens up.
• click Tab3 to close it -> Tab3 closed.
• all tabs are closed now; from now on, when clicking on any tab pane, they open up but then immediately close back.
  This is not an issue in IE10.

r42654: fix to avoid processing setActiveIndex(), when the index is the same as the state holder, in order to avoid closing tabs in collapsible accordions; fix to convert an active index of '-1' to 'false' in the client side, since that's how the jQuery Accordion widget understands that all panels should be collapsed.

R. 42654:
ace:accordion > Overview: if checking a checkbox in Tab1, and then closing Tab1, none of the panes can be re-opened; this occurs in all browsers (tested in IE10,11; FF31, Chrome37), however in Chrome I did not always reproduce this issue.

r42656: fix to consult the active index from the internal state of the jQuery UI Accordion widget object when determining whether to process setActiveIndex() or not.

r42659: Committed various fixes to support all use cases. This also solves the issue reported in ICE-10266 with the CSS source accordions in 'required styling' demos.

R. 42661/ IE10, IE11, Chrome37, FF31: re-tested showcase > accordion demos, and no issues have been found.
Also, the CSS Source view issue is resolved.

r42670: Committed code that was meant to be committed previously. The last reported issue is now fixed.

ICEfaces 4 trunk r42671
Tomcat 7, all browsers.
Reopening because the QA accordion in ui:Repeat inside h:dataTable test is now failing. When selecting an inactive pane, the matching panes in the ui:repeat also become selected.
This issue does not occur when accordion is alone inside ui:repeat, or h:dataTable or ace:dataTable.
To reproduce:
Use test app located at http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion.
Navigate to Accordion in Repeat and Data table test.
In the first row, select an inactive pane.
Note that all matching panes in the same row become activated.

The problem is with the test page/app itself. It just wasn't visible before, because before this fix there was no script to expand the active index dynamically, but all the hidden input fields, holding the active index for each accordion, were being updated. There was just no visible clue that there was something wrong with the app. Another way to see it, is to replace the accordion component on the test page (accordionRepeatDataTbl.xhtml) for an ace:tabSet, as in the following markup:

<ace:tabSet id="accordion" clientSide="false" selectedIndex="#{accordion.activeIndex}">
	<ace:tabPane id="cPane" label="Calgary">
		<h:outputText id="outputTxt1" value="Calgary content"/>
	</ace:tabPane>
	<ace:tabPane id="vPane" label="Vancouver">
		<h:outputText id="outputTxt2" value="Vancouver content"/>
	</ace:tabPane>
	<ace:tabPane id="tPane" label="Toronto">
		<h:outputText id="outputTxt3" value="Toronto content"/>
	</ace:tabPane>
	<ace:ajax event="serverSideTabChange" />
</ace:tabSet>

The issue with the test page is also visible when using an ace:tabSet. The problem is that the activeIndex/selectedIndex is being bound to the 'accordion' variable, which is the variable declared in the outer h:dataTable, and not the variable declared in the inner ui:repeat. There's not even a variable declared in ui:repeat. So, all accordions inside ui:repeat are bound to the same outer variable, so when an active index is modified, all accordions bound to that property also have to update their active indexes. Also, the data collection is exactly the same for the h:dataTable and for the ui:repeat (accordionRepeatDataTblBean.accordions), which doesn't make much sense to me, but I'm not sure what was the original purpose of this test page. What I'm used to see with nested iterative containers is that there's a data object for for the outer container and a different data object for the inner container, each with their own variables. A similar test in the ace:tabSet test app follows this pattern. Please review this test page/app and make the necessary changes for it to work normally.

The QA test application has been updated as required and committed to http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/accordion r39540. No issues are present.