Hi Thomas What I can do is use an attribute to mark the view as poolable or not poolable.
The annotation code must be done outside core. regards, Leonardo 2013/12/7 Thomas Andraschko <[email protected]> > Leo, one question: > Is it possible to mark a view as "poolable" via code? > We configure all our views via typesafe view config from CODI/DS > > > > 2013/12/4 Thomas Andraschko <[email protected]> > >> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
