Hello, 1) remove the restriction of trinidad-impl being non-API and enforce that code in this package be backward-compatible No, it's way too messed up still to say that we're going to be backward compatible, ui and uinode for example and some renderer are messed up as well, they renderer what they need correctly bu are not necessarily as good as they should be (including some of mine)
2) somehow move some of the burden of parts of renderers out of trinidad-impl and into trinidad-api I would be +1 to move resolveProperty and findTypeConstants to CoreRenderer; I would be +1 to move XhtmlRenderer to trinidad-api IF we were to clean it up first, it's the base renderer and there's some strangeness with it like some static methods that shouldn't really be static, has some redundant methods and/or parameters. There's also TypedRenderer interface that doesn't seem to be used anymore which is in the api that XhtmlRenderer implements. I don't think much more should be moved to api. Maybe we could create a enums or constant classes for XhtmlElement and XhtmlAttribute based on W3C, that would help save typos for renderer writer. Other than that, I don't see anything that semantically fit to be in api. When you want to redo a room decoration to make it more functional, it's often useful to start by cleaning it up. 3) introduce some configurable way to override default behavior for rendering certain areas of components. I don't think anyone would be against that as long as we don't have to ensure backward compatibility, but a simple, serious redesign of every component would probably do better than hooks. I kind of liked the reduced multiple renderers idea. It would complexify the delegation structure, but would also improve modularity and readability imho. 4) removing some final modifiers after discussion and make extending Trinidad renderers accepted, aka not tabu Not taboo, but I think we should maintain the API may change without warning from a version to another notification in the doc. Again, rethinking (or simply thinking) the current renderer class structure and the method contract would probably do better than just ditching the final modifier. I think we need to create some rules and always follow them. One example is the main issue I get on when working with renderer extension, which is the parent renderer failing to call a non-final protected getter method to get an attribute value, either calling it directly from the bean and the property key, resulting in a NullPointerException if my component doesn't support that attribute or calling a protected method that I cannot override, under which case I do ditch the final modifier. 5) promoting private members to protected or public after discussion and make extending Trinidad renderers accepted, aka not tabu. Idem as 4. Regards, ~ Simon On Fri, Apr 11, 2008 at 3:04 PM, Andrew Robinson < [EMAIL PROTECTED]> 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 > 2) somehow move some of the burden of parts of renderers out of > trinidad-impl and into trinidad-api > 3) introduce some configurable way to override default behavior for > rendering certain areas of components. > 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 > > 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 >
