Ignore the component link, I messed that one up. The renderers are the ones to have a look at.
On Mon, Apr 14, 2008 at 10:11 AM, Andrew Robinson <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > >
