Hi
Ouch, I forgot to answer this one.
In few words, the full algorithm is way too complex to explain.
Some extracts from _DeltaStateHelper (I wrote the description long time ago)
*Components implementing the PartalStateHolder interface have an initial
state and delta states, the initial state is the one holding all root
values and deltas store differences to the initial states.*
*The context from this class comes and that should be taken into account is
this:First request:- A new template is created (using
javax.faces.view.ViewDeclarationLanguage.buildView method)and
component.markInitialState is called from its related TagHandler classes
(see javax.faces.view.facelets.ComponentHandler ).- When this method is
executed, the component tree is populated from the values set in the
facelet abstract syntax tree (or in other words composition of facelets
templates).- From this point all updates on the variables are considered
"delta".- On saveState, if initialStateMarked is true, only delta is saved.
Second request (and next ones)- A new template is created and
component.markInitialState is called fromits related TagHandler classes
again. In this way, components like c:forEach or c:if, that add or remove
components could notify about this and handle them properly (see
javax.faces.view.StateManagementStrategy). Note that a component restored
using this method is no different as the same component at the first
request at the same time. - A call for restoreState is done, passing the
delta as object value. If no delta, the state is complete and no call is
triggered. - Lifecycle occur, changing the necessary stuff.- On saveState,
if initialStateMarked is true, only delta is saved.*
The pattern used in saveState is this:
@Override
public Object saveState(FacesContext facesContext)
{
if (initialStateMarked())
{
//Save delta
}
else
{
//Save full
}
}
restoreState is similar, but it does the check for fullState/delta using
the incoming object.
There are a couple of low level cases where you need to deal with
PartialStateHolder (handling properties with method expressions or attached
objects that implements PartialStateHolder), but those cases are not very
common for the average user.
regards,
Leonardo Uribe
2015-08-14 8:54 GMT-05:00 Kito Mann <kito.mann_at_virtua.com>:
> I agree. There are much bigger issues to tackle.
>
> ___
>
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
> http://www.JSFCentral.com | @jsfcentral
> +1 203-998-0403
>
> * Listen to the Enterprise Java Newscast: *http://
> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
> <http://ww.enterprisejavanews.com>*
> * JSFCentral Interviews Podcast:
> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
> * Sign up for the JSFCentral Newsletter:
> http://oi.vresp.com/?fid=ac048d0e17
>
> On Wed, Aug 12, 2015 at 1:23 PM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
>
>> Hi all,
>>
>> As I see the scope of JAVASERVERFACES_SPEC_PUBLIC-981 to be too broad and
>> I want to close it as "Won't fix".
>>
>> Ed, Leonardo, Cagatay, I specifically am asking you to weigh in on this.
>>
>> Thanks!
>>
>> Kind regards,
>> Manfred Riem
>>
>>
>