Ya, I think you can go ahead.

Thanks,

Gab

Pavitra Subramaniam wrote:
So shall I create a JIRA issue for this? 

Thanks
- Pavitra

-----Original Message-----
From: Simon Lessard [mailto:[EMAIL PROTECTED]] 
Sent: Monday, October 16, 2006 2:40 PM
To: [email protected]
Subject: Re: commandNavigationItem - recommend changing 2 properties

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
      

        

      
    


  

Reply via email to