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
