myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Sun, 24 Nov 2013 19:56:29 GMT

2013/11/24 Thomas Andraschko <>

> Hi Leo,
> By default all the code in UIComponentBase is already in place, so if all
>> components extend from UIComponentBase everything will work just fine
> cool, perfect!
> What about Behaviors or ActionListeners like:
> Will they work correctly?

Yes, because the related variables are stored into the state, so if they
change, saveState(...) will return non null and in the worst case the
component will be replaced with a new one.

The ideal is the attached objects (Collector) implements PartialStateHolder
instead StateHolder. The reason is the hack involves save the state when
markInitialState(...) was called and when a hard reset is done, reuse that
information and restore the state of the component or attached object like
it was when the view was built by first time. But if that is not done, the
algorithm just replace the component with a new one and problem solved.

The tricky part are those variables that are not part of the state buy
plays some role, because there is no way to know they are there. For
example the dataModelMap in UIData, but the examples out there are very

> All other components in PrimeFaces just use the StateHelper. So it should
> be fine.
If saveState(...) is overriden, there is a chance that some additional
lines are required.

Note we still have a lot of work to do, but the evidence we have suggest we
should at least give another try and see what happens.


Leonardo Uribe

> Regards,
> Thomas

View raw message