On Mon, Apr 14, 2008 at 2:15 AM, Cristi Toth <[EMAIL PROTECTED]> wrote: > 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.
true. and it is important to not add everything to Trin :-) > 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. yes. I personally think that allowing hooks is OK. And the folks that "depend" on these hooks need to understand! that there overridden thing *can* fail in a next release... > > 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'. I like the "composed renderers" approach as well -Matthias > > > 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 > > > > > > > > > > > > > > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
