You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Carsten Pieper (JIRA)" <de...@myfaces.apache.org> on 2007/08/16 10:37:31 UTC
[jira] Created: (TRINIDAD-631) Renderer classes that extend
InputLabelAndMessageRenderer don't provide protected constructor with
parameter FacesBean.TYPE
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 <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.
[jira] Resolved: (TRINIDAD-631) Renderer classes that extend
InputLabelAndMessageRenderer don't provide protected constructor with
parameter FacesBean.TYPE
Posted by "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.