Hi
Checking this patch I founded one use case where the hack proposed could fail:
I found it in this link:
http://seamframework.org/Documentation/CreatingACompositeAjaxifiedForm
In this case, things could be rewritten to this:
I think in this case the second syntax is better, so we
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 t
On Sun, Jun 5, 2011 at 9:35 AM, Martin Koci
wrote:
> 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 is
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. 2
Hi,
Leonardo Uribe píše v Pá 03. 06. 2011 v 15:38 -0500:
> Hi
>
> 2011/6/3 Martin Koci :
> > 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
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 beforehand
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:
jsf
Hi
2011/6/3 Martin Koci :
> 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.
> TagAttributeImpl.getValue/M
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 :)
Anot
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
expressi
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
2011/6/
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:
http://markmail.org
12 matches
Mail list logo
