Hello all,

I'm a bit torn on that issue. On one side, I don't find it too hard to
override current renderers and actually think there's a quite formidable
amount of protected methods, but on the other side I do come across annoying
final methods every now and then and I have to use my commiter right to
remove it which is not an immediate option available to everyone. So,
basically, I'm +0...


Regards,

~ Simon

On Thu, Apr 10, 2008 at 2:57 AM, Martin Marinschek <
[EMAIL PROTECTED]> wrote:

> And here again, I can only support Cristi - Trinidad has clearly said
> that the renderers are part of the implementation (it is even in the
> package name!). People know implementation code might change its API
> in the next version, so there is no sense in enforcing this on the
> source level...
>
> regards,
>
> Martin
>
> On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote:
> > One more thing,
> >
> > Trinidad now being open-source means that it should be really open
> > for those advanced developers that dive into the code.
> >
> > On Thu, Apr 10, 2008 at 8:11 AM, Cristi Toth <[EMAIL PROTECTED]>
> wrote:
> >
> > > Well, between having developers not being able to override some simple
> > > behaviour
> > > and keeping backwards compatibility on subclassers,
> > > I'll choose the 2nd one.
> > >
> > > This is the reason that some components from tomahawk,
> > > that are less feature-enabled that thos in Trinidad,
> > > are considered more flexible and easier to customize than the ones in
> > > Trinidad.
> > >
> > > Quite some experienced MyFaces developers told me to
> > > "forget" overriding table and input renderers in Trinidad
> > > (some of the most frequently used renderers).
> > >
> > >
> > > So between not having a feature at all and being careful not to break
> > > backwards compatibility on some methods,
> > > the second one doesn't seem that bad, but the first one does.
> > >
> > > regards,
> > >
> > >
> > > On Thu, Apr 10, 2008 at 2:39 AM, Blake Sullivan
> > <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > >  The reason is that each time we make one of these methods
> protected, we
> > > > have to guarantee that we will maintain the semantics of that hook
> until
> > the
> > > > end-of-time or risk breaking users of that hook.  By slowly opening
> up
> > the
> > > > api we get the developers to tell us what they need and can weigh
> the
> > > > benefit against the support cost.  If the hooks don't require that
> super
> > be
> > > > called, in many ways, it is safer to completely override the
> function.
> > > >
> > > > This is the general issue of the competing desires to make it easy
> to
> > > > tweak a renderer by subclassing without needing to completely
> replace it
> > vs.
> > > > a desire to be able to change the Renderer implementation without
> > breaking
> > > > subclassers.  I actually think that we went too far in providing
> lots of
> > > > subclasser knobs in Trinidad, but that's just my opinion.
> > > >
> > > > -- Blake Sullivan
> > > >
> > > > Cristi Toth said the following On 4/9/2008 5:23 PM PT:
> > > >
> > > > 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
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Cristi Toth
> > >
> > > -------------
> > > Codebeat
> > > www.codebeat.ro
> > >
> >
> >
> >
> > --
> > Cristi Toth
> >
> > -------------
> > Codebeat
> > www.codebeat.ro
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Reply via email to