I agree with Geoff's suggestion. Changing the behaviour of setVisible would impact a lot of programs as well. Do it Geoff's way. Bill Powell --- Geoff Crawford <[EMAIL PROTECTED]> wrote:
> At 03:48 PM 9/28/2007, P T Withington wrote: > >Please comment on this proposed API change which we > would like to > >implement for 4.1 (RingDing). > > > >Problem: > > > >SetVisible currently accepts null|false|true, where > null has the > >special meaning 'let data control visibility'. > This is a poor > >interface because it is too easy to accidentally > pass a value of > >null. The `visible` attribute cannot be used to > ask programmatically > >if a view is visible or not for the data-bound > case. > > > >Proposal: > > > >1. Add a new attribute `visibility` that is a > read/write String and > >has values 'visible', 'hidden', 'collapse'. This > is implemented by a > >setter that maps 'visible' -> true, 'hidden' -> > false, 'collapse' -> > >null in the old mechanism. > > > >2. Deprecate `setVisible`: issue a warning telling > how to get the > >same effect with `setVisibility`. Make `visible` > reflect the actual > >state of the view (do not store the value passed to > `setVisible`). > > > >3. In the next major release make `setVisible` a > no-op so that > >`visible` is read-only and reflects the actual > state of the view > >(i.e., if `visibility` is 'collapse', it will be > true when there is > >data and false otherwise). > > > >Evaluation: > > > >Pro: 1) Replaces an error-prone interface. 2) > Solves the problem of > >programmatically query a view's visible state. 3) > Uses an interface > >that is compatible with CSS. > > > >Con: 1) Programs will have to be updated to use > the new API. > > I understand the need, that's valid. But breaking > old code > this way is not desirable - I've got an ERP system > we're building > that would be dramatically affected. > > Suggestion: Make the new attribute and method as > described. > And also make the method work as stated, basically > it > adjusts the old visible attribute as before. > However, > don't make the old visible read-only - keep it and > let the old behavior work as well. It would only > mean > you'd have to add to the visible code something that > also set "visibility" as well. That would give > two paths to essentially the same thing with neither > one being broken by the new functionality. Then > stop publishing the old method in the documentation. > Old code would work, but anyone new to the > environment > wouldn't be aware of the old methodology. > > > ======================================================================= > Geoff Crawford Phone: > (973) 361 - 4224 > Innov8 Computer Solutions, LLC FAX: > (973) 537 - 6946 > 711 Route 10 East, Suite 204 Email: > [EMAIL PROTECTED] > Randolph NJ 07869 Web: > http://www.processwareerp.com > > ProcessWare ERP for the Chemical > Industry > > > ____________________________________________________________________________________ Check out the hottest 2008 models today at Yahoo! Autos. http://autos.yahoo.com/new_cars.html
