Hi Alex,
El sáb., 28 dic. 2019 a las 2:46, Alex Harui (<aha...@adobe.com.invalid>)
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 (<harbs.li...@gmail.com>)
> 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 <
> carlosrov...@apache.org>
> > 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
>
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C39715e51de7749703a2b08d78addbb1a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637130557240362094&sdata=yeDSDeCKTNK1jeg8unPRrxVTKMvd8mmqBE%2F6FmJxC%2FQ%3D&reserved=0
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
