Gak. Trinary-valued attributes that are magically different when
read and written.
I wish we had designed this so that there was a `visibility`
attribute that was one of 'visible', 'hidden', or 'auto' that says
how you want visibility to be computed. Then the `visible` attribute
could be read-only and either `true` or `false`.
On 2007-05-02, at 21:48 EDT, Henry Minsky wrote:
I'm looking at a bug report about behavior of the "visible=null"
attribute on a view.
(http://jira.openlaszlo.org/jira/browse/LPP-3643)
This used to be called "datacontrolsvisibility", but that has been
deprecated and now
setting visible=null is supposed to have the same affect as
datacontrolsvisibility=true
I don't think this ever worked in LZX code, since the schema only
supports 'true' or 'false' for values of the 'visible' attribute on
<view> in LZX. Calling setVisible(null) from script would have been
the only API access.
Once I implemented the proper schema data typing for the 'visible'
attribute, I came to the actual bug the user was reporting, which is
that the <window> component doesn't obey
the visible=null option.
The setter for LzView.setVisible(), doesn't actually set this.visible.
It instead sets an internal flag called this.__LZvisibleSet which
serves to remember what the intended visibility behavior was. The
routine LzView.__LZupdateShown updates the value of this.visible
to it's actual final computed value.
The <window> component needs to know what the intended value of
visible is (not the actual value). Since this is an internal property
(by convention of how it's named, __LZvisibleSet) the <window>
component shouldn't really be looking at it.
So I guess we need an API to return the value that setVisible() was
called with? I propose
an implementation
function whatWasVisibleSupposedToBe() {
return this.__LZvisibleSet;
}
I think I need a more informative name for this accessor though.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
