Are JIRA 1668 and JIRA 1700 dupes?
Maria
-Original Message-
From: Blake Sullivan
Sent: Tuesday, January 19, 2010 12:09 PM
To: MyFaces Development
Subject: Re: [TRINIDAD][API]TRINIDAD-1668 Speed up UIXComponent.getId()
The api part of the fix is that UIXFacesBeanImpl
The api part of the fix is that UIXFacesBeanImpl and
UIXEditableFacesBeanImpl have been moved to
org.apache.myfaces.trinidad.component. There is nothing interesting
about these classes and it was kind of rude that they were present only
in impl, since everyone needs an implementation (for
That works as well, not optimal, but does reduce the backward compatibility
risk to the minimum, so I guess it's the best course of action.
On Wed, Jan 6, 2010 at 7:20 PM, Blake Sullivan blake.sulli...@oracle.comwrote:
OK. I got smarter and looked more carefully at the FacesBean
Hi Blake,
Yep, that's exactly what I meant. I'm aware that the main risk lies with
compatibility, but I think it's minimal.
Regards,
~ Simon
On Tue, Jan 5, 2010 at 8:00 PM, Blake Sullivan blake.sulli...@oracle.comwrote:
Simon Lessard said the following On 1/5/2010 2:34 PM PT:
Blake,
OK. I got smarter and looked more carefully at the FacesBean
implementations. The best solution is to modify
org.apache.myfaces.trinidadinternal.bean.UIXFacesBeanImpl to hang onto
the UIXComponent passed to init() and then override setProperty(),
getLocalPropertyImpl(), saveState(), and
On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
UIComponent.getId() is by far the most requested component attribute. There
are a number of reasons for this:
1) The JSF RI has an issue in the JSP-JSF integration which causes getId()
to be called n^2 times
Matthias Wessendorf said the following On 1/5/2010 10:49 AM PT:
On Thu, Dec 31, 2009 at 11:12 PM, Blake Sullivan
blake.sulli...@oracle.com wrote:
UIComponent.getId() is by far the most requested component attribute. There
are a number of reasons for this:
1) The JSF RI has an issue in the
Hi,
Why not simply NOT support a PropertyKey for the id attribute? I know it
isn't consistent with the other properties, but id is a very special case
not supporting EL anyway. In all the project I ever did, I never used
FacesBean.getProperty(ID_PROPERTY_KEY). The only drawback I would see is if
The reason is that we need to support AttributeMap/component accessor
equivalence--get/set of the id attribute through the Map is supposed to
work correctly. The ValueExpression only exists to make this work.
-- Blake Sullivan
Simon Lessard said the following On 1/5/2010 10:57 AM PT:
Hi,
Have the AttributeMap call the getId/setId. The contract for the Map
returned by getAttributes is supposed to call the getter/setter method on
the component anyway, from
http://java.sun.com/javaee/5/docs/api/javax/faces/component/UIComponent.html#getAttributes%28%29
:
- get() - If the
Is your suggestion that we
1) Add a new Map(String, Object) implementation that takes both the
FacesBean and the UIComponent
2) Explicitly test for the id attribute in all of the accessor and
mutator functions, in addition to the the Sets returned
3) Override the state saving/restoration code
Hi Blake,
Actually it's harsher/simpler than that. Assuming that .getAttributes() is
very rarely used in a Trinidad application (exception for custom
attributes).
1. Have AttributeMap work exactly like standard JSF's AttributeMap. That is,
always call the getter/setter on the component (which in
Simon,
For part 1), are you proposing that we stop overriding getAttributes()?
If so, private implementation properties used by the component and set
by using setAttribtue(), would not be available on the FacesBean. So I
assume that you are suggesting that we change the components to set
Blake,
For 1, both possibilities exist. However, I would prefer them to not be
available on the FacesBean from a performance PoV. Those don't have indexed
property keys anyway so the lookup for them is actually quite inefficient.
That would requires some additional changes to the state saving
Simon Lessard said the following On 1/5/2010 2:34 PM PT:
Blake,
For 1, both possibilities exist. However, I would prefer them to not be
available on the FacesBean from a performance PoV. Those don't have indexed
property keys anyway so the lookup for them is actually quite inefficient.
That
Hmm. It would be nice if the HTML formatting actually worked
1) Current Implementation:
UIComponent.getFoo(): Flagged Map Access
UIComponent.getId(): Map Access (since id
always set)
FacesBean.getProperty(FOO_KEY):Flagged Map
UIComponent.getId() is by far the most requested component attribute.
There are a number of reasons for this:
1) The JSF RI has an issue in the JSP-JSF integration which causes
getId() to be called n^2 times where n is the number of children a
component has
2) getClientId() calls getId()
3)
17 matches
Mail list logo
