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