myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cristi Toth" <cristi.t...@gmail.com>
Subject Re: [Trinidad] private / protected final methods in renderers
Date Thu, 10 Apr 2008 21:59:58 GMT
Well I think we don't see the problem in the same way.

What does good design mean in this case ...!?
Making some methods protected and remove the final for others doesn't hurt
Trinidad itself at all.
So you can't say this is bad design.

If the bad design refers to what we offer the clients, than this is
definitely wrong.
Because a quite a lot of clients that me or some of my collaborators have
interacted with,
have complained a lot about Trinidad code that's so CLOSED !!!
Many said that instead of trying a small feature to the trinidad table,
you better take the Tomahawk one, and add all the feature you need on it.
It's easier and cleaner.

The faces-config allows you to override any renderer for any component,
right !?
So renderers are meant to be overriden. (by the JSF spec)
This is the beauty of JSF, because it's so flexible and customizable.
How do you expect to override Trinidad renderers?
Copying all the code and make some small changes?
Imagine that overriding some behaviour of some larger renderers,
you have to override the whole renderer hierarchy (i.w.
LabelAndMessageRenderer).

Between duplicating the whole renderer code
and just having some protected renderer methods,
which sounds better in design?

If we talk about backwards compatibilty,
then imagine a whole duplicated renderer which isn't aware of any other
updated renderers...
And if a custom renderer developer gets a compile error after an update,
I assume it won't take him to much time to fix it...

If a renderer is not in the API, this means that it shouldn't be overriden
!?
Let's think a bit out of the box and try to figure what's best for the
client.
Because that's what matters most...

regards,

On Thu, Apr 10, 2008 at 11:34 PM, Scott O'Bryan <darkarena@gmail.com> wrote:

> The overuse of final is largely irrelevant in impl packages.  The reason
> is that removing a final allows the class to remain binary compatible and
> only items inside of the impl package should be extending the class.
>
> In some cases, final helps ensure an implied contract.  In other words, if
> something is final, you know it's implemented nowhere else.  In API's I
> agree with Andy, final should be used only to enforce a contract that should
> not (can not) change.  Most commonly this is used on immutable classes/api
> but it has some other uses.
>
> Scott
>
>
> Andy Schwartz wrote:
>
> > Hi Andrew -
> >
> > On Thu, Apr 10, 2008 at 4:36 PM, Andrew Robinson
> > <andrew.rw.robinson@gmail.com> wrote:
> >
> >
> > > I wasn't suggesting blind removal.
> > >
> > >
> >
> > Okay.  The use of the word "most" gave me that impression. :-)
> >
> >
> >
> > > IMO final should rarely ever be used, for open source it almost never
> > > does
> > > anyone any good.
> > >
> > >
> >
> > Final should be used for its intended purpose.  Sure, in some cases
> > final may be abused, but then those cases should be corrected.  That
> > doesn't mean that final should rarely be used - it should be used when
> > appropriate.
> >
> > Again, I don't see how open vs. closed source comes into play here.
> > Good API design is good API design, whether open or closed source.
> >
> >
> >
> > > I would suggest a renderer-by-renderer approach though, not
> > > method-by-method
> > >  as that would take too long to file that many bugs.
> > >
> > >
> >
> > I am not sure I understand the difference between these approaches.
> > At some point somebody will need to evaluate specific methods to
> > determine whether changes are required.
> >
> > Personally I prefer the approach that Blake alluded to, which is to
> > open things up as the need arises.  (I may have missed it, but I don't
> > remember seeing the particular offending cases which triggered this
> > discussion.)
> >
> >
> >
> > >  Right now Trinidad and facelets are by far the most inflexible open
> > >  source code I have worked with. Both over-use final and both assume
> > >  that out-of-the box behavior is enough fore everyone's needs. For
> > >  Trinidad renderers, many only expose encodeAll as protected then do
> > >  most of the work in private methods. As a result a person needing to
> > >  customize a renderer has to use copy & paste (generate an entirely
> > > new
> > >  renderer using the source of the core one) which really sucks for
> > >  maintenance.
> > >
> > >
> >
> > I don't understand this at all.  Why would anyone do that, vs. log an
> > issue, submit a patch, fix the problem, revel in the magic of open
> > source?
> >
> > Is the issue here really that the renderers as a whole are considered
> > off-limits to subclassing, due to the fact that they are located in
> > trinidadinternal (not trinidadapi)?
> >
> > Andy
> >
> >
>
>


-- 
Cristi Toth

-------------
Codebeat
www.codebeat.ro

Mime
View raw message