Hi, what problem is it? I know about excessive "rendered" evaluation: JAVASERVERFACES_SPEC_PUBLIC-941. "value" at EditableValueHolder can be evaluated 2x during one request/response.
If it is another problem, can you create a jira issue, please? Thanks, Kočičák Kito Mann píše v Pá 03. 06. 2011 v 17:58 -0400: > Leonardo, would this reduce the number of calls to getters during > request processing? > --- > Kito D. Mann | twitter: kito99 | Author, JSF in Action > Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and > consulting > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | > twitter: jsfcentral > +1 203-404-4848 x3 > > * Listen to the latest headlines in the JSF and Java EE > newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF > +and+Java+EE+Newscast > * See you at JAX and JSF Summit 2011 June 20-23rd in San > Jose: http://jaxconf.com/ > > > On Thu, Jun 2, 2011 at 10:10 PM, Leonardo Uribe <[email protected]> > wrote: > Hi > > I have attached another patch to MYFACES-3160. This one has > the > ability to detect if the expression uses some variable > resolved by > facelets VariableMapper wrappers and if so, indicate the > expression > cannot be cached. > > This solution will work better, because it only creates > Value/Method > expressions when it is necessary. This is a great > optimization, > because in practice most expressions are bound to managed > beans, so in > practice it will make pages render faster (because EL parsing > is only > done once and a lot of objects will not be created) and the > memory > usage will be lower (less instances means gc works less). > > The only part this does not have any effect is when there is a > ValueExpression directly on the markup. In this case, I think > since > org.apache.myfaces.view.facelets.compiler.UIInstructionHandler > is > final (that means it is inmutable), put a volatile variable > for cache > such cases will make it a mutable class, so it cannot take > advantage > of some compiler optimizations. Maybe we can create two > classes, one > to handle markup without EL and other with EL. Anyway, the > most > critical point is expressions on attributes (changes on > facelets > compiler has to be done very carefully). > > JK> I would really like to see some prototyping work for JSF > 2.2 in this > JK> area directly in a MyFaces core branch! > > The patch proposed on MYFACES-3160 is for MyFaces 2.0 and 2.1. > After > the latest patch I think we don't really need some work on a > EL > implementation (see explanations below). > > MK>> > MK>> we need to avoid unnecessary ValueExpression instances. > > Yes, sure!. I know this optimization will be very useful, and > it will > do better use of available resource (memory and cpu). > > MK>> > MK>> Here is one idea: because we cannot wait for JCP (or I > don't want to), > MK>> prototype some improvements in sandbox, for example: > MK>> > MK>> 1) we can create MyFacesExpressionFactory with methods > MK>> createTagValueExpression, createLocationValueExpression, > MK>> createResourceLocationValueExpression .... > MK>> > > The problem here is the hacks required to make #{cc} and > resource > "this" are too myfaces specific, and are too coupled to > myfaces impl. > > MK>> 2) In myfaces-core-impl then create default > implementation with same > MK>> code as > TagAttributeImpl.getValueExpression(FaceletContext, Class) has > MK>> currently. > MK>> > > It could be good to have a factory pattern applied to that > part. > > MK>> 3) create new module myfaces-integration with additional > implementations > MK>> of MyFacesExpressionFactory. For example > JUELOWBMyFacesExpressionFactory > MK>> - create* methods of such implementation will create not > wrapped > MK>> expression but one instance of JUELCODIValueExpression. > MK>> JUELCODIValueExpression will use inheritance from JUEL > internal API (and > MK>> some code from OWB). > MK>> > MK>> Of course it will need cooperation with JUEL/OWB > developers (for example > MK>> because de.odysseus.el.TreeValueExpression from JUEL is > final class). > MK>> Solution with inheritance is proposal only, I didn't try > it yet. User > MK>> must be sure that no other library wants to wrap > ValueExpression. > MK>> > > In my mind this only works as a "last resource". > VariableMapper usage > is only a concern inside facelets, because its usage is bound > to the > context the expression is created. > > Anyway, I would like to know first if it is really necessary > to create > such factories. We need concrete use cases that support that. > For now, > I'll be happy with the solution proposed. It still requires a > deep > review (because the code affected is very critical) and some > junit > tests, so it will take some time before finish it. > > regards, > > Leonardo Uribe >
