I have not used other frameworks. What other multitarget SDK's use NaN to unset dimensional Numbers?
Constants don't work so well in MXML. You have to bind to them, or use the actual literal value. IMO, while NaN is an allowed value of percentWidth/explicitWidth, there has never been an intention to allow application developers to use NaN as a value set to those properties. UIBase does replicate the logic form Flex that setting percentWidth sets explicitWidth to NaN and vice versa. Supporting NaN as a set value would add more code to UIBase for what is not a mainstream usage. We know we can solve this problem with a utils function and that will be more PAYG and less likely to result in implementation issues on future runtimes. The utils function would also clear explicitWidth as well. My 2 cents, -Alex On 12/19/19, 6:14 PM, "Greg Dove" <[email protected]> wrote: ' But the meaning of percentWidth=NaN is not clear. ' The way that seems usual in other multitarget sdks in this type of situation is to 'abstract' the value being used instead of literal NaN. We could use a public static const for the 'unset' value and tell developers to use that. The name of that adds the semantic meaning to the code as well. And it can be set up to cost nothing in release builds because of inlining. myComponent.percentWidth = DimensionConsts.PERCENT_VALUE_DISABLED; It is more verbose for sure, but much clearer whether it might be -1 or NaN for a specific target. I don't think that precludes providing other useful utility functions which might do different things (like unset size-To-Parent on both dimensions internally) With the existing code it already assumes that NaN can be an assigned value for both our current targets. So this seems like a bugfix to me, because if NaN is an expected possible value (and it seems to be because it is already being tested in both targets), then setting width style to 'NaN%' is a bug in my view. I'm just sharing what looks obvious to me - 'first glance'. So maybe I am missing some much deeper interpretation of all this. Anyhow, I will leave it to others to comment further. On Fri, Dec 20, 2019 at 1:35 PM Alex Harui <[email protected]> wrote: > IMO, if the application developer is going to be encouraged to set > foo.percentWidth=NaN in their code, we might have a hard time implementing > that on some future runtime that offers a percentWidth API but doesn't > support NaN. And then the app will not easily migrate to that future > runtime. Flash is a clue. It is a different runtime and doesn't support > NaN as a value to width. Who knows that some future runtime will require? > > The "meaning" of percentWidth=100 is pretty clear. It means you want > something to stretch the width of its parent. But the meaning of > percentWidth=NaN is not clear. That's why I keep focusing on what the > higher-level objective is, not the browser-specific way you want to > accomplish that higher-level objective. I'm pretty sure the higher-level > objective is to switch a component from being sized to its parent to being > sized to its content. Please propose an API with a name that describes > that objective. Maybe something like > org.apache.royale.utils.sizeToContent(child:IUIBase); > > I'd rather leave the topic of change events to another thread. I'd prefer > to try to get folks to agree that higher-level abstractions will serve > Royale better than replicating platform-specific patterns that we can't > guarantee will work on all platforms and that don't have a clear meaning. > > Thanks, > -Alex > > On 12/19/19, 2:49 PM, "Greg Dove" <[email protected]> wrote: > > On first glance, that for me that seems an regular bugfix, because it > looks > to be fixing something not working that is intended to actually work. > > I'd also wonder about the inconsistency between the two targets for > avoiding to dispatch events when the same value is set twice (although > the > 'equals' trap for that will not catch NaNs). > It is standard practice elsewhere I think to include this avoidance in > setters for anything that dispatches 'change' like events (so a change > is > *really* a change). > > > > On Fri, Dec 20, 2019 at 11:33 AM Carlos Rovira < > [email protected]> > wrote: > > > Hi Alex, > > > > I think what I want is not what you think I want :) > > > > "Setting Sprite.width to NaN is not allowed in the Flash runtime" > > > > That will not happen. The actual code for "percentWidth": > > > > public function set percentWidth(value:Number):void > > { > > COMPILE::SWF { > > if (_percentWidth == value) > > return; > > if (!isNaN(value)) > > _explicitWidth = NaN; > > _percentWidth = value; > > } > > COMPILE::JS { > > this._percentWidth = value; > > this.positioner.style.width = value.toString() + '%'; > > if (!isNaN(value)) > > this._explicitWidth = NaN; > > } > > dispatchEvent(new Event("percentWidthChanged")); > > } > > > > The code I want in percentWidth: > > > > public function set percentWidth(value:Number):void > > { > > COMPILE::SWF { > > if (_percentWidth == value) > > return; > > if (!isNaN(value)) > > _explicitWidth = NaN; > > _percentWidth = value; > > } > > COMPILE::JS { > > this._percentWidth = value; > > this.positioner.style.width = isNaN(value) ? null : value.toString() > + '%'; > > if (!isNaN(value)) > > this._explicitWidth = NaN; > > } > > dispatchEvent(new Event("percentWidthChanged")); > > } > > > > Do you see that this is not about the general/global Royale API? is > just a > > fix for JS specific platform. > > IOW, is just adding to "COMPILE::JS" the code "isNaN(value) ? null > : " > > > > So we are not baking any "behavior" or "particular semantic" in > Royale > > global code. > > > > Think in what I said in my latest email: "what happens in JS if we > pass NaN > > to percentWidth"? > > what value will be in "this.positioner.style.width" at the end of the > > method execution? > > > > Make more sense now? > > > > Thanks > > > > Carlos > > > > > > > > El jue., 19 dic. 2019 a las 19:57, Alex Harui > (<[email protected]>) > > escribió: > > > > > Carlos, > > > > > > The browser is only one runtime. Setting Sprite.width to NaN is > not > > > allowed in the Flash runtime. What will the next runtime's > requirements > > be? > > > Width as a style is a platform-specific API that, by deleting it, > AFAICT, > > > has the meaning "I want this thing sized to content instead of > sized to > > > parent". IMO, we do not want to bake platform-specific API usage > into > > our > > > base classes. > > > > > > Feel free to make private things protected in UIBase, but please > do not > > > bake platform-specific API usage into Basic. > > > > > > Thanks, > > > -Alex > > > > > > On 12/19/19, 10:49 AM, "Carlos Rovira" <[email protected]> > wrote: > > > > > > Hi Alex, > > > > > > I can try to add to StyledUIBase instead to UIBase. I think > I'll need > > > to > > > make some UIBase vars protected instead of private to be able > to do > > so > > > > > > Anyway, I don't think this is "just-in-case" code. Is a real > value > > > width > > > can take in Javascript platform. The portability of the code > is not > > > affected this way since is the standard in browsers: setting > style > > > properties to null removes the property in all browsers. If we > set > > > width to > > > NaN in AS3, what does the browser? > > > > > > I think the problem could be that you're identifying this case > with a > > > particular layout scenario of a concrete component. It's not > the > > case, > > > I > > > found this issue other times when working on Royale, and is > not about > > > to > > > make a component to size as the parent or size as its content, > is > > > about to > > > allow to assign a value in a concrete property. > > > > > > I found that need around three times working on ComboBox, > DateField, > > > and > > > now in DataGrid. I solved hardcoding the style.width in that > concrete > > > code, > > > but I think is not the right solution to add code of that kind > in the > > > framework. > > > > > > The fact other users does not find this problem is maybe that > a part > > > that > > > we are few yet in royale, and people is not going to that lower > > level, > > > is > > > that me and you are the only ones working in components most > of the > > > time, > > > And between both, maybe I'm doing more styling work with css, > layouts > > > and > > > other kind of visuals. > > > > > > The solution of adding to StyledUIBase seems to me not the > right one, > > > since > > > we end adding lots of code (override all that width and height > > > methods) for > > > something that is just a particular JS case that all users of > UIBase > > > should > > > have available, and I'm afraid that some components that are > coming > > > from > > > other basic components (like Group or DataContiner) will not > have > > that > > > properties, and I'll need to add the same code (again) to all > that > > > classes. > > > > > > I think if we are so strict in this kind of cases, we are not > using > > ok > > > PAYG, moreover when as I said before I think we are > interpreting PAYG > > > not > > > right in this concrete case that is just part of the JS > platform > > still > > > not > > > considered in Basic implementation. > > > > > > After this explanation, do you still think I need to add all > that > > code > > > to > > > StyledUIBase? Or maybe could it be better to add directly to > UIBase > > > the NaN > > > case, so the rest of code in Royale could have this missing JS > > > implementation? > > > > > > Thanks! :) > > > > > > Carlos > > > > > > > > > > > > > > > > > > El jue., 19 dic. 2019 a las 17:34, Alex Harui > > > (<[email protected]>) > > > escribió: > > > > > > > IMO, your proposed change adds code "just-in-case" someone > wants to > > > change > > > > from sizing-to-parent to sizing-to-content. We've written > lots of > > > > FlexJS/Royale code over the years that works just fine > without that > > > > change. That implies to me that this scenario is not a > "standard > > > case". > > > > > > > > If you want to build that in as a standard case to Jewel, > that's > > > fine. > > > > Jewel does not have to be as lightweight as Basic. > > > > > > > > If, over more years, we hear more folks with these cases for > Basic > > > then we > > > > can consider adding it to Basic, but I would probably just > add a > > > Utils > > > > function like "sizeToContent()" that "does the right > thing". In > > some > > > > component sets, sizing to content might force a measuring > API to > > > run, for > > > > example. > > > > > > > > IMO, it is better to think of the "semantics" or "meaning" > of some > > > code so > > > > that we don't bake platform-specific patterns into the > framework. > > > We want > > > > the framework to be easily portable to other runtimes > someday. > > > > > > > > My 2 cents, > > > > -Alex > > > > > > > > On 12/19/19, 2:47 AM, "Carlos Rovira" < > [email protected]> > > > wrote: > > > > > > > > Hi Alex, > > > > > > > > My perception for this particular case in the JS > platform we > > are > > > > missing a > > > > standard case. > > > > To try to make a comparison is like if we could add to > an int > > > var any > > > > number except "0". > > > > > > > > IMHO, the PAYG concept does not apply since Basic (and > any > > other > > > set) > > > > should need in some cases to remove width (so browsers > apply > > the > > > > default) > > > > and that make JS set "width=null'" to remove it. > > > > IOW, we are not translating correctly to JS in all > possible > > > cases. > > > > > > > > In other words we have in UIBase this code: > > > > > > > > this.positioner.style.width = value.toString() + '%'; > > > > > > > > I tested UIBase with this change worked: > > > > > > > > this.positioner.style.width = isNaN(value) ? null : > > > value.toString() + > > > > 'px'; > > > > > > > > It's ok to do this change? > > > > > > > > Thanks > > > > > > > > Carlos > > > > > > > > > > > > > > > > El jue., 19 dic. 2019 a las 3:57, Alex Harui > > > (<[email protected] > > > > >) > > > > escribió: > > > > > > > > > Basic has the most minimal support for changing things. > > > Supporting > > > > change > > > > > takes more code, so because of PAYG, only the most > expected > > > change > > > > are > > > > > supported. > > > > > > > > > > What is the "semantics" behind removing percentWidth? > That > > > you want > > > > > something to go back to sizing to its content? One > option is > > > that > > > > could be > > > > > a utils function like sizeToContent(widget:IUIBase) > that > > knows > > > how to > > > > > manipulate a particular component set's widgets. What > needs > > > to be > > > > done to > > > > > a component might depend on the component set. > > > > > > > > > > My 2 cents, > > > > > -Alex > > > > > > > > > > On 12/18/19, 2:32 PM, "Carlos Rovira" < > > [email protected] > > > > > > > > wrote: > > > > > > > > > > Hi, > > > > > > > > > > I think I had this issue at other time. > > > > > > > > > > Let's say we have a container where percentWidth is > > > configured > > > > to 100, > > > > > so > > > > > in html this is: > > > > > > > > > > <div style="width:100%"/> > > > > > > > > > > then we need to remove style="width:100%" so we > end with: > > > > > > > > > > <div/> > > > > > > > > > > In royale we can do container.percentWidth=100, but > > > there's no > > > > way back > > > > > right? > > > > > we can't do container.percentWidth = NaN or > undefined. > > > > > > > > > > Or I'm missing something? > > > > > > > > > > Thanks > > > > > > > > > > > > > > > -- > > > > > Carlos Rovira > > > > > > > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915474335&sdata=NwOqzkTYRBtUczCJdbrat0ns%2FooJQ1kwvZKf7%2FQOt%2Fw%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > > > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915484317&sdata=BSw0%2FIs94ziSfk%2Fe1xm%2BH6loda9pQTzxWtMVEWPOWLY%3D&reserved=0 > > > > > > > > > > > > > > > > > > -- > > > Carlos Rovira > > > > > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915484317&sdata=BSw0%2FIs94ziSfk%2Fe1xm%2BH6loda9pQTzxWtMVEWPOWLY%3D&reserved=0 > > > > > > > > > > > > > -- > > Carlos Rovira > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C495907a289f44b5fd9d908d784f2647e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637124048915484317&sdata=BSw0%2FIs94ziSfk%2Fe1xm%2BH6loda9pQTzxWtMVEWPOWLY%3D&reserved=0 > > > > >
