Assuming you meant add/remove from classList as you proposed in the first
post, then I think the answer is yes.
yes, that's what I really meant. Ok, I will add that to MXRoyale probably
tomorrow.
Other:
I do expect to be contributing more to MXRoyale over coming weeks/months -
such as mxDataGrid which still needs more work over time.
I also saw different behavior with GridItems inside GridRow recently when
there was no height set for example, it was not being set to full height by
default, so I will look into that at some point (I am often using
workarounds for issues, but noting them as needs attention in Royale - I
don't have time for logging issues for everything with repro at this point).
For styles, yeah I think I saw alternatingColors for datagrid in MXRoyale
is not correctly processed (I think it goes the browser which does not
understand it - and so ignores it).
I am working on a client project with similar justifications for choosing
emulation.... I know others are looking at emulation as well for the same
reasons.
For people who don't care about IE11, (and I actually had someone from my
client ask me 'why do we care about that?' recently with genuine surprise)
then es6 Proxy would support a lot of 'runtime' emulations I think, which I
mentioned to you previously, so I know you are aware of it. I know at least
for certain browsers that es6 Proxy is very performant in spite of it being
a 'Proxy' approach. I am not thinking about this for now, but really I
think IE11 is the only thing holding us back there. I personally would like
to see us let go of IE11 asap after 1.0 - the more it continues to be
supported, the more it lingers and I do think we should look forward more
rather than back. I think if people want to keep using old IE browsers
internally with its risks etc, then they could probably keep using IE10
just for swf apps (iirc IE10 probably won't, but IE11 will get the
maintenance update that removes flash player at the end of the year.... if
IE11 did not, then I can't understand why we would continue to support it
for Royale, IMO, it is just holding us back).
anyway... that's off topic. For another time....
On Thu, May 7, 2020 at 6:37 PM Alex Harui <aha...@adobe.com.invalid> wrote:
> Assuming you meant add/remove from classList as you proposed in the first
> post, then I think the answer is yes. I think that's simple enough to
> emulate and will work most of the time. I think you have to use classList
> instead of className because there will be other things in the classList.
>
> For MXRoyale/SparkRoyale we are trying to have people change their code as
> little as possible. We are not trying to set them up for the future. IMO,
> if the migrator is willing to change a lot of code then Jewel or Basic
> should be considered.
>
> CSS is already funky in MXRoyale/SparkRoyale. Flex supported style
> properties that don't exist in the browser (like gap and horizontalCenter,
> IIRC) and width=100% has a completely different meaning. The emulation
> will eventually watch for certain styles and decide whether to emulate it
> in browser CSS or never set it in the browser and store the values
> elsewhere for use by getStyle calls from other code. The layouts do the
> latter in most cases. PercentWidth is never set on the HTMLElement. The
> old Flex layout code runs and interprets it.
>
> In the end, it should be a collaborative effort for the migrating team and
> the framework team. Time is running out on 2020 so the main question is
> what will get someone migrated faster? Emulation is usually faster and
> safer than changing code paths in many places in the application and helps
> others trying to use the emulations. But some emulations (runtime property
> access) are too hard or slow so the application does need to be changed.
>
> HTH,
> -Alex
>
> On 5/6/20, 11:08 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
>
> Thanks Alex, but - as a follow-on, do you think the styleName setter
> should
> set the className if it has a string value assignment? Or should we be
> telling people to manually edit the code/mxml and swap styleName string
> value assignments to 'className' value assignments? I think for the
> majority of cases (which I think will be string values), it might be
> good
> to have it 'work by default' and we can add the warnings for
> non-strings,
> like you suggest, but I just wanted to be sure that it is better to
> 'emulate' than to force review/attention....
>
>
>
> On Thu, May 7, 2020 at 5:03 PM Alex Harui <aha...@adobe.com.invalid>
> wrote:
>
> > Without thinking too hard, I would output a warning if someone passes
> > something other than a string. Then we'll know if anybody really
> needs the
> > more complex cases and can figure out what to do about it then.
> >
> > -Alex
> >
> > On 5/6/20, 2:11 PM, "Greg Dove" <greg.d...@gmail.com> wrote:
> >
> > This question is mainly for Alex or anyone else involved in
> porting an
> > MXRoyale application.
> >
> > When porting styleName='myStyleName' what is considered the best
> > approach?
> >
> > I would have assumed that styleName could simply be added to the
> > underlying
> > element's classList if it is a string, so it (I assume) would
> > correspond
> > closely to how it was used in the original Flex app. But I know
> > styleName
> > is not always a string in Flex, but in my experience that seems
> to be
> > the
> > most frequent case, which relates to a named declaration in the
> > stylesheet.
> >
> > Alex, and others, what are your thoughts? I am dealing with a
> large
> > codebase and would like to use a consistent approach from the
> outset.
> >
> > At the moment we have;
> >
> > set styleName(value:Object /* String, CSSStyleDeclaration, or
> > UIComponent
> > */):void
> > ...
> > // TODO
> > trace("styleName not implemented");
> >
> > if it is a string, then I assume it could be considered as a
> > custom/arbitrary css class, similar to how I remember it working
> in
> > Flex.
> >
> > UIComponent seems more problematic I assume, but I have not
> thought too
> > deeply about it.
> >
> > Anyway I would welcome thoughts. I guess one simple option is
> simply to
> > change it to className when porting if it is a string. But for
> > MXRoyale I
> > wondered if this should work (if it can) without changes....
> >
> >
> >
>
>
>
