You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sam Witty <sa...@yahoo.com> on 2009/06/26 03:36:28 UTC

Caching the result of an EL expression evaluation with in a life cycle

If you have the following code:

<h:h:outputText>#{someBean.user.firstName}></h:outputText>
<h:h:outputText>#{someBean.user.lastName}></h:outputText>
<h:h:outputText>#{someBean.user.age}"></h:outputText>

and if SomeBean.user() is a call to the db then every one of the above
expressions will cause a trip to the db. Of course to get around this one
simply has to cache the value of user from the db (the first time) and then
return the cached value instead of going to the db again. 

This is all well and good... however, I find myself writing a lot of this
type of caching code in various places. It would seem that a much elegant
solution would be to have the EL expression evaluator cache the result of an
expression within a life cycle avoiding the need for every JSF developer to
sprinkle caching code all over the place.

Then again there maybe something out there that does this already (magical
config param?) I just could not find anything.

Thanks
-Sam
-- 
View this message in context: http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.


Re: Caching the result of an EL expression evaluation with in a life cycle

Posted by Sam Witty <sa...@yahoo.com>.

Yes I absolutely agree, it has to be configurable in some way. It just seems
like such a common issue that I was hoping there was a general solution. 

The ELResolver route will certainly work, though as you pointed out it will
have to be some sort of annotation which will look and feel "hacky", but I
think it would still be better then constantly writing "micro" caches
everywhere.

Thanks
-Sam


Manfred Geiler-2 wrote:
> 
> A standard EL expression evaluator cannot and MUST never cache results.
> Imagine the following expression:
> <h:outputText>#{someBean.nextCounterValue}></h:outputText>
> The app developer would not be very happy if EL caches that result, right?
> 
> So caching can only be a matter for the model.
> OR: you write your own custom ELResolver that somehow "knows" which
> values to cache and which it should not cache. Perhaps by inspecting
> the annotations of your getters? I could imagine a custom @Cacheable
> annotation for that purpose.
> 
> However, there is no magic config param. Sorry.
> 
> --Manfred
> 
> 
> 
> On Fri, Jun 26, 2009 at 03:36, Sam Witty<sa...@yahoo.com> wrote:
>>
>> If you have the following code:
>>
>> <h:h:outputText>#{someBean.user.firstName}></h:outputText>
>> <h:h:outputText>#{someBean.user.lastName}></h:outputText>
>> <h:h:outputText>#{someBean.user.age}"></h:outputText>
>>
>> and if SomeBean.user() is a call to the db then every one of the above
>> expressions will cause a trip to the db. Of course to get around this one
>> simply has to cache the value of user from the db (the first time) and
>> then
>> return the cached value instead of going to the db again.
>>
>> This is all well and good... however, I find myself writing a lot of this
>> type of caching code in various places. It would seem that a much elegant
>> solution would be to have the EL expression evaluator cache the result of
>> an
>> expression within a life cycle avoiding the need for every JSF developer
>> to
>> sprinkle caching code all over the place.
>>
>> Then again there maybe something out there that does this already
>> (magical
>> config param?) I just could not find anything.
>>
>> Thanks
>> -Sam
>> --
>> View this message in context:
>> http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
>> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24223523.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.


Re: Caching the result of an EL expression evaluation with in a life cycle

Posted by Manfred Geiler <ma...@apache.org>.
A standard EL expression evaluator cannot and MUST never cache results.
Imagine the following expression:
<h:outputText>#{someBean.nextCounterValue}></h:outputText>
The app developer would not be very happy if EL caches that result, right?

So caching can only be a matter for the model.
OR: you write your own custom ELResolver that somehow "knows" which
values to cache and which it should not cache. Perhaps by inspecting
the annotations of your getters? I could imagine a custom @Cacheable
annotation for that purpose.

However, there is no magic config param. Sorry.

--Manfred



On Fri, Jun 26, 2009 at 03:36, Sam Witty<sa...@yahoo.com> wrote:
>
> If you have the following code:
>
> <h:h:outputText>#{someBean.user.firstName}></h:outputText>
> <h:h:outputText>#{someBean.user.lastName}></h:outputText>
> <h:h:outputText>#{someBean.user.age}"></h:outputText>
>
> and if SomeBean.user() is a call to the db then every one of the above
> expressions will cause a trip to the db. Of course to get around this one
> simply has to cache the value of user from the db (the first time) and then
> return the cached value instead of going to the db again.
>
> This is all well and good... however, I find myself writing a lot of this
> type of caching code in various places. It would seem that a much elegant
> solution would be to have the EL expression evaluator cache the result of an
> expression within a life cycle avoiding the need for every JSF developer to
> sprinkle caching code all over the place.
>
> Then again there maybe something out there that does this already (magical
> config param?) I just could not find anything.
>
> Thanks
> -Sam
> --
> View this message in context: http://www.nabble.com/Caching-the-result-of-an-EL-expression-evaluation-with-in-a-life-cycle-tp24213650p24213650.html
> Sent from the My Faces - Dev mailing list archive at Nabble.com.
>
>