Hi,

+1 for this feature in core 2.2.

Regards,

Kocicak


2013/11/24 Thomas Andraschko <andraschko.tho...@gmail.com>

> Perfect. Thanks for Info.
>
> So +1 from my side.
>
>
> 2013/11/24 Leonardo Uribe <lu4...@gmail.com>
>
>> Hi
>>
>> 2013/11/24 Thomas Andraschko <andraschko.tho...@gmail.com>
>>
>>> 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:
>>>
>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/component/collector/Collector.java
>>>
>>> http://code.google.com/p/primefaces/source/browse/primefaces/trunk/src/main/java/org/primefaces/behavior/base/AbstractBehavior.java
>>>
>>> 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
>> few.
>>
>>
>>> 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.
>>
>> regards,
>>
>> Leonardo Uribe
>>
>>
>>> Regards,
>>> Thomas
>>>
>>>
>>>
>>
>

Reply via email to