Looks fine for me!
2013/12/3 Leonardo Uribe <[email protected]> > Hi > > I have been thinking about how to define the configuration for the view > pool. The idea is add the following new web config parameters: > > org.apache.myfaces.VIEW_POOL_ENABLED (enable / disable for all pages in > the app, by default false) > org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE (the number of views stored in > the pool per key) > org.apache.myfaces.VIEW_POOL_MAX_DYNAMIC_PARTIAL_LIMIT (the number of dyn > views that can be used as partial) > org.apache.myfaces.VIEW_POOL_ENTRY_MODE (weak, soft) > org.apache.myfaces.VIEW_POOL_DEFERRED_NAVIGATION (reuse views that are > navigated using default algorithm (increase reusal but it uses a hack that > does not follow jsf spec) ) > > And include this possible extension in faces-config.xml: > > <faces-config-extension> > <view-pool-mapping> > <url-pattern>/*</url-pattern> > <parameter> > <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name> > <value>5</value> > </parameter> > </view-pool-mapping> > </faces-config-extension> > > The idea is allow users to enable the view pool only for a part of the > application using <url-pattern> and override some specific view pool > parameters. The idea is there are parts of the application that are used > quite intensively and others that are not frequently visited. > > Suggestions are welcome. > > regards, > > Leonardo Uribe > > > > 2013/11/25 Martin Kočí <[email protected]> > >> Hi, >> >> +1 for this feature in core 2.2. >> >> Regards, >> >> Kocicak >> >> >> >> 2013/11/24 Thomas Andraschko <[email protected]> >> >>> 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 >>>>> >>>>> >>>>> >>>> >>> >> >
