> > 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 protected 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 maintenance). 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.
