Hi, Let me add some things to what I already stated here.
There are 2 important reason for overriding renderers, that nobody mentioned here. 1) Not all users needs are general enough to be comitted into Trinidad. I myself encountered some very custom features required by some customers, that I simply said, there's no way I'll commit this in Trinidad. 2) Custom components When developers build some custom components, they usually extend the existing ones and most of the cases extend also the renderers. That's code reusability and flexibility, right? So for these types of cases, you have to support in some way the renderer overriding. Another reason for not complaining to much about renderer backward compatibility is that companies tend not to upgrade dependencies any more, when they have a relatively stable product. Not to mention that if the user duplicates the whole renderer, he'll have even more problems when upgrading. Thanks Andrew for trying to organize this thread. I totally support : 3) introduce some configurable way to override default behavior for rendering certain areas of components. The best way is having some smaller renderers that are delegated to render parts of components. As Andrew suggested, faces-config seems the perfect way to support overriding those 'sub-renderers'. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu For these 2 points, I really want to make myself clear. I have NOT even thought of promoting ALL private members to protected. Of course only if really helpful for overriding. And as Gabrielle stated, we never made promises of renderer backwards compatibility. Regards, -- Cristi Toth ------------- Codebeat www.codebeat.ro On Fri, Apr 11, 2008 at 11:02 PM, Gabrielle Crawford < [EMAIL PROTECTED]> wrote: > Generally I really do agree with Simon that "a simple, serious redesign of > every component would probably do better than hooks". > > Also, I really think once you put restrictions on your renderers you run > into issues, like you have a bug or a new feature which makes you need to > reorganize in an unexpected way. I'm fine with making it easier to subclass > renderers for those that want to take the risk, but I'm -1 on any scheme > that restricts our ability to make changes when the need arises. > > Other comments inline: > > Andrew Robinson wrote: > > > Could we move this discussion away from a debate? > > > > Could MyFaces Committers or PMC members _only_ please share their > > thoughts on this to keep the discussion to the stake holders only? > > > > Please share other solutions as you have them. > > > > Here some view points to discuss: > > > > 1) remove the restriction of trinidad-impl being non-API and enforce > > that code in this package be backward-compatible > > > > > -1, the renderers have to be able to change without worrying about > backwards compatibility. > > > 2) somehow move some of the burden of parts of renderers out of > > trinidad-impl and into trinidad-api > > > > > Maybe I've misunderstood, but this sounds like it's basically the same as > 1 but for pieces of a renderer, -1. > > > 3) introduce some configurable way to override default behavior for > > rendering certain areas of components. > > > > > That would be fine, as long as there's not a perf issue, and there's an > understanding that things may break at the next release - hopefully rare, > but possible. > > > 4) removing some final modifiers after discussion and make extending > > Trinidad renderers accepted, aka not tabu > > > > > I think removing final modifiers AFTER discussion is fine, and I think if > people want to risk extending renderers then fine, but we make no promises > they will not break at the next release. Same for 5 below. > > Thanks, > > Gab > > 5) promoting private members to protected or public after discussion > > and make extending Trinidad renderers accepted, aka not tabu > > > > Christi, could you please share more of your needs and give further > > legitimate reasons why this is needed? > > > > If you are not a member of MyFaces, Committer or PMC member please > > refrain from further reply to this thread as your feedback has already > > been noted. > > > > Thank you, > > Andrew > > > > > > On Wed, Apr 9, 2008 at 6:23 PM, Cristi Toth <[EMAIL PROTECTED]> > > wrote: > > > > > > > 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 > > > > > > > >
