Forgot to say that in my example, I have "TestSubRendererHeader" as a renderer type. So the registered renderer for this type should have knowledge on how to appropriately render a header for this component type. So in this case, the contract is the FacesBean having a "header" property set or having a "top" faces present.
Or am I still off base in your concern? On Mon, Apr 14, 2008 at 10:45 AM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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? >
