Andrew,
That's a fair assesment, but that same "pressed for time" company will
be angry when their stuff no longer works and those will turn into JIRA
tickets. I'm not saying we shouldn't make Trinidad more flexible. I'm
just saying that it's unrealistic to expose logic hap-hazardly. If this
is a really big issue, and I believe that you and others think it is,
then take the time to make it right. Think through the api's, clean
them up, and put them in the api package.
The Trinidad framework does offer a lot of flexibility for custom
component development, it's just not at the granularity that some people
want them to be. We don't expose specific renderers, just the rendering
infrastructure. If there are components that people need to
enhance/override then we should look at making those public, but really,
how hard is it to write a renderer or (better yet IMO) make the
renderers do what you want them to do though the use of attributes and
better skinning?
Scott
Andrew Robinson wrote:
> 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.
