[
https://issues.apache.org/jira/browse/TRINIDAD-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Lessard resolved TRINIDAD-631.
------------------------------------
Resolution: Fixed
Fix Version/s: 1.0.3-core
Applied the patch to the trunk.
> 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
> Assignee: Simon Lessard
> Fix For: 1.0.3-core
>
> Attachments: TRINIDAD-631.patch
>
>
> 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.
