incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arjuna Wijeyekoon" <>
Subject Re: commandNavigationItem - recommend changing 2 properties
Date Mon, 16 Oct 2006 20:23:06 GMT
+1 to use just "disabled" and to drop "readOnly"

On 10/16/06, Gabrielle Crawford <> wrote:
> Hi,
> I have 3 thoughts about this.
> 1] I think navPane and breadcrumbs clearly only need 1 attribute. I
> actually thought they basically treat readOnly and disabled the same.
> 2] I can't think of a real world use case for using both attributes on
> train, if anyone on this list has a real world use case can they post it?
> 3] +1 to using the attribute name "disabled" over "readOnly". Users
> around here have no problem understanding if a link/button/etc is
> 'disabled', they don't understand 'readOnly'.
> Thanks,
> Gab
> Pavitra Subramaniam wrote:
> >Hello all,  The 'commandNavigationItem' supports 2 properties 'disabled'
> and 'readOnly'.The tag documentationdescribes these as follows.  disabled -
> If value is "true", the component becomes non-interactive. Otherwise,the
> default value is "false" and component assumes its expected behavior.
> readOnly - whether the item should be rendered as readOnly. Depending on the
> renderer the text may or may not appear when readOnly is true.  The train
> component uses both these properties, but I have found that there is not
> much difference between these 2 properties when it comes to rendering (at
> least in the train's case). There are 2 other components (navigationPane and
> breadCrumbs) that usecommandNavItemas it's nodestamp, butthey onlyuse
> 'readOnly' attribute. I would like to know ifthere are any objections
> tomaking the following changes.  1. Remove the'disabled' property 2. Rename
> the 'readOnly' property to 'disabled'  The reasons for removing 'disabled'
> are the following. 1. If a stop is disabled for the entire life of the
> train, it can be excluded from the model and hence not displayed at all. 2.
> If the stop is disabled only for a short time within the normal flow of the
> train, then it can be rendered as unvisited - readOnly, until some condition
> enables it. I am not sure if any one has seen other use cases for the
> 'disabled' attribute that requires us to keep it around.  If we remove
> 'disabled' thenwe should rename 'readOnly' to 'disabled', since most users
> intuitively think of links/stops/navItems as being enabled (or disabled)more
> thanthey being readOnly (or not).It is much source of confusion today.  Any
> comments?  Thanks  Pavitra
> >
> >
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message