Hi
KM>> This is very similar to JAVASERVERFACES_SPEC_PUBLIC-1184
KM>> (Support using JSON for component updates instead of XML).
KM>> The idea there is that only the changed attributes would be sent,
KM>> and the updates would be applied via JavaScript instead of DOM
KM>> replacement. That's a separate topic, though.
Ok, we can discuss it later. I just wanted to note, that it could be useful
to provide a way to detect which attributes are bound to EL expressions,
or which attributes were changed and use that fact to improve JSF. Maybe
we should focus our efforts into that.
MR>> I would like to go ahead and close this issue as a "Won't fix" as there is
MR>> a better way of addressing this without any specification changes.
+1.
MR>> Thoughts?
I think there are some changes we can do about in some EL resolvers.
One that comes to my mind is the one that handles #{cc.attrs....}. Section
5.6.2.2. there is a part when you need to return a Map, and that map
is resolved by MapELResolver, but that is not a good idea, because
this resolver is the last of the EL Resolver chain. It is also necessary to
call FacesContext.getCurrentInstance() internally to evaluate the
target EL expressions. It would be better if this is still a map, but we force
that another EL Resolver (it could be the same) handles this object
(using a class cast that check if the object implements some
interface). In that way, we can pass the FacesContext instance to a
custom method that receives FacesContext as parameter, instead
use Map.get().
That simple change would increase performance of composite
components, improving the speed of the EL evaluation. We can't do
that without a change in the spec.
regards,
Leonardo
2015-01-22 12:33 GMT-05:00 manfred riem <manfred.riem_at_oracle.com>:
> Hi all,
>
> I would like to go ahead and close this issue as a "Won't fix" as there is
> a better way of addressing this without any specification changes.
>
> Thoughts?
> Manfred
>
> On 1/21/15, 9:19 PM, Leonardo Uribe wrote:
>>
>> Hi
>>
>> MR>> I think caching the ELExpression becomes well uncessary. Hence no
>> real action need from a spec perspective.
>>
>> I agree cache the values from the EL Expressions is not effective from
>> performance perspective. The problem is it is quite hard to decide
>> when the value can be reused or not. In the case of isRendered() you
>> can take advantage of the fact that most of the calls are done in
>> encodeXXX methods, but besides that you cannot do much besides
>> optimize the EL Resolver chain. In MyFaces there are a couple of
>> tricks for that.