Renderer classes that extend InputLabelAndMessageRenderer don't provide
protected constructor with parameter FacesBean.TYPE
---------------------------------------------------------------------------------------------------------------------------
Key: TRINIDAD-631
URL: https://issues.apache.org/jira/browse/TRINIDAD-631
Project: MyFaces Trinidad
Issue Type: Bug
Reporter: Carsten Pieper
Detected this one for InputTextRenderer but it applies to all trinidadinternal
classes extending InputLabelAndMessageRenderer
These are:
InputColorRenderer
InputDateRenderer
InputFileRenderer
InputListOfValuesRenderer
InputNumberSpinboxRenderer
InputTextRenderer
SelectBooleanCheckboxRenderer
SelectBooleanRadioRenderer
SelectManyCheckboxRenderer
SelectManyListboxRenderer
SelectOneChoiceRenderer
SelectOneListboxRenderer
SelectOneRadioRenderer
Excerpts from
http://www.nabble.com/-Trinidad--Skinning---no-CSS-selector-for-tr%3AoutputText--tf4247489.html:
That's true, but for practical purposes we cannot pretend that people won't
make their own renderers using some features already present in trinidad-impl
since they help avoiding quite a lot of boilerplate code. Creating a new kind
of input component with a label and message is probably the most obvious case.
~ Simon
On 8/15/07, Adam Winer <[EMAIL PROTECTED]> wrote:
Strictly speaking, that's not really true... all of our renderers
are in trinidadinternal, which means that they're not really public
to the outside world, and their APIs can change arbitrarily from
release to release. So there's no guarantees of subclassabililty.
That said, I've got no problems adding the protected constructor,
but anyone subclassing the renderers has to know their code
can very well break any time they move to a newer version.
-- Adam
On 8/15/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Hello Carsten,
>
> Wow... you're right... JIRA issue please. It should be possible to
override
> all of our renderers and failing to provide a protected constructor
> receiving a FacesBean.Type prevents that.
>
>
> Regards,
>
> ~ Simon
>
>
> On 8/15/07, Carsten Pieper < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > Simon's advice works fine with me, except...
> > > The critical thing, which is easy to overlook, is that you
> > > have to pass your component's Type object to the Renderer
> > > superclasses constructor, which is what Simon's code is doing.
> >
> > I can't pass my component's Type object to the renderer superclass
> > because InputTextRenderer just has this one parameterless constructor:
> >
> > public InputTextRenderer()
> > {
> > super(CoreInputText.TYPE);
> > }
> >
> > Best regards,
> > Carsten
> >
> >
> > Adam Winer wrote:
> > >
> > > The critical thing, which is easy to overlook, is that you
> > > have to pass your component's Type object to the Renderer
> > > superclasses constructor, which is what Simon's code is doing.
> > >
> > > -- Adam
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
