Simon, Frankly I do not understand #2, sorry. Could you explain what the problem is in a different way? Perhaps I just have not seen something in the current code that does something that you are referring to. I was hoping that someone besides myself would understand what you said better and provide an answer.
The code I presented works AFAIK like the current sub-renderer Trinidad architecture where a sub-renderer gets the property values, and the knowledge of existence of properties by querying the FacesBean instance, not the component. Therefore, to mask, rename or change the value of a property passed to a sub-renderer, would the developer not wrap, extend or present the FacesBean in some way to the sub-renderer to make those abstractions? Or am I really not understanding your concern correctly? -Andrew On Mon, Apr 14, 2008 at 10:37 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > Hello Andrew, > > Your examples don't handle concern #2 of my reply. > > > Regards, > > ~ Simon > > > > 2. How do we privately extends those renderer like > > > > TheSpecificDelegateRenderer does? I see no way and it's quite critic > as some > > > > renderers use that pattern in order to inhibit a given property or to > infer > > > > it from a different attribute of the original component. Well, saying > that I > > > > see no way is not exactly true. It could be possible to have those > renderers > > > > implement an interface defining a clone method (a bit like > TypedRenderer) > > > > receiving a kind of Accessors object to get its attribute values > from. > > > > However, I'm a bit wary of the performance impact of such structure > and it > > > > wouldn't necessarily fix all issues either. Anyone has any idea how > to deal > > > > with that?
