Hello Andrew, Ok, let say we have a renderer that renders a custom layout with an inputText showing the component's value and allowing to alter it. Since we don't want to reinvent the wheel, we need to reuse the inputText renderer. So, somewhere in the code we'll see something like :
delegateRenderer(context, rc, component, bean, _simpleInputTextRenderer); This is where it gets fishy and why findTypeConstants exists (and I assume while cloneWithType / TypedRenderer were created in the first place). If you get the renderer instance from the render kit, or from a direct new using the default constructor for that matter, the renderer will be initialized with CoreInputText.TYPE property keys, but my custom component does not use that type, it rather use MyComponent.TYPE. So, the FacesBean instance passed to delegateRenderer will be using that latter type and there's absolutely no guarantee (actually it's pure luck if it is) that the PropertyKey instance found by the renderer in its findTypeConstants for the value property is going to be the same than the one from my custom type. So, normally in the current delegate model, we instanciate the delegate renderer using the protected constructor receiving a FacesBean.Type instance so that it initialize itself with the right PropertyKey for our use. We can probably workaround that issue using the cloneWithType(newFacesBean.Type) functionality of TypedRenderer, bu that's not the only use case we have. Sometimes, the custom component does not support or do not want to expose one of the attribute (for example onclick) on the renderer sub-part. When such circumstances show up, we create a private inner renderer class extending the one we need to delegate to and override the getter method (getOnclick(FacesBean)) of the property we don't want to render on the sub-part. I currently see no way to achieve that using renderers found from the render kit. Clearer ? ~ Simon On Mon, Apr 14, 2008 at 12:49 PM, Andrew Robinson < [EMAIL PROTECTED]> wrote: > 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? > > >
