Also, ICE-5219 depends on this

Need to ascertain if View scope should be supporting comp. binding or not in JSF2.

Using basic-ajax2 example of jsf2.0 distribution (binary dist has several examples), I added component binding to class Echo for an HtmlInputText standard jsf component.
@ManagedBean(name = "echo")
@SessionScoped
public class Echo implements Serializable {

HtmlInputText inputTextBinding;
public HtmlInputText getInputTextBinding()

public void setInputTextBinding(HtmlInputText inputTextBinding)

....

and modify the following in echo1.xhtml:-
Output: <h:outputText id="out1" value="#

" binding="#

"/>

You can then see that jsf2.0 in Session scope allows component binding when a full form submit is done. If using <f:ajax> tag, I wasn't able to get the component binding to return the correct value. If using View scope, a different instance of the bean is used each time so no component binding is returned to the backing bean. (just keep getting a new one).

Similar results when modifying the input Text example of component-showcase.

Have to determine if
1) there is a bug in jsf2.0
2) should component-binding work in View Scope? or do we have to use Session scope for it?

Can always look up the component in the tree (using find method of the CoreComponentsUtil class)

I believe this is a bug in JSF 2.0.2. A bug has bee filed:

https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1492

In the meantime we should use findComponent()

Do we have a component JIRA for implementing this pagination behavior without a component binding or findComponent()?

Judy, please add a reference the new paginator JIRA.

For workaround, the datapaginator of the component-showcase example uses the CoreComponentsUtil method of find too look up the component in the tree to set it in the backing bean

DataPaginator demo in compat showcase needs to be updated to reflect "best practice" with respect to avoiding component binding.

Let's assume we have a state holder bean, in session or view scope. Now let's add a standard request scope bean, to hold our component binding, and act as a a controller. In the faces-config.xml, add the following:

<managed-bean>
<managed-bean-name>stateHolder</managed-bean-name>
<managed-bean-class>org.icefaces.StateHolder</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>

<managed-bean>
<managed-bean-name>controller</managed-bean-name>
<managed-bean-class>org.icefaces.Controller</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<property-name>stateHolder</property-name>
<value>#

</value>
</managed-property>
</managed-bean>

Now, the controller can use component bindings as well as regular ValueBindings to the display, and receive events. It doesn't matter that it can't hold state, since it has a reference to the session scoped bean, which simply holds long-term state.

Added a request scoped bean to hold the component binding, and to receive the ValueChangeEvent which made use of the component binding. Didn't need to tie the two beans together, since the new controller only needed static state from the model.

Subversion 21550
glimmer\compat\samples\component-showcase\src\org\icefaces\application\showcase\view\bean\examples\component\dataPaginator\DataScrollingController.java
glimmer\compat\samples\component-showcase\src\org\icefaces\application\showcase\view\bean\examples\component\dataPaginator\DataScrollingModel.java
glimmer\compat\samples\component-showcase\web\WEB-INF\includes\examples\custom\dataTable-dataScrolling.xhtml

This was the only component binding in compat component-showcase.

it doesn't work, the state holder bean is also reload when dataPaginator or another component with partiall submit is clicked

the state holder bean has view scope