Did you mean to slow down implementing it, or the actual performance of the implementation?
Implementing it the way Kito suggests, will probably be faster then having to read a context-parameter, even if both solutions will have neglectable impact overall.
I guess adding two static PropertyDescriptors (with appropriate read-methods) to the property descriptor map wouldn't add any noticeable overhead. Returning null for the write-method will also make them read-only as suggested (this probably should depend on a context-parameter, but would postpone the evaluation of it until a write call is made, which probably no one ever uses)
Imre
On 17.08.2010, at 05:06, Blake Sullivan wrote:
This would needlessly slow down the context attributes
implementation, which is also hammered on.
-- Blake Sullivan
On 8/16/10 9:10 AM, Kito Mann wrote:
On Mon, Aug 16, 2010 at 9:48 AM, Ed Burns
<edward.burns@oracle.com>
wrote:
>>>>> On Wed, 11 Aug 2010 11:46:21 -0400, Kito
Mann <kito.mann@virtua.com>
said:
KM> Couldn't you modify the map to return the constant
values for the
KM> proper keys? That way, they would be read-only values
that don't
KM> need to be stored, the Map just needs to know the keys.
I'm sorry, I don't understand what you mean. Can you please
restate it
differently?
Basically, what I'm saying is that we could change the Map
implementation to simply delegate to UIComponent.getCurrentComponent() and UIComponent.getCurrentCompositeComponent() in the
get() method whenever the key value is CURRENT_COMPONENT or
CURRENT_COMPOSITE_COMPONENT. This way we'd save space but
would maintain backwards compatibility without the switch.
Ed
--
| edward.burns@oracle.com
| office: +1 407 458 0017
| homepage: | http://ridingthecrest.com/
| 02 work days until JSF 2.1 Milestone 2