The current scheme can be made to work, I just have to add an API to read the "intended visibility" value so that the window component can look at it in a kosher way.
But Tucker's right, it would be better to have two different names for the desired and actual computed value... On 5/3/07, John Sundman <[EMAIL PROTECTED]> wrote:
Do I hear a proposal to amend, or should I try to better explain how it currently works? Thanks, jrs On May 3, 2007, at 7:45 AM, P T Withington wrote: > 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] >
-- Henry Minsky Software Architect [EMAIL PROTECTED]
