Andrew I really like you idea from the other thread (the trick one :) ). Having new renderer types in the API and being able to override them via faces-config sounds much more standard and clean.
Probably we should wait and see where the other thread leads to and then start a vote on this regards, On 4/11/08, Scott O'Bryan <[EMAIL PROTECTED]> wrote: > Sorry, this went to the wrong thread. Please disregard. > > Scott > > Scott O'Bryan wrote: > > So if this is the case (ie- people who extend impl expect things to > > break and know what they are doing), why is it so hard for these > > people to submit a patch to add a protected or remove a final? Again, > > everything will remain binary compatible. > > > > Scott > > > > Cristi Toth wrote: > >> 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] <mailto:[EMAIL PROTECTED]>> > >> wrote: > >> > >> ++1 > >> > >> On Thu, Apr 10, 2008 at 12:55 AM, Martin Marinschek > >> <[EMAIL PROTECTED] <mailto:[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] > >> <mailto:[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] > >> <mailto:[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] <mailto:[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 <http://www.codebeat.ro> > >> > > > > >> > > > >> > > > >> > > > >> > > -- > >> > > Cristi Toth > >> > > > >> > > ------------- > >> > > Codebeat > >> > > www.codebeat.ro <http://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 <http://www.codebeat.ro> > > > > -- Cristi Toth ------------- Codebeat www.codebeat.ro
