[jira] Resolved: (TRINIDAD-631) Renderer classes that extend InputLabelAndMessageRenderer don't provide protected constructor with parameter FacesBean.TYPE

["Simon Lessard (JIRA)" <de...@myfaces.apache.org>]

     [ 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 <aw...@...> 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 <si...@...> 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 < carsten.pieper@...> 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.