Have you looked at my code in the branch? I think it would be good te critique that so that there is a solid example for people to look at. I did not attempt to make it pretty, so hopefully if such a thing is done, we would give it a better API.
SVN Path: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/xhtml/ Component: http://tinyurl.com/5sej5p Main Renderer that delegates: http://tinyurl.com/4hzk8t The two sub-renderers: http://tinyurl.com/4qrwgn http://tinyurl.com/5dvqxl The code works like current sub-renderers: 1) They are required to be an instance of CoreRenderer 2) They use the FacesBean that is passed in to their encodeAll method 3) They should not use the root component ID on any HTML element The only difference is that I looked the value up in the render kit instead of directly instantiating the renderer -Andrew On Mon, Apr 14, 2008 at 8:53 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > I thought a little bit more about the renderer composition idea and there > are some things to address. > > Currently, when we create a renderer using a delegation model, it often look > like the following: > > public class MyMainRenderer extends XhtmlRenderer > { > private Renderer partRenderer; > > protected void findTypeContants(FacesBean.Type type) > { > partRenderer = new TheSpecificDelegateRenderer(type); > } > > private class TheSpecificDelegateRenderer extends TheBaseDelegateRenderer > { > public TheSpecificDelegateRenderer(FacesBean.Type type) > { > super(type); > } > } > } > > public class TheBaseDelegateRenderer extends XhtmlRenderer > { > protected TheBaseDelegateRenderer(FacesBean.Type type) > { > super(type); > } > } > > Given we now want to define the composition renderers within faces-config, > it makes the previous way quite hard to deal with. We're most likely have to > locate the renderer using > > context.getRenderKit().getRenderer(componentFamily, rendererType); > > > I see two problems with this: > > 1. What naming convention should we use for the component families and > renderer types? That one is more a point to address than a problem; > 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? > > > Regards, > > ~ Simon > > > > On Mon, Apr 14, 2008 at 10:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> > wrote: > > On Mon, Apr 14, 2008 at 3:54 PM, Andrew Robinson > > > > <[EMAIL PROTECTED]> wrote: > > > > > Yes, I understand, but when one mailing list member is holding up > > > progress by providing only negative, non-constructive feedback and > > > even admits that his own branch of the thread has ceased to be useful, > > > > perhaps due to my lack of English these comments didn't sound that > > "non-constructive" I understood them as a valid concerns, which IMO > > legitimate to share them. BTW. here is an interesting FAQ ([1]) > > > > > > > it is important to be able to let the other members of the community > > > have a say. This was the only way to stop unnecessary bickering from > > > > I still don't like stopping contribtions that way... > > ...and we should keep the "discussion" open.... > > > > > > > going on without end. As long as people are contributing helpful > > > feedback and are attempting to further the discussion and help make > > > proposals on how to fix problems, instead of just making negative > > > comments on how people work, then that feedback is welcome. > > > > > > -Matthias > > [1] http://wicket.sourceforge.net/faqs.html#why-final > > > > > > > > > > > > > > > > > > > > On 4/14/08, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > > On Fri, Apr 11, 2008 at 9:04 PM, Andrew Robinson > > > > <[EMAIL PROTECTED]> wrote: > > > > > If you are not a member of MyFaces, Committer or PMC member please > > > > > refrain from further reply to this thread as your feedback has > already > > > > > been noted. > > > > > > > > as an asf member I really don't like statements like that... > > > > a strong community builds a strong product so, why not > > > > listening to contributors? > > > > > > > > -M > > > > > > > > > > > > > > Thank you, > > > > > Andrew > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth > <[EMAIL PROTECTED]> > > > > wrote: > > > > > > Hi guys, > > > > > > > > > > > > A lot of Trinidad renderers have some "override useful" methods > as > > > > private > > > > > > or protected final. > > > > > > This makes customizing renderers a nasty job. > > > > > > > > > > > > - first these methods obviously can't be overriden > > > > > > - then when trying to override some public/protected methods, > > > > > > it's hard because they use other private methods that you > can't use > > > > in > > > > > > your overriden method > > > > > > > > > > > > I assume this come from the fact that Trinidad wasn't > open-source in > > > > its > > > > > > origins... or? > > > > > > Do we still have reasons to keep it this way? > > > > > > > > > > > > IMO we could make those protected final "override useful" > methods to > > > > > > protected > > > > > > and the private methods used in those methods, make them > protected > > > > final. > > > > > > > > > > > > What's you opinion on this? > > > > > > > > > > > > Regards, > > > > > > -- > > > > > > Cristi Toth > > > > > > > > > > > > ------------- > > > > > > Codebeat > > > > > > www.codebeat.ro > > > > > > > > > > > > > > > > > > > > > -- > > > > Matthias Wessendorf > > > > > > > > further stuff: > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > mail: matzew-at-apache-dot-org > > > > > > > > > > > > > > > -- > > > > > > > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > > >
