1) the company will not be angry, as I mentioned that I would be making the hack as a temporary solution, fully expecting that it will need to be converted later
2) It is impossible to control renderers 100% through component attributes and Skinning. For example, sometimes their DOM may just be wrong for someone (using a TABLE instead of a DIV...). If you ever tried to write an application using Trinidad you may understand ;) . Having huge amounts of attributes to make all the little things customizable would make (1) a really bad and hard to use API and (2) would have performance that sucked. If I want all my table components to render in a certain way, it is much better for me to customize the renderer than to have the renderer do if or switch statements on attributes all the time to customize how it does the rendering. On Fri, Apr 11, 2008 at 10:25 AM, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > 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. > > > > > >
