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>
