You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Sylvain Vieujot <sv...@apache.org> on 2005/05/10 13:55:09 UTC
Vote for new displayValueOnly attribute
I don't want to over user the voting process, but I feel this issue
should be sorted.
I apologize for the ones that would be bothered by this, and here is the
new feature I propose to vote on :
- Add an interface similar to UserRoleAware, that some x: components
would implement.
- Add the matching attribute (no name decided yet, but let's use
displayValueOnly).
By default, displayValueOnly is false, and the components behaves as
they do today.
When displayValueOnly is true, no input widget is rendered. Only the
text corresponding to the component's value is displayed.
Examples :
For inputText, inputTextarea, inputHtml, the text is displayed as if it
where rendered by an outputText (with proper escape).
For radio buttons, check boxes, combo boxes & list boxes, only the
selected values are displayed.
For inputDate, the date is rendered
As suggested by Manfred, please remember that a negative binding vote on
a *feature addition* proposal means: showstopper, that prevents the
whole community from getting a (perhaps) valuable contribution. A -1
voter should at least present an alternative solution and should be
willing to implement it himself
Here is my +1 for this.
Thanks,
Sylvain.
Re: Vote for new displayValueOnly attribute
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello Sean,
No, the work hasn't begun yet, but I would like this to be finished
roughly by the end of the week.
And frankly it starts to be much longer to discuss than to implement.
I have other proposals that would require a subproject, but for this
one, I would like this to really be resolved or refused.
Thanks,
Sylvain.
On Tue, 2005-05-10 at 13:09 -0400, Sean Schofield wrote:
> Sylvain,
>
> Has the work on this already been done? If not, do you think it will
> take long? Perhaps we could have Sylvain commit his proposed changes
> (without a vote) and then vote on whether to keep them. I think it
> would be easier to see the actual code plus a new simple example.
>
> BTW, this is a perfect argument for a sandbox ASAP. Even though
> Sylvain's suggestion is to add to an existing component, we could have
> him add the existing component plus modifications to sandbox. Then we
> could add Kalle's proposal to the sandbox. Then everyone could
> evaluate the two approaches.
>
> It sounds like Sylvain would like to resolve this sooner than when the
> sandbox issue will be resolved but IMO this is an argument for
> starting up the subproject discussion again.
>
> sean
>
> On 5/10/05, Martin Marinschek <ma...@gmail.com> wrote:
> > Hi Grant,
> >
> > it will be the same component - an HtmlInputText in the MyFaces
> > ext-package, all that was going to change was an additional attribute
> > on the component and the rendering of the component. Component stays
> > the same!
> >
> > Kalle's suggestion would be leading to a whole new bunch of components
> > - still there would be one fixed underlying component.
> >
> > so there is no difference in this aspect.
> >
> > regards,
> >
> > Martin
> >
> > On 5/10/05, Grant Smith <gr...@marathon-man.com> wrote:
> > > Before casting a vote, I would like to seek clarity on one issue this seems
> > > to raise:
> > >
> > > If the displayValueOnly attibute is set, does the underlying component
> > > change ? for example, if I have:
> > >
> > > <x:someComponent
> > > binding="#{someBean.methodReturningComponent}"/>
> > >
> > > And I directly manipulate the underlying component with
> > > someBean.methodReturningComponent(). If I add the new
> > > displayValueOnly, will I still be able to directly manipulate the same
> > > underlying component, or will that component now be something different ?
> > > I'm thinking it WILL be different, but I would like clarity on that.
> > >
> > > Thanks,
> > > Grant.
> > >
> > > Martin Marinschek wrote:
> > > +1 from me...
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 5/10/05, Thomas Spiegl <th...@gmail.com> wrote:
> > >
> > >
> > > +1 using Myfaces extended components
> > > +1 add an interface similar to UserRoleAware
> > > +1 adding displayValueOnly attribute
> > >
> > > What's about matching style & styleClass attributes
> > > (displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
> > > those attributes as well?
> > > +1 from me
> > >
> > > regards, thomas
> > >
> > > On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > >
> > >
> > > I don't want to over user the voting process, but I feel this issue should
> > > be sorted.
> > > I apologize for the ones that would be bothered by this, and here is the
> > > new feature I propose to vote on :
> > >
> > > - Add an interface similar to UserRoleAware, that some x: components would
> > > implement.
> > >
> > > - Add the matching attribute (no name decided yet, but let's use
> > > displayValueOnly).
> > > By default, displayValueOnly is false, and the components behaves as they
> > > do today.
> > > When displayValueOnly is true, no input widget is rendered. Only the text
> > > corresponding to the component's value is displayed.
> > >
> > > Examples :
> > > For inputText, inputTextarea, inputHtml, the text is displayed as if it
> > > where rendered by an outputText (with proper escape).
> > > For radio buttons, check boxes, combo boxes & list boxes, only the selected
> > > values are displayed.
> > > For inputDate, the date is rendered
> > >
> > > As suggested by Manfred, please remember that a negative binding vote on a
> > > *feature addition* proposal means: showstopper, that prevents the whole
> > > community from getting a (perhaps) valuable contribution. A -1 voter should
> > > at least present an alternative solution and should be willing to implement
> > > it himself
> > >
> > > Here is my +1 for this.
> > >
> > > Thanks,
> > >
> > > Sylvain.
> > >
> > > .
> > >
> > >
> > >
> > >
> >
Re: Vote for new displayValueOnly attribute
Posted by Sean Schofield <se...@gmail.com>.
Sylvain,
Has the work on this already been done? If not, do you think it will
take long? Perhaps we could have Sylvain commit his proposed changes
(without a vote) and then vote on whether to keep them. I think it
would be easier to see the actual code plus a new simple example.
BTW, this is a perfect argument for a sandbox ASAP. Even though
Sylvain's suggestion is to add to an existing component, we could have
him add the existing component plus modifications to sandbox. Then we
could add Kalle's proposal to the sandbox. Then everyone could
evaluate the two approaches.
It sounds like Sylvain would like to resolve this sooner than when the
sandbox issue will be resolved but IMO this is an argument for
starting up the subproject discussion again.
sean
On 5/10/05, Martin Marinschek <ma...@gmail.com> wrote:
> Hi Grant,
>
> it will be the same component - an HtmlInputText in the MyFaces
> ext-package, all that was going to change was an additional attribute
> on the component and the rendering of the component. Component stays
> the same!
>
> Kalle's suggestion would be leading to a whole new bunch of components
> - still there would be one fixed underlying component.
>
> so there is no difference in this aspect.
>
> regards,
>
> Martin
>
> On 5/10/05, Grant Smith <gr...@marathon-man.com> wrote:
> > Before casting a vote, I would like to seek clarity on one issue this seems
> > to raise:
> >
> > If the displayValueOnly attibute is set, does the underlying component
> > change ? for example, if I have:
> >
> > <x:someComponent
> > binding="#{someBean.methodReturningComponent}"/>
> >
> > And I directly manipulate the underlying component with
> > someBean.methodReturningComponent(). If I add the new
> > displayValueOnly, will I still be able to directly manipulate the same
> > underlying component, or will that component now be something different ?
> > I'm thinking it WILL be different, but I would like clarity on that.
> >
> > Thanks,
> > Grant.
> >
> > Martin Marinschek wrote:
> > +1 from me...
> >
> > regards,
> >
> > Martin
> >
> > On 5/10/05, Thomas Spiegl <th...@gmail.com> wrote:
> >
> >
> > +1 using Myfaces extended components
> > +1 add an interface similar to UserRoleAware
> > +1 adding displayValueOnly attribute
> >
> > What's about matching style & styleClass attributes
> > (displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
> > those attributes as well?
> > +1 from me
> >
> > regards, thomas
> >
> > On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
> >
> >
> > I don't want to over user the voting process, but I feel this issue should
> > be sorted.
> > I apologize for the ones that would be bothered by this, and here is the
> > new feature I propose to vote on :
> >
> > - Add an interface similar to UserRoleAware, that some x: components would
> > implement.
> >
> > - Add the matching attribute (no name decided yet, but let's use
> > displayValueOnly).
> > By default, displayValueOnly is false, and the components behaves as they
> > do today.
> > When displayValueOnly is true, no input widget is rendered. Only the text
> > corresponding to the component's value is displayed.
> >
> > Examples :
> > For inputText, inputTextarea, inputHtml, the text is displayed as if it
> > where rendered by an outputText (with proper escape).
> > For radio buttons, check boxes, combo boxes & list boxes, only the selected
> > values are displayed.
> > For inputDate, the date is rendered
> >
> > As suggested by Manfred, please remember that a negative binding vote on a
> > *feature addition* proposal means: showstopper, that prevents the whole
> > community from getting a (perhaps) valuable contribution. A -1 voter should
> > at least present an alternative solution and should be willing to implement
> > it himself
> >
> > Here is my +1 for this.
> >
> > Thanks,
> >
> > Sylvain.
> >
> > .
> >
> >
> >
> >
>
Re: Vote for new displayValueOnly attribute
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Grant,
it will be the same component - an HtmlInputText in the MyFaces
ext-package, all that was going to change was an additional attribute
on the component and the rendering of the component. Component stays
the same!
Kalle's suggestion would be leading to a whole new bunch of components
- still there would be one fixed underlying component.
so there is no difference in this aspect.
regards,
Martin
On 5/10/05, Grant Smith <gr...@marathon-man.com> wrote:
> Before casting a vote, I would like to seek clarity on one issue this seems
> to raise:
>
> If the displayValueOnly attibute is set, does the underlying component
> change ? for example, if I have:
>
> <x:someComponent
> binding="#{someBean.methodReturningComponent}"/>
>
> And I directly manipulate the underlying component with
> someBean.methodReturningComponent(). If I add the new
> displayValueOnly, will I still be able to directly manipulate the same
> underlying component, or will that component now be something different ?
> I'm thinking it WILL be different, but I would like clarity on that.
>
> Thanks,
> Grant.
>
> Martin Marinschek wrote:
> +1 from me...
>
> regards,
>
> Martin
>
> On 5/10/05, Thomas Spiegl <th...@gmail.com> wrote:
>
>
> +1 using Myfaces extended components
> +1 add an interface similar to UserRoleAware
> +1 adding displayValueOnly attribute
>
> What's about matching style & styleClass attributes
> (displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
> those attributes as well?
> +1 from me
>
> regards, thomas
>
> On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
>
>
> I don't want to over user the voting process, but I feel this issue should
> be sorted.
> I apologize for the ones that would be bothered by this, and here is the
> new feature I propose to vote on :
>
> - Add an interface similar to UserRoleAware, that some x: components would
> implement.
>
> - Add the matching attribute (no name decided yet, but let's use
> displayValueOnly).
> By default, displayValueOnly is false, and the components behaves as they
> do today.
> When displayValueOnly is true, no input widget is rendered. Only the text
> corresponding to the component's value is displayed.
>
> Examples :
> For inputText, inputTextarea, inputHtml, the text is displayed as if it
> where rendered by an outputText (with proper escape).
> For radio buttons, check boxes, combo boxes & list boxes, only the selected
> values are displayed.
> For inputDate, the date is rendered
>
> As suggested by Manfred, please remember that a negative binding vote on a
> *feature addition* proposal means: showstopper, that prevents the whole
> community from getting a (perhaps) valuable contribution. A -1 voter should
> at least present an alternative solution and should be willing to implement
> it himself
>
> Here is my +1 for this.
>
> Thanks,
>
> Sylvain.
>
> .
>
>
>
>
Re: Vote for new displayValueOnly attribute
Posted by Sylvain Vieujot <sv...@apache.org>.
Hello Grant,
I "think" they would be no difference from when you change another
attribute.
It's just another attribute that the renderer uses.
I'm cautious about this though, as I never use binding. So I might miss
something.
Sylvain.
On Tue, 2005-05-10 at 08:55 -0700, Grant Smith wrote:
> Before casting a vote, I would like to seek clarity on one issue this
> seems to raise:
>
> If the displayValueOnly attibute is set, does the underlying component
> change ? for example, if I have:
>
>
> <x:someComponent binding="#{someBean.methodReturningComponent}"/>
>
>
> And I directly manipulate the underlying component with
> someBean.methodReturningComponent(). If I add the new
> displayValueOnly, will I still be able to directly manipulate the same
> underlying component, or will that component now be something
> different ? I'm thinking it WILL be different, but I would like
> clarity on that.
>
> Thanks,
> Grant.
>
> Martin Marinschek wrote:
>
> > +1 from me...
> >
> > regards,
> >
> > Martin
> >
> > On 5/10/05, Thomas Spiegl <th...@gmail.com> wrote:
> >
> >
> > > +1 using Myfaces extended components
> > > +1 add an interface similar to UserRoleAware
> > > +1 adding displayValueOnly attribute
> > >
> > > What's about matching style & styleClass attributes
> > > (displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
> > > those attributes as well?
> > > +1 from me
> > >
> > > regards, thomas
> > >
> > > On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > >
> > >
> > > > I don't want to over user the voting process, but I feel this issue should
> > > > be sorted.
> > > > I apologize for the ones that would be bothered by this, and here is the
> > > > new feature I propose to vote on :
> > > >
> > > > - Add an interface similar to UserRoleAware, that some x: components would
> > > > implement.
> > > >
> > > > - Add the matching attribute (no name decided yet, but let's use
> > > > displayValueOnly).
> > > > By default, displayValueOnly is false, and the components behaves as they
> > > > do today.
> > > > When displayValueOnly is true, no input widget is rendered. Only the text
> > > > corresponding to the component's value is displayed.
> > > >
> > > > Examples :
> > > > For inputText, inputTextarea, inputHtml, the text is displayed as if it
> > > > where rendered by an outputText (with proper escape).
> > > > For radio buttons, check boxes, combo boxes & list boxes, only the selected
> > > > values are displayed.
> > > > For inputDate, the date is rendered
> > > >
> > > > As suggested by Manfred, please remember that a negative binding vote on a
> > > > *feature addition* proposal means: showstopper, that prevents the whole
> > > > community from getting a (perhaps) valuable contribution. A -1 voter should
> > > > at least present an alternative solution and should be willing to implement
> > > > it himself
> > > >
> > > > Here is my +1 for this.
> > > >
> > > > Thanks,
> > > >
> > > > Sylvain.
> > > >
> >
> >
> > .
> >
> >
>
>
Re: Vote for new displayValueOnly attribute
Posted by Grant Smith <gr...@marathon-man.com>.
Before casting a vote, I would like to seek clarity on one issue this
seems to raise:
If the displayValueOnly attibute is set, does the underlying component
change ? for example, if I have:
<x:someComponent binding="#{someBean.methodReturningComponent}"/>
And I directly manipulate the underlying component with
someBean.methodReturningComponent(). If I add the new displayValueOnly,
will I still be able to directly manipulate the same underlying
component, or will that component now be something different ? I'm
thinking it WILL be different, but I would like clarity on that.
Thanks,
Grant.
Martin Marinschek wrote:
>+1 from me...
>
>regards,
>
>Martin
>
>On 5/10/05, Thomas Spiegl <th...@gmail.com> wrote:
>
>
>>+1 using Myfaces extended components
>>+1 add an interface similar to UserRoleAware
>>+1 adding displayValueOnly attribute
>>
>>What's about matching style & styleClass attributes
>>(displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
>>those attributes as well?
>>+1 from me
>>
>>regards, thomas
>>
>>On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
>>
>>
>>> I don't want to over user the voting process, but I feel this issue should
>>>be sorted.
>>> I apologize for the ones that would be bothered by this, and here is the
>>>new feature I propose to vote on :
>>>
>>> - Add an interface similar to UserRoleAware, that some x: components would
>>>implement.
>>>
>>> - Add the matching attribute (no name decided yet, but let's use
>>>displayValueOnly).
>>> By default, displayValueOnly is false, and the components behaves as they
>>>do today.
>>> When displayValueOnly is true, no input widget is rendered. Only the text
>>>corresponding to the component's value is displayed.
>>>
>>> Examples :
>>> For inputText, inputTextarea, inputHtml, the text is displayed as if it
>>>where rendered by an outputText (with proper escape).
>>> For radio buttons, check boxes, combo boxes & list boxes, only the selected
>>>values are displayed.
>>> For inputDate, the date is rendered
>>>
>>> As suggested by Manfred, please remember that a negative binding vote on a
>>>*feature addition* proposal means: showstopper, that prevents the whole
>>>community from getting a (perhaps) valuable contribution. A -1 voter should
>>>at least present an alternative solution and should be willing to implement
>>>it himself
>>>
>>> Here is my +1 for this.
>>>
>>> Thanks,
>>>
>>> Sylvain.
>>>
>>>
>
>.
>
>
>
Re: Vote for new displayValueOnly attribute
Posted by Martin Marinschek <ma...@gmail.com>.
+1 from me...
regards,
Martin
On 5/10/05, Thomas Spiegl <th...@gmail.com> wrote:
> +1 using Myfaces extended components
> +1 add an interface similar to UserRoleAware
> +1 adding displayValueOnly attribute
>
> What's about matching style & styleClass attributes
> (displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
> those attributes as well?
> +1 from me
>
> regards, thomas
>
> On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
> > I don't want to over user the voting process, but I feel this issue should
> > be sorted.
> > I apologize for the ones that would be bothered by this, and here is the
> > new feature I propose to vote on :
> >
> > - Add an interface similar to UserRoleAware, that some x: components would
> > implement.
> >
> > - Add the matching attribute (no name decided yet, but let's use
> > displayValueOnly).
> > By default, displayValueOnly is false, and the components behaves as they
> > do today.
> > When displayValueOnly is true, no input widget is rendered. Only the text
> > corresponding to the component's value is displayed.
> >
> > Examples :
> > For inputText, inputTextarea, inputHtml, the text is displayed as if it
> > where rendered by an outputText (with proper escape).
> > For radio buttons, check boxes, combo boxes & list boxes, only the selected
> > values are displayed.
> > For inputDate, the date is rendered
> >
> > As suggested by Manfred, please remember that a negative binding vote on a
> > *feature addition* proposal means: showstopper, that prevents the whole
> > community from getting a (perhaps) valuable contribution. A -1 voter should
> > at least present an alternative solution and should be willing to implement
> > it himself
> >
> > Here is my +1 for this.
> >
> > Thanks,
> >
> > Sylvain.
>
Re: Vote for new displayValueOnly attribute
Posted by Thomas Spiegl <th...@gmail.com>.
+1 using Myfaces extended components
+1 add an interface similar to UserRoleAware
+1 adding displayValueOnly attribute
What's about matching style & styleClass attributes
(displayValueOnlyStyleClass, displayValueOnlyStyle)? Should we add
those attributes as well?
+1 from me
regards, thomas
On 5/10/05, Sylvain Vieujot <sv...@apache.org> wrote:
> I don't want to over user the voting process, but I feel this issue should
> be sorted.
> I apologize for the ones that would be bothered by this, and here is the
> new feature I propose to vote on :
>
> - Add an interface similar to UserRoleAware, that some x: components would
> implement.
>
> - Add the matching attribute (no name decided yet, but let's use
> displayValueOnly).
> By default, displayValueOnly is false, and the components behaves as they
> do today.
> When displayValueOnly is true, no input widget is rendered. Only the text
> corresponding to the component's value is displayed.
>
> Examples :
> For inputText, inputTextarea, inputHtml, the text is displayed as if it
> where rendered by an outputText (with proper escape).
> For radio buttons, check boxes, combo boxes & list boxes, only the selected
> values are displayed.
> For inputDate, the date is rendered
>
> As suggested by Manfred, please remember that a negative binding vote on a
> *feature addition* proposal means: showstopper, that prevents the whole
> community from getting a (perhaps) valuable contribution. A -1 voter should
> at least present an alternative solution and should be willing to implement
> it himself
>
> Here is my +1 for this.
>
> Thanks,
>
> Sylvain.