Re: Trying an implementation "inheritWidth" function on StyledUIBase
In Basic, we might introduce debug-time parameter checking to catch people setting NaN as a value. Basic will continue to choose higher-level least code APIs. I've been unable to get you to see the line that I see between platform-specific and higher-level abstractions. If you want to expose platform-specific patterns to your users that is your choice and hopefully they won't get burned by it later. Abstraction/Encapsulation/Polymorphism/Composition/Inheritance are all standard CS practices IMO. That's why I'm pushing hard to implement them in Basic. Flex broke a lot of these rules and paid the price. For example, it doesn't matter what _width starts out as. What matters is what the width API does. Because that is what the users application is going to be coded against. Underneath, what Flash does with Sprite.width is different than what the browser does since the HTMLElement doesn't even have a width property. So yes, we pay the price of adding a bit more code to build a higher-level abstraction on top that is most likely to be portable to other platforms/runtimes. Platform-agnostic abstractions come at a price. We could have a component set with few abstractions and expose HTMLElement. But then, how portable will that be? Anyway, you can do whatever you want in Jewel. Good luck, -Alex On 12/28/19, 10:10 AM, "Carlos Rovira" wrote: Hi Alex, El sáb., 28 dic. 2019 a las 2:46, Alex Harui () escribió: > > Yes, it is fine to change them to protected. > ok will try to do > The original discussion included the topic of higher-level abstractions vs > platform-specific APIs. It seems you really want Jewel users to use a > platform-specific API, so you are welcome to allow NaN in Jewel. > after looking other ways I think is the best option, although it defeats a bit to extend from UIBase, since I'll need to copy/paste almost 80% of the code in that class. Maybe could be better to extend HTMLElementWrapper instead. > > If I were to implement something similar in Basic, I would first try to > understand how often it is needed and where it is needed because I would > not want to implement something on UIBase "just-in-case". The problem is that JS platform (and one day other ones too) will requiere to deal with its particularities. I don't like the way browsers works using "strings" and having default strange options, but doing serious work with styling reveal you need manage width and height to its defaults some times to make sizing adapt in the right way. So I have clear in mind that this particularity in browsers must to be solved. I think the NaN check is something right, since is the nature of the platform. I understand you and Harbs about the ideal concepts, but sometimes ideal concepts does not work, since others make things in a weird way, like in browsers. I think what we need to do is to try to manage singularities as best as we can, and for using NaN to default to browsers is the right way. Moreover: If you have a width not set in Royale, _width is NaN. That means in JS element.style.width does not exists, and that means width is "auto". Then setting width to 200 makes _width = 200 and this sets element.style.width = "200px". Then setting width to NaN makes element.style.width = "NaNpx" what is a wrong value. I think you guys should fix that in some way or another. That implies introduce more code, now it's a matter if you make that code useful for users or just signal an ilegal state. > If it was primarily needed on, say, a TitleWindow/Panel thing, that > TitleWindow might get a higher-level API like 'displayState" which could > have the values "minimized, maximized, sizedToContent". The underlying > code behind displayState would call the sizeToContent utility function. > And then it could be used in ternary expressions. And I might implement > that on a subclass of TitleWindow (TitleWindowWithDisplayState) so that not > all TitleWindows/Panels carry that API. > I think that seems to me lots of code, and not PAYG. As well seems to me something users could never reach to it, since people coming from JS will search for a away to remove "element.style.width" > > One of the things I think you are running into with inheritWidth (which > doesn't actually get set to inherit when you set to null, IMO, so I'm not a > fan of the name), is that in Royale we have elected to make width a Number > where in the browser it is a String. Yes, I think using Number is the right way to go. Using Strings is what browsers do under the hood, and we need to translate in an efficient way. > If you want to expose browser APIs to Jewel users, you may want to come up
Re: Trying an implementation "inheritWidth" function on StyledUIBase
Hi Alex, El sáb., 28 dic. 2019 a las 2:46, Alex Harui () escribió: > > Yes, it is fine to change them to protected. > ok will try to do > The original discussion included the topic of higher-level abstractions vs > platform-specific APIs. It seems you really want Jewel users to use a > platform-specific API, so you are welcome to allow NaN in Jewel. > after looking other ways I think is the best option, although it defeats a bit to extend from UIBase, since I'll need to copy/paste almost 80% of the code in that class. Maybe could be better to extend HTMLElementWrapper instead. > > If I were to implement something similar in Basic, I would first try to > understand how often it is needed and where it is needed because I would > not want to implement something on UIBase "just-in-case". The problem is that JS platform (and one day other ones too) will requiere to deal with its particularities. I don't like the way browsers works using "strings" and having default strange options, but doing serious work with styling reveal you need manage width and height to its defaults some times to make sizing adapt in the right way. So I have clear in mind that this particularity in browsers must to be solved. I think the NaN check is something right, since is the nature of the platform. I understand you and Harbs about the ideal concepts, but sometimes ideal concepts does not work, since others make things in a weird way, like in browsers. I think what we need to do is to try to manage singularities as best as we can, and for using NaN to default to browsers is the right way. Moreover: If you have a width not set in Royale, _width is NaN. That means in JS element.style.width does not exists, and that means width is "auto". Then setting width to 200 makes _width = 200 and this sets element.style.width = "200px". Then setting width to NaN makes element.style.width = "NaNpx" what is a wrong value. I think you guys should fix that in some way or another. That implies introduce more code, now it's a matter if you make that code useful for users or just signal an ilegal state. > If it was primarily needed on, say, a TitleWindow/Panel thing, that > TitleWindow might get a higher-level API like 'displayState" which could > have the values "minimized, maximized, sizedToContent". The underlying > code behind displayState would call the sizeToContent utility function. > And then it could be used in ternary expressions. And I might implement > that on a subclass of TitleWindow (TitleWindowWithDisplayState) so that not > all TitleWindows/Panels carry that API. > I think that seems to me lots of code, and not PAYG. As well seems to me something users could never reach to it, since people coming from JS will search for a away to remove "element.style.width" > > One of the things I think you are running into with inheritWidth (which > doesn't actually get set to inherit when you set to null, IMO, so I'm not a > fan of the name), is that in Royale we have elected to make width a Number > where in the browser it is a String. Yes, I think using Number is the right way to go. Using Strings is what browsers do under the hood, and we need to translate in an efficient way. > If you want to expose browser APIs to Jewel users, you may want to come up > with a whole new set of base classes that more directly mimic the browser > API. Then setting width to NaN or null wouldn't be a factor. Folks would > be setting the value to a string like "auto" instead. but that will be unaligned with _width value. If a user makes element.style.width = "auto", (or = null that is the same), _width still is in a incorrect value (maybe 50, 100, 200 or NaN). We should try to avoid make users to change browsers values bypassing royale official way to manage it. > However I think there are good reasons for most other Royale components to > make width a Number. I think there are way more calculations of width > based on Numbers, although I can imagine a component set where width is > always determined by constraints and not values. I think it is very rare > for folks to need to switch random components from sizeToParent to > sizeToContent, and that the components that need that more frequently can > expose that choice in subclasses for those who need to manage that value > via expressions. > I think most of the times this problems is for advanced users trying to make components. But we are to young to say 95% of the users will not need to remove width or height. But anyone trying to do serious development with Royale will find this sooner or later, then you and Harbs will have this conversation again talking about is not right to put " isNaN(value) ? null :" since is not legal, and that will make that users try to go the same I use, that is change underlaying browser style width values and making royale components state not aligned to it. HTH Carlos > > My 2 cents, > -Alex > > El vie., 27 dic. 2019 a las 14:00, Harbs () >
Re: Trying an implementation "inheritWidth" function on StyledUIBase
On 12/27/19, 7:02 AM, "Carlos Rovira" wrote:
Hi Harbs,
I assume your implementation is part of the StyledUIBase class.
One thing I see is _width and _height are private (as well the rest of
underscored vars in UIBase), should be change it to protected?
Yes, it is fine to change them to protected.
if you consider NaN to be error prone, we should consider other option,
since for me the important part here is the flexibility/usability of the
solution through ternary/binding constructions in MXML or AS3 code by users.
The original discussion included the topic of higher-level abstractions vs
platform-specific APIs. It seems you really want Jewel users to use a
platform-specific API, so you are welcome to allow NaN in Jewel.
If I were to implement something similar in Basic, I would first try to
understand how often it is needed and where it is needed because I would not
want to implement something on UIBase "just-in-case". If it was primarily
needed on, say, a TitleWindow/Panel thing, that TitleWindow might get a
higher-level API like 'displayState" which could have the values "minimized,
maximized, sizedToContent". The underlying code behind displayState would call
the sizeToContent utility function. And then it could be used in ternary
expressions. And I might implement that on a subclass of TitleWindow
(TitleWindowWithDisplayState) so that not all TitleWindows/Panels carry that
API.
One of the things I think you are running into with inheritWidth (which doesn't
actually get set to inherit when you set to null, IMO, so I'm not a fan of the
name), is that in Royale we have elected to make width a Number where in the
browser it is a String. If you want to expose browser APIs to Jewel users, you
may want to come up with a whole new set of base classes that more directly
mimic the browser API. Then setting width to NaN or null wouldn't be a factor.
Folks would be setting the value to a string like "auto" instead. However I
think there are good reasons for most other Royale components to make width a
Number. I think there are way more calculations of width based on Numbers,
although I can imagine a component set where width is always determined by
constraints and not values. I think it is very rare for folks to need to
switch random components from sizeToParent to sizeToContent, and that the
components that need that more frequently can expose that choice in subclasses
for those who need to manage that value via expressions.
My 2 cents,
-Alex
El vie., 27 dic. 2019 a las 14:00, Harbs () escribió:
> I would implement it differently:
>
> COMPILE::SWF//assuming this works in SWF
> public function
> inheritDimensions(width:Boolean=true,height:Boolean=true):void{
> if(width){
> this.width = NaN;
> }
> if(height){
> this.height = NaN;
> }
> }
> COMPILE::JS
> public function
> inheritDimensions(width:Boolean=true,height:Boolean=true):void{
> if(width){
> _width = _explicitWidth = _percentWidth = NaN;
> this.positioner.style.width = null;
> }
> if(height){
> _height = _explicitHeight = _percentHeight = NaN;
> this.positioner.style.height = null;
> }
> // do we need to dispatch an event?
> }
>
> > 1.- *I loose ternary operato**rs*. I mean expressions like:
> *button.width
> > = **condition ? 200 : NaN;*
>
> Like I already said, I think this kind of code is bug-prone, so I don’t
> share your concern.
>
> > 2.- *Lose opportunity to do binding in MXML*. I mean expressions like:
> > *button.width
> > = "{condition ? 200 : NaN}”*
>
> You can create a subclass of Button in your application with custom
> setters if this is a concern.
>
> > 3.- *Duplicating `style.width` instruction*. In setWidth the
> > positioner.style.width is set to "NaNpx" then we reach the
> > "setInheritWidth" to remove to null. No collateral problems, but just
> seems
> > poor code.
>
> My implementation solves this problem. Ideally I’d like to solve the
> problem of accessing private vars from utility functions, but that’s
> another topic.
>
>
> HTH,
> Harbs
> > On Dec 27, 2019, at 2:03 PM, Carlos Rovira
> wrote:
> >
> > public function setInheritWidth(noEvent:Boolean = false):void
> > {
> > setWidth(NaN);//we need _width = NaN
> > COMPILE::JS
> > {
> > this.positioner.style.width = null;//remove style.width after setWidth
> sets
> > _width to "NaNpx" for JS
> > }
> > }
>
>
--
Carlos Rovira
Re: Trying an implementation "inheritWidth" function on StyledUIBase
Hi Harbs,
I assume your implementation is part of the StyledUIBase class.
One thing I see is _width and _height are private (as well the rest of
underscored vars in UIBase), should be change it to protected?
if you consider NaN to be error prone, we should consider other option,
since for me the important part here is the flexibility/usability of the
solution through ternary/binding constructions in MXML or AS3 code by users.
El vie., 27 dic. 2019 a las 14:00, Harbs () escribió:
> I would implement it differently:
>
> COMPILE::SWF//assuming this works in SWF
> public function
> inheritDimensions(width:Boolean=true,height:Boolean=true):void{
> if(width){
> this.width = NaN;
> }
> if(height){
> this.height = NaN;
> }
> }
> COMPILE::JS
> public function
> inheritDimensions(width:Boolean=true,height:Boolean=true):void{
> if(width){
> _width = _explicitWidth = _percentWidth = NaN;
> this.positioner.style.width = null;
> }
> if(height){
> _height = _explicitHeight = _percentHeight = NaN;
> this.positioner.style.height = null;
> }
> // do we need to dispatch an event?
> }
>
> > 1.- *I loose ternary operato**rs*. I mean expressions like:
> *button.width
> > = **condition ? 200 : NaN;*
>
> Like I already said, I think this kind of code is bug-prone, so I don’t
> share your concern.
>
> > 2.- *Lose opportunity to do binding in MXML*. I mean expressions like:
> > *button.width
> > = "{condition ? 200 : NaN}”*
>
> You can create a subclass of Button in your application with custom
> setters if this is a concern.
>
> > 3.- *Duplicating `style.width` instruction*. In setWidth the
> > positioner.style.width is set to "NaNpx" then we reach the
> > "setInheritWidth" to remove to null. No collateral problems, but just
> seems
> > poor code.
>
> My implementation solves this problem. Ideally I’d like to solve the
> problem of accessing private vars from utility functions, but that’s
> another topic.
>
>
> HTH,
> Harbs
> > On Dec 27, 2019, at 2:03 PM, Carlos Rovira
> wrote:
> >
> > public function setInheritWidth(noEvent:Boolean = false):void
> > {
> > setWidth(NaN);//we need _width = NaN
> > COMPILE::JS
> > {
> > this.positioner.style.width = null;//remove style.width after setWidth
> sets
> > _width to "NaNpx" for JS
> > }
> > }
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Trying an implementation "inheritWidth" function on StyledUIBase
I would implement it differently:
COMPILE::SWF//assuming this works in SWF
public function inheritDimensions(width:Boolean=true,height:Boolean=true):void{
if(width){
this.width = NaN;
}
if(height){
this.height = NaN;
}
}
COMPILE::JS
public function inheritDimensions(width:Boolean=true,height:Boolean=true):void{
if(width){
_width = _explicitWidth = _percentWidth = NaN;
this.positioner.style.width = null;
}
if(height){
_height = _explicitHeight = _percentHeight = NaN;
this.positioner.style.height = null;
}
// do we need to dispatch an event?
}
> 1.- *I loose ternary operato**rs*. I mean expressions like: *button.width
> = **condition ? 200 : NaN;*
Like I already said, I think this kind of code is bug-prone, so I don’t share
your concern.
> 2.- *Lose opportunity to do binding in MXML*. I mean expressions like:
> *button.width
> = "{condition ? 200 : NaN}”*
You can create a subclass of Button in your application with custom setters if
this is a concern.
> 3.- *Duplicating `style.width` instruction*. In setWidth the
> positioner.style.width is set to "NaNpx" then we reach the
> "setInheritWidth" to remove to null. No collateral problems, but just seems
> poor code.
My implementation solves this problem. Ideally I’d like to solve the problem of
accessing private vars from utility functions, but that’s another topic.
HTH,
Harbs
> On Dec 27, 2019, at 2:03 PM, Carlos Rovira wrote:
>
> public function setInheritWidth(noEvent:Boolean = false):void
> {
> setWidth(NaN);//we need _width = NaN
> COMPILE::JS
> {
> this.positioner.style.width = null;//remove style.width after setWidth sets
> _width to "NaNpx" for JS
> }
> }
Re: Trying an implementation "inheritWidth" function on StyledUIBase
In Framework, was as a result of these days discussion about width = NaN in other threads. Search for "inheritWidth" or "sizeWidthToContent"
Trying an implementation "inheritWidth" function on StyledUIBase
Hi Harbs and Alex,
trying an implementation of "inheritWidth" function
public function setInheritWidth(noEvent:Boolean = false):void
{
setWidth(NaN);//we need _width = NaN
COMPILE::JS
{
this.positioner.style.width = null;//remove style.width after setWidth sets
_width to "NaNpx" for JS
}
}
results in usage like this:
if(condition) {
button.width = 200;
} else {
button.setInheritWidth();
}
Two things I don't like from this solution:
1.- *I loose ternary operato**rs*. I mean expressions like: *button.width
= **condition ? 200 : NaN;*
2.- *Lose opportunity to do binding in MXML*. I mean expressions like:
*button.width
= "{condition ? 200 : NaN}"*
3.- *Duplicating `style.width` instruction*. In setWidth the
positioner.style.width is set to "NaNpx" then we reach the
"setInheritWidth" to remove to null. No collateral problems, but just seems
poor code.
As well the meaning of this solution does not end to satisfy my since we
are really not inherit the value but setting it to a default value (imposed
just by JS platform).
As well other option was "*sizeWidthToContent*" that seems to have problems
1.- and 2.- (at least, but maybe 3.- too) and be a concrete use case
solution, I mean, not an API to get a value set, that is what I expect here
(and suppose other users too).
Thoughts?
--
Carlos Rovira
http://about.me/carlosrovira
