Hi,
Leonardo Uribe píše v Pá 03. 06. 2011 v 15:38 -0500:
Hi
2011/6/3 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
the idea seems very good - but when is decided that expression does not
uses some variable resolved by VariableResolver?
Inside VariableMapperWrapper.resolveVariable.
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
On Sun, Jun 5, 2011 at 9:35 AM, Martin Koci
martin.kocicak.k...@gmail.comwrote:
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
Ah, okay. Thanks for the explanation, Leonardo.
---
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
Hi
Checking this patch I founded one use case where the hack proposed could fail:
c:if test=#{somecondition}
c:set var=myvar value=somevalue/
/c:if
!-- code that use myvar --
I found it in this link:
http://seamframework.org/Documentation/CreatingACompositeAjaxifiedForm
In this case,
Hi,
the idea seems very good - but when is decided that expression does not
uses some variable resolved by VariableResolver?
TagAttributeImpl.getValue/MethodExpression methods are called in
VDL.buildView - how is the check done? String parsing? Yes, I didn't
look in the patch, its friday :)
Hi
2011/6/3 Martin Koci martin.kocicak.k...@gmail.com:
Hi,
the idea seems very good - but when is decided that expression does not
uses some variable resolved by VariableResolver?
Inside VariableMapperWrapper.resolveVariable. If it returns a not null
value, a variable has been resolved.
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:
Hi Kito
No, this will reduce the number of value/method expressions created
each request, but the calls to getters during request will be the
same.
In my understanding, some additional getter calls are triggered by
effect of ve.getType(). The only way to prevent that is define the
type
Hi,
as discussed here:
http://markmail.org/message/kca64ojdvb6em367?q=[core]+performance:
+TagAttributeImpl+part+II:+object+allocations#query:[core]%20performance
%3A%20TagAttributeImpl%20part%20II%3A%20object%20allocations+page:1
+mid:kca64ojdvb6em367+state:results
and here:
Hi Martin,
Good idea! +1 from my side.
Unfortunately, EL is one of the most expensive things in JSF and
wrapping Value-/MethodExpressions does not make it better!
I would really like to see some prototyping work for JSF 2.2 in this
area directly in a MyFaces core branch!
Regards,
Jakob
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
12 matches
Mail list logo
