And here again, I can only support Cristi - Trinidad has clearly said that the renderers are part of the implementation (it is even in the package name!). People know implementation code might change its API in the next version, so there is no sense in enforcing this on the source level...
regards, Martin On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote: > One more thing, > > Trinidad now being open-source means that it should be really open > for those advanced developers that dive into the code. > > On Thu, Apr 10, 2008 at 8:11 AM, Cristi Toth <[EMAIL PROTECTED]> wrote: > > > Well, between having developers not being able to override some simple > > behaviour > > and keeping backwards compatibility on subclassers, > > I'll choose the 2nd one. > > > > This is the reason that some components from tomahawk, > > that are less feature-enabled that thos in Trinidad, > > are considered more flexible and easier to customize than the ones in > > Trinidad. > > > > Quite some experienced MyFaces developers told me to > > "forget" overriding table and input renderers in Trinidad > > (some of the most frequently used renderers). > > > > > > So between not having a feature at all and being careful not to break > > backwards compatibility on some methods, > > the second one doesn't seem that bad, but the first one does. > > > > regards, > > > > > > On Thu, Apr 10, 2008 at 2:39 AM, Blake Sullivan > <[EMAIL PROTECTED]> > > wrote: > > > > > The reason is that each time we make one of these methods protected, we > > > have to guarantee that we will maintain the semantics of that hook until > the > > > end-of-time or risk breaking users of that hook. By slowly opening up > the > > > api we get the developers to tell us what they need and can weigh the > > > benefit against the support cost. If the hooks don't require that super > be > > > called, in many ways, it is safer to completely override the function. > > > > > > This is the general issue of the competing desires to make it easy to > > > tweak a renderer by subclassing without needing to completely replace it > vs. > > > a desire to be able to change the Renderer implementation without > breaking > > > subclassers. I actually think that we went too far in providing lots of > > > subclasser knobs in Trinidad, but that's just my opinion. > > > > > > -- Blake Sullivan > > > > > > Cristi Toth said the following On 4/9/2008 5:23 PM PT: > > > > > > Hi guys, > > > > > > A lot of Trinidad renderers have some "override useful" methods as > > > private or protected final. > > > This makes customizing renderers a nasty job. > > > > > > - first these methods obviously can't be overriden > > > - then when trying to override some public/protected methods, > > > it's hard because they use other private methods that you can't use in > > > your overriden method > > > > > > I assume this come from the fact that Trinidad wasn't open-source in its > > > origins... or? > > > Do we still have reasons to keep it this way? > > > > > > IMO we could make those protected final "override useful" methods to > > > protected > > > and the private methods used in those methods, make them protected > > > final. > > > > > > What's you opinion on this? > > > > > > Regards, > > > -- > > > Cristi Toth > > > > > > ------------- > > > Codebeat > > > www.codebeat.ro > > > > > > > > > > > > > > > -- > > Cristi Toth > > > > ------------- > > Codebeat > > www.codebeat.ro > > > > > > -- > Cristi Toth > > ------------- > Codebeat > www.codebeat.ro > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
