Now it's me not to understand what you mean :)
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(a)oracle.com> wrote:
> >>>>> On Wed, 11 Aug 2010 11:46:21 -0400, Kito Mann
<kito.mann(a)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(a)oracle.com | office: +1 407 458 0017
> | homepage: |
http://ridingthecrest.com/
> | 02 work days until JSF 2.1 Milestone 2
>