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
>
