Perfect. Thanks for Info. So +1 from my side.
2013/11/24 Leonardo Uribe <[email protected]> > Hi > > 2013/11/24 Thomas Andraschko <[email protected]> > >> 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 >> >> >> >
