[Myfaces Wiki] Update of "Component Bindings" by WernerPunz

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The following page has been changed by WernerPunz:
http://wiki.apache.org/myfaces/Component_Bindings

New page:
=Component Bindings=
== Introduction ==
While the best pratice is to have a single page controller under conversation per page or for a full multi page flow, there is a discrepancy between the scope length needed for the conversation and the scope length for associated component bindings.

==Problem==
The main problem is, component bindings in a backend bean require a scope lenth of request. The cause is that the component tree is regenerated at every request. Longer component bindings are a possible cause for internal id clashes etc...

The main problems we now face are, we have a single page controller/model object which is associated to the view. The page controller/model now is stateful, which is exactly as inded, however we need component bindings in this bean and those are referenced by the view. The bindings under normal circumstances inherit exactly the scope of the page controller.

Therefore following construct automatically is bound to fail:
{{{
<component binding="#{viewcontrollerbean.bindingattribute}" />					
}}}				

The problem here is that the viewcontroller bean has a scope of conversation, the bindingattribute, however, needs a scope of request. This at the first look is a problem impossible to solve. At the second look, Spring itself provides the solution. Since every bean referenced by the framework and the view layer is a Spring bean, we get the solution out of the magical Spring box.

==Solution==
Spring in 2.0 has introduced a construct called aop-proxy. This is a special tag which can be embedded into beans which basically does nothing more than to weave a proxy object around an existing object which inherits the scope of the referencing bean. The inner part of the proxy or own bean then can have a scope of its own which can be smaller than the scope of the referencing object.

So how does this help: Lets look again at our example

<component binding="#{viewcontrollerbean.componentbindingmodel.bindingattribute}" />					
				

The accessor path has slightly changed, we have introduced a second bean a model bean which holds our component bindings.

What happens on the spring configuration side is simply following:

{{{
<bean id="componentbindingmodel" scope="request" class="path.to.our.model.class">
   <aop:scoped-proxy />
</bean>

<bean id="viewcontrollerbean" scope="conversation" ...>
      <property name="componentbindingmodel"
            ref="componentbindingmodel" />

</bean>
}}}				

The associated component binding model class is simply a class which holds the components as attributes and its associated setter and getter methods.

What happens at call stage: The viewcontrollerbean is instantiated under conversation scope, the proxy object is generated and assigned dependin on its lazy binding stage. At the request end, the content of the componentbindingmodel bean is dropped and only the empty proxy shell still is referenced. At the next request which references parts of the componentbindingmodel object the content again is initialized and can be accessed. This way it is possible to bind the request scoped component bindings to any long running scope no matter being it our conversation scopes or session scopes!