Hi Kalle,

thanks for your feedback - you will need to decide on -1 or 0 and be
willing to implement the feature your way if your decision is staying
-1.

regards,

Martin

On 5/10/05, Korhonen, Kalle <[EMAIL PROTECTED]> wrote:
> ________________________________
>         From: Sylvain Vieujot [mailto:[EMAIL PROTECTED]
>         Subject: Vote for new displayValueOnly attribute
>         - 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
> --- (could you please you plain text when posting your messages?) ---
> 
> -1/0 from me, and I don't mean it as a showstopper, but I think there's
> an alternative way to implement this. I propose to implement a new
> "editable" family of components, i.e. editableText, editableTextarea,
> editableHtml which are rendered either as input controls or as output
> controls depending on the value of their "readonly" attribute. It solves
> the semantical problem of rendering inputText as outputText and doesn't
> add new attributes to components.
> 
> Kalle
> 
> > -----Original Message-----
> > From: Korhonen, Kalle
> > Sent: Thursday, May 05, 2005 1:01 PM
> > To: 'MyFaces Development'
> > Subject: RE: [Myfaces-develop] New feature suggestion : Edit mode
> >
> > Mmm.. good point, if we kept inputText as is (and its
> > readonly is reserved for html input attribute readonly), but
> > implemented x:editableText with attribute readonly, which
> > would then render either inputText or outputText, we wouldn't
> > need to add new attributes and would avoid the semantical
> > problem of rendering inputText as outputText. A good compromise, no?
> >
> > Kalle
> 
>

Reply via email to