myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leonardo Uribe <lu4...@gmail.com>
Subject Re: [core][discuss][proposal] Include View Pooling into MyFaces 2.2.x
Date Sat, 07 Dec 2013 19:07:14 GMT
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 <andraschko.thomas@gmail.com>

> 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 <andraschko.thomas@gmail.com>
>
>> Looks fine for me!
>>
>>
>> 2013/12/3 Leonardo Uribe <lu4242@gmail.com>
>>
>>> 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čí <martin.kocicak.koci@gmail.com>
>>>
>>>> Hi,
>>>>
>>>> +1 for this feature in core 2.2.
>>>>
>>>> Regards,
>>>>
>>>> Kocicak
>>>>
>>>>
>>>>
>>>> 2013/11/24 Thomas Andraschko <andraschko.thomas@gmail.com>
>>>>
>>>>> Perfect. Thanks for Info.
>>>>>
>>>>> So +1 from my side.
>>>>>
>>>>>
>>>>> 2013/11/24 Leonardo Uribe <lu4242@gmail.com>
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> 2013/11/24 Thomas Andraschko <andraschko.thomas@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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message