myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Robinson" <>
Subject Re: [Trinidad] private / protected final methods in renderers
Date Fri, 11 Apr 2008 15:53:47 GMT
>  >  What I mean by this is that rendereds should make an effort to expose
>  >  functionality even if it isn't thought through
>  I am not a fan of this.  If people want to put in the effort to think
>  through APIs that they expose on their renderers, then +1.  But big -1
>  from me for exposing APIs haphazardly.

My point is that protected in the trinidad-impl.jar is not an API that
is exposed. Since it is not an API, therefore it does not have to be
designed as such.

Let me give you a valid use case (valid as it has happened to me while
working on a project, not Trinidad, but similar open source issue):

1) Company decides to adopt Trinidad for a project
2) They are either (a) crunched for time or (b) need to get a release out
3) From mgmt, they are told they have to implement a feature
4) Trinidad has no way to support this feature, but the current
renderer has a method that would allow me to do it if it were
5) So assuming #3, the method is protected and in the trinidad-impl.jar
6) I extend the method, hacking the renderer and get the code to work
as required by my company and my customers.
7) We ship on this code to get it out the door
8) In the meantime, I create a JIRA issue to expose the functionality I require
9) It goes through weeks of debate (operating on recent Trinidad
experience on this comment) and finally 2 days to 5 months later makes
it into a SNAPSHOT build
10) My company has a policy to only use released versions, so I wait
and wait for the release (which is much better for Trinidad users that
Tomahawk which has less than yearly release cycles)
11) When it finally becomes API, I port my code from the hack of
subclassing the code to the new API

So as you can see, it was never my intention to treat the usage of the
protected method as a solution, but a temporary way to get my code to
work. Asking users to log bugs and wait for discussion and then
implementation and then a release is simply not feasible for many
companies that need to get software out the door.

So when I say #3 then #2, I mean to allow people to get their code out
quickly and then go through the proper channels to improve the code.
Saying #2 only is just not feasible for companies to meet deadlines
and many companies will not permit you to change open source code and
ship the changed versions (some afraid of licenses, some afraid of

I fully agree that #2 is the solution though and even that we need to
make some part of the trinidad rendering in the API, because I
strongly feel that only having components in the API is just not
customizable enough, and I don't think that components with 300
attributes and facets is the way to go.

View raw message