Hello Andrew,

Your examples don't handle concern #2 of my reply.


Regards,

~ Simon

On Mon, Apr 14, 2008 at 12:21 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:

> 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
> >  > >
> >  >
> >  >
> >
>

Reply via email to