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
>>>>
>>>>
>>>>
>>>
>>
>
