In case of train it's readOnly that's more relevant than disabled, but switching from one to another won't be too hard. I could not think of a real world usage of a disabled step either when coding it as it more or less meant that the process could not be completed.
So, +1. Regards, ~ Simon On 10/16/06, Arjuna Wijeyekoon <[EMAIL PROTECTED]> wrote:
+1 to use just "disabled" and to drop "readOnly" On 10/16/06, Gabrielle Crawford <[EMAIL PROTECTED]> 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 > > > > > > > > >
