Yes, much clearer. In a previous email on this thread, I had an idea on creating an alias wrapper for faces beans. The idea being that I could essentially rename the "title" property of the faces bean to "value" so I could use the output text renderer to print the title as it would a normal tr:outputText.
I am all for different approaches to this, as I am not sure my proposal is that wonderful. Yes, I could see and interface being used as you mention with the requirement that a renderer for type X implement interface Y, but that would be more restrictive, wouldn't it? The aliasing of the faces bean, and the ability to only expose certain properties with such an object is just one proposal. Frankly, I dislike writing "protected SomeObject getSomeProperty(FacesBean bean)" methods in renderers, as it seems to be quite unnecessary when the FacesBean has the information that is needed to perform this logic without making all these methods (it has the property type, the default value and access to get the current value). I do see their use, but I think that a better solution could be found. Perhaps in some abstraction of the FacesBean in the renderer? -Andrew On Mon, Apr 14, 2008 at 11:03 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > 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? > > > > > > >
