Hi Leo, Hehe, yes, great idea!! I am wondering why we did not think of that in the first place...
However one question - why are you using the approach with one integer instead of three booleans? I know it's only a question about code style, but it kinda seems odd. Regards, Jakob 2010/10/20 Leonardo Uribe <[email protected]>: > Hi > > I have an idea: why don't evaluate that condition on construction time? > > In that case, EL will be scanned only once (when the Facelet or Abstract > Syntax Tree (AST) is build) and > not when the view is build, like is happening now. > > I have created an issue > > https://issues.apache.org/jira/browse/MYFACES-2951 > > and committed the code in trunk. > > Suggestions are welcome. > > Leonardo Uribe > > 2010/10/20 Jakob Korherr <[email protected]> >> >> Hi Kočičák, >> >> There might be some ways to improve this, but we have to be very >> careful in making changes to that area, because the whole composite >> components + EL domain is not that easy. >> >> Actually the CompositeComponentELUtils.isCompositeComponentXYZ methods >> were introduced by myself when fixing the #{cc} issues we encountered >> in some MyFaces 2 alpha versions. Unfortunately I currently don't >> really have time to think about improvements here, sorry. But I really >> think that there is some room for improvements! >> >> Also I really like your idea of isProcessingCompositeComponent. This >> might be a good way, because if this is false we can skip the #{cc} >> check, because such expressions will certainly not occur outside of a >> composite component. If you have some spare time, a patch would be >> really great :) :) - otherwise please just open a JIRA issue for this >> one so that we don't loose sight of it. Thanks! >> >> Regards, >> Jakob >> >> 2010/10/20 Werner Punz <[email protected]>: >> > Just my 2c without looking into the code, but I assume speed >> > improvements >> > already can be gained by replacing the pattern matches, if possible with >> > a >> > direct ll comparison. >> > Regexps often are heavier than simple parsing or string operations. >> > >> > Another thing might be that we add some caching mechanism on this level >> > which caches per request if possible. But I have not looked into the >> > code, >> > so I am making wild assumptions here. >> > >> > I assume also that some speed still can be gained in this area by better >> > utilization of the improved tree walking api jsf2 provides. >> > >> > >> > Werner >> > >> > >> > Am 20.10.10 15:54, schrieb Martin Koci: >> >> >> >> Hi, >> >> >> >> >> >> a issue to consider in >> >> org.apache.myfaces.view.facelets.tag.TagAttributeImpl: >> >> >> >> >> >> Methods >> >> TagAttributeImpl.getMethodExpression and >> >> TagAttributeImpl.getValueExpression use >> >> CompositeComponentELUtils.isCompositeComponentXYZ methods to detect if >> >> current #{} contains cc expression. But consider following: if user >> >> migrates from facelets 1.2 to 2.0, this new cc detection slows down >> >> build view process. In one my test case VDL.buildView calls >> >> CompositeComponentELUtils.isCompositeComponentXYZ approx 3000 times per >> >> build view with no match. isCompositeComponentXYZ is not cheap method >> >> because it uses Pattern.matches(). >> >> >> >> Are there possibilities to avoid this? For example is possible have >> >> some >> >> kind of "isProcessingCompositeComponent" method and skip >> >> Pattern.matches() if false? We are in VDL.buildView here and no >> >> components are available yet, no use of methods like >> >> UIComponent.isCompositeComponent(UIComponent) is possible. >> >> >> >> Any ideas? >> >> >> >> Regards, >> >> >> >> Kočičák >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> > >> > >> >> >> >> -- >> Jakob Korherr >> >> blog: http://www.jakobk.com >> twitter: http://twitter.com/jakobkorherr >> work: http://www.irian.at > > -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
