not sure if the thread is already "over"... since I was gone for some days...
On Fri, Apr 11, 2008 at 8:45 AM, Martin Marinschek <[EMAIL PROTECTED]> wrote: > 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. nice example :) > > 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 I agree, that having hooks may be the better option for the Trinidad community (and the adoption of Trinidad) > 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 > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
