Hi Scott, your statement is really irrelevant - in JSF, renderers are designed to be extended/exchanged. JSF has been built this way. Trinidad (or where Trinidad comes from) tries to make this impossible, out of support reasons inside Oracle. If you go into a wider space, and want Trinidad to be accepted by more people than just Oracle clients, you will need to allow them (if they find out the behaviour of the existing renderers does not fit their use-case well enough) to extend and override the existing behaviour. You can certainly tell them that they are not in a safe land if they do this, but you should not prohibit it.
It is much like the time of the "Prohibition" in the US - what is better - telling people it is not safe to override renderers (=drink alcohol), but allowing them to do so still, and most people will do it appropriately (=drink in moderation) and just fix a problem in the upgrade when it arises, or prohibit it by making everything final and private (=prohibition of drinking alcohol completely), which overly restricts what people may want to do and will lead to something close to a revolution. I can certainly accept Andy's and Blake's statements - let us not open everything, but decide on a case-by-case base what to open up (in reality, we did the same in Tomahawk, in the beginning, most of our methods where private as well, now a lot of hooks have been changed to be protected - where clients actually felt the need to override something), but I cannot accept your statement - this is dangerous for Trinidad and its community. You should change your opinion in this case! Once again: I can accept that renderers are not _meant_ to be overriden, but I cannot accept that it is completely _prohibited_ to do so. Now I know that Cristi is actually working with Trinidad, and that he has a problem, namely he would need to be able to override/replace sub-renderers for a clients design-issue. This is a concrete problem, and if he wants to address it, we should allow him so - and I definitely feel it should be addressed, if you take the general spirit of JSF, which allows a lot of flexibility. regards, Martin On 4/11/08, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > But that is my point precisely. We don't "offer" the impl classes to > clients to extend. Only the classes in the API. > > Scott > > Scott > > Cristi Toth wrote: > > 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 <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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 > > <[EMAIL PROTECTED] > > <mailto:[EMAIL PROTECTED]>> 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 <http://www.codebeat.ro> > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
