If you want to here my opinion: we need Trinidad to be as customizable as possible. People who do this customization will know what they are doing - and will know how to handle an upgrade to a new version. It is enough to say: this is part of the impl package - it might change from version to version, your own fault, if you extend it and it breaks!
IMHO, Adam is wrong in this regard. regards, Martin On 4/10/08, Cristi Toth <[EMAIL PROTECTED]> wrote: > But what does the "open-source" mean then... ? > All the renderers are in the impl packages, > but that's the beauty of open-source... > you can customize something you need. > That's an advantage that we should not oversee. > > On Thu, Apr 10, 2008 at 5:07 AM, Andrew Robinson < > [EMAIL PROTECTED]> wrote: > > > I am not sure if you will get much support as Trinidad has all the > > renderers in the impl package, and therefore should not be considered > > part of its api and also should not be extended. Fighting this and > > asking for more APIs in the past was fruitless for me, but then again > > that was when Adam Winer was the constant one to veto all > > improvements. > > > > On Wed, Apr 9, 2008 at 6:14 PM, Cristi Toth <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > > > As you probably know, there are a lot of "composed" renderers in > > Trinidad > > > which delegate to other "sub"renderers to render parts of the component. > > > i.e. Table renderer delegates to: > > > - NavBar(subclass of SelectRangeChoiceBarRenderer), > > > - AllDetails (subclass of ShowDetailRenderer) > > > - DetailColumnRenderer > > > > > > input fields renderers (subclasses of InputLabelAndMessageRenderer) > > delegate > > > to: > > > - one renderer that renders the input field (subclass of > > > FormInputRenderer) > > > - Label (subclass of OutputLabelRenderer) > > > - Message (subclass of MessageRenderer) > > > > > > and many more... > > > > > > As this may look like "good practice", it makes life hell for the > > developers > > > that want to customize/override these renderers. > > > > > > I have 2 possible solutions: > > > > > > 1. make some xml config file that maps a "sub-renderer" type to a > > renderer > > > class > > > I know this might look like the old uix practice, but it's for a > > differernt > > > reason. > > > With a small xsd and some docs, this will be much more transparent. > > > > > > 2. at least have protected getters that return a renderer instance > > > either for using the default defined sub-renderer in an overriden method > > > or just for overriding that sub-renderer itself > > > > > > I personally like the 1st solution more, because it's easier to override > > > sub-renderers > > > defined in a super class of more renderers (LabelAndMessageRenderer) > > > > > > Opinions, suggestions, other solutions? > > > > > > regards > > > > > > -- > > > 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
