Hi all,
I have closed this as "Won't fix". Any other optimizations that could be
done should be discussed in a separate relevant issue to make followup
easier.
Thanks!
Manfred
On 1/26/15, 9:24 AM, Kito Mann wrote:
>
>
>
> 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.
>
>
> +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.
>
>
> +1 Definitely sounds like a good idea.
>
>
> regards,
>
> Leonardo
>
>
> 2015-01-22 12:33 GMT-05:00 manfred riem <manfred.riem_at_oracle.com
> <mailto: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.
>
>