Ok, so if you are pro, which solution do you prefer? And if the configurable one (1st) than what kind of implementation do you think of?
On Thu, Apr 10, 2008 at 7:17 PM, Andrew Robinson < [EMAIL PROTECTED]> wrote: > ++1 > > On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek > <[EMAIL PROTECTED]> wrote: > > 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 > > > -- Cristi Toth ------------- Codebeat www.codebeat.ro
