You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Greg Dove <gr...@gmail.com> on 2020/05/06 21:10:37 UTC
MXRoyale question - styleName
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....
Re: MXRoyale question - styleName
Posted by Carlos Rovira <ca...@apache.org>.
In my experience element.classList is a must and a need in modern
development, it was very cumbersome when don't have it. I could solve
adding support in StyledUIBase and redoing most of hierarchies in Jewel to
get that class as the base, but was cause of many time and headaches. If
you don't have it at MXRoyale level my advice is to add it. Or as you want
some serious styling support you will need it for sure.
El jue., 7 may. 2020 a las 22:48, Alex Harui (<ah...@adobe.com.invalid>)
escribió:
> org.apache.royale.utils.ClassSelectorList looks like it may someday be a
> platform abstraction so I don't see any reason to use it for js-only code.
>
> My 2 cents,
> -Alex
>
> On 5/7/20, 12:44 PM, "Greg Dove" <gr...@gmail.com> wrote:
>
> Back to original topic:
>
> I plan to work on that change at my EOD today. I was thinking to
> implement
> this directly using native
> element.classList.add/element.classList.remove
> for the string assignments (and adjust the trace warning for other
> types)
>
> I also see org.apache.royale.utils.ClassSelectorList. Can you think of
> a
> reason why that would be needed here? I assume it should not be needed.
>
> Thanks
> Greg
>
> On Fri, May 8, 2020 at 5:40 AM Greg Dove <gr...@gmail.com> wrote:
>
> >
> > Oh, I know it's still out there. But we know it is small and getting
> > smaller. It is the age-old dilemma of the needs-of-the-few dictating
> the
> > needs-of-the-many. I don't think the laggards are those who use it
> for
> > personal browser. Use as the 'internal' browser in corporates has to
> be
> > getting less over time. And if they actually lock down updates, then
> maybe
> > they will not lose flash player internally anyway (or could choose
> not to).
> > I understand we are stuck with it for now, I was just expressing
> that it
> > does hold Royale back.
> >
> > For Proxy, I don't think major re-writes would be necessary -
> perhaps they
> > would be useful in some cases, but they may not be necessary. I have
> used
> > it in the past, but it has been a while now. It does not participate
> in
> > inheritance or typing. So you could simply use it to decorate
> instances to
> > make them runtime savvy, and that may not need to be all instances
> for
> > example, it could just be in parts of code that need it. For XML I
> don't
> > know what the memory overhead would be of using it for every
> instance, and
> > it may not be something to do by default. Proxy could perhaps be
> something
> > that you use in places where it's needed (@royalexmlruntimeinstances
> -
> > construct with Proxy support inside this function scope) and
> otherwise
> > not, for example. To be clear, I'm not worried about this
> specifically now,
> > I was just replying to your earlier comment that it would be hard or
> slow
> > to do runtime property access - I think the way Proxy works may mean
> it is
> > not too difficult, but making it selective and not for all instances
> would
> > still be preferable I assume (which is work in the compiler).
> >
> >
> >
> > On Fri, May 8, 2020 at 4:59 AM Yishay Weiss <yi...@hotmail.com>
> > wrote:
> >
> >> Yes, I was meaning to respond to that. Our client opened up our POC
> on
> >> his default browser, which is IE11, and saw nothing working. It’s
> still out
> >> there.
> >>
> >> >It's interesting that in the same month as someone wants modules
> to work
> >> in IE11 we also want to get rid of IE11 support.
> >>
> >> On 5/7/20, 2:09 AM, "Greg Dove" <gr...@gmail.com> wrote:
> >>
> >> 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
> <ah...@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" <gr...@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
> >> <ah...@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" <gr...@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....
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >>
> >>
> >>
>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: MXRoyale question - styleName
Posted by Alex Harui <ah...@adobe.com.INVALID>.
org.apache.royale.utils.ClassSelectorList looks like it may someday be a platform abstraction so I don't see any reason to use it for js-only code.
My 2 cents,
-Alex
On 5/7/20, 12:44 PM, "Greg Dove" <gr...@gmail.com> wrote:
Back to original topic:
I plan to work on that change at my EOD today. I was thinking to implement
this directly using native element.classList.add/element.classList.remove
for the string assignments (and adjust the trace warning for other types)
I also see org.apache.royale.utils.ClassSelectorList. Can you think of a
reason why that would be needed here? I assume it should not be needed.
Thanks
Greg
On Fri, May 8, 2020 at 5:40 AM Greg Dove <gr...@gmail.com> wrote:
>
> Oh, I know it's still out there. But we know it is small and getting
> smaller. It is the age-old dilemma of the needs-of-the-few dictating the
> needs-of-the-many. I don't think the laggards are those who use it for
> personal browser. Use as the 'internal' browser in corporates has to be
> getting less over time. And if they actually lock down updates, then maybe
> they will not lose flash player internally anyway (or could choose not to).
> I understand we are stuck with it for now, I was just expressing that it
> does hold Royale back.
>
> For Proxy, I don't think major re-writes would be necessary - perhaps they
> would be useful in some cases, but they may not be necessary. I have used
> it in the past, but it has been a while now. It does not participate in
> inheritance or typing. So you could simply use it to decorate instances to
> make them runtime savvy, and that may not need to be all instances for
> example, it could just be in parts of code that need it. For XML I don't
> know what the memory overhead would be of using it for every instance, and
> it may not be something to do by default. Proxy could perhaps be something
> that you use in places where it's needed (@royalexmlruntimeinstances -
> construct with Proxy support inside this function scope) and otherwise
> not, for example. To be clear, I'm not worried about this specifically now,
> I was just replying to your earlier comment that it would be hard or slow
> to do runtime property access - I think the way Proxy works may mean it is
> not too difficult, but making it selective and not for all instances would
> still be preferable I assume (which is work in the compiler).
>
>
>
> On Fri, May 8, 2020 at 4:59 AM Yishay Weiss <yi...@hotmail.com>
> wrote:
>
>> Yes, I was meaning to respond to that. Our client opened up our POC on
>> his default browser, which is IE11, and saw nothing working. It’s still out
>> there.
>>
>> >It's interesting that in the same month as someone wants modules to work
>> in IE11 we also want to get rid of IE11 support.
>>
>> On 5/7/20, 2:09 AM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> 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 <ah...@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" <gr...@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
>> <ah...@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" <gr...@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....
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXRoyale question - styleName
Posted by Greg Dove <gr...@gmail.com>.
Back to original topic:
I plan to work on that change at my EOD today. I was thinking to implement
this directly using native element.classList.add/element.classList.remove
for the string assignments (and adjust the trace warning for other types)
I also see org.apache.royale.utils.ClassSelectorList. Can you think of a
reason why that would be needed here? I assume it should not be needed.
Thanks
Greg
On Fri, May 8, 2020 at 5:40 AM Greg Dove <gr...@gmail.com> wrote:
>
> Oh, I know it's still out there. But we know it is small and getting
> smaller. It is the age-old dilemma of the needs-of-the-few dictating the
> needs-of-the-many. I don't think the laggards are those who use it for
> personal browser. Use as the 'internal' browser in corporates has to be
> getting less over time. And if they actually lock down updates, then maybe
> they will not lose flash player internally anyway (or could choose not to).
> I understand we are stuck with it for now, I was just expressing that it
> does hold Royale back.
>
> For Proxy, I don't think major re-writes would be necessary - perhaps they
> would be useful in some cases, but they may not be necessary. I have used
> it in the past, but it has been a while now. It does not participate in
> inheritance or typing. So you could simply use it to decorate instances to
> make them runtime savvy, and that may not need to be all instances for
> example, it could just be in parts of code that need it. For XML I don't
> know what the memory overhead would be of using it for every instance, and
> it may not be something to do by default. Proxy could perhaps be something
> that you use in places where it's needed (@royalexmlruntimeinstances -
> construct with Proxy support inside this function scope) and otherwise
> not, for example. To be clear, I'm not worried about this specifically now,
> I was just replying to your earlier comment that it would be hard or slow
> to do runtime property access - I think the way Proxy works may mean it is
> not too difficult, but making it selective and not for all instances would
> still be preferable I assume (which is work in the compiler).
>
>
>
> On Fri, May 8, 2020 at 4:59 AM Yishay Weiss <yi...@hotmail.com>
> wrote:
>
>> Yes, I was meaning to respond to that. Our client opened up our POC on
>> his default browser, which is IE11, and saw nothing working. It’s still out
>> there.
>>
>> >It's interesting that in the same month as someone wants modules to work
>> in IE11 we also want to get rid of IE11 support.
>>
>> On 5/7/20, 2:09 AM, "Greg Dove" <gr...@gmail.com> wrote:
>>
>> 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 <ah...@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" <gr...@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
>> <ah...@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" <gr...@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....
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
Re: MXRoyale question - styleName
Posted by Greg Dove <gr...@gmail.com>.
Oh, I know it's still out there. But we know it is small and getting
smaller. It is the age-old dilemma of the needs-of-the-few dictating the
needs-of-the-many. I don't think the laggards are those who use it for
personal browser. Use as the 'internal' browser in corporates has to be
getting less over time. And if they actually lock down updates, then maybe
they will not lose flash player internally anyway (or could choose not to).
I understand we are stuck with it for now, I was just expressing that it
does hold Royale back.
For Proxy, I don't think major re-writes would be necessary - perhaps they
would be useful in some cases, but they may not be necessary. I have used
it in the past, but it has been a while now. It does not participate in
inheritance or typing. So you could simply use it to decorate instances to
make them runtime savvy, and that may not need to be all instances for
example, it could just be in parts of code that need it. For XML I don't
know what the memory overhead would be of using it for every instance, and
it may not be something to do by default. Proxy could perhaps be something
that you use in places where it's needed (@royalexmlruntimeinstances -
construct with Proxy support inside this function scope) and otherwise
not, for example. To be clear, I'm not worried about this specifically now,
I was just replying to your earlier comment that it would be hard or slow
to do runtime property access - I think the way Proxy works may mean it is
not too difficult, but making it selective and not for all instances would
still be preferable I assume (which is work in the compiler).
On Fri, May 8, 2020 at 4:59 AM Yishay Weiss <yi...@hotmail.com> wrote:
> Yes, I was meaning to respond to that. Our client opened up our POC on his
> default browser, which is IE11, and saw nothing working. It’s still out
> there.
>
> >It's interesting that in the same month as someone wants modules to work
> in IE11 we also want to get rid of IE11 support.
>
> On 5/7/20, 2:09 AM, "Greg Dove" <gr...@gmail.com> wrote:
>
> 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 <ah...@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" <gr...@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
> <ah...@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" <gr...@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....
> > >
> > >
> > >
> >
> >
> >
>
>
>
RE: MXRoyale question - styleName
Posted by Yishay Weiss <yi...@hotmail.com>.
Yes, I was meaning to respond to that. Our client opened up our POC on his default browser, which is IE11, and saw nothing working. It’s still out there.
>It's interesting that in the same month as someone wants modules to work in IE11 we also want to get rid of IE11 support.
On 5/7/20, 2:09 AM, "Greg Dove" <gr...@gmail.com> wrote:
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 <ah...@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" <gr...@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 <ah...@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" <gr...@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....
> >
> >
> >
>
>
>
Re: MXRoyale question - styleName
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Most components work for the scenarios we've seen. So if we've only seen GridRow used with a height set, it is not surprising it doesn't work without height set. We reused a fair amount of code from Flex, but laying out elements is often different.
ADG has a working alternatingRowColors so hopefully you can move that down into DataGrid.
It's interesting that in the same month as someone wants modules to work in IE11 we also want to get rid of IE11 support. Not sure what the right thing to do is. I think we'd have to rewrite XML to use ES6 Proxy if we go that route since that's the other main runtime property access problem scenario. Not sure if there are others.
-Alex
On 5/7/20, 2:09 AM, "Greg Dove" <gr...@gmail.com> wrote:
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 <ah...@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" <gr...@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 <ah...@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" <gr...@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....
> >
> >
> >
>
>
>
Re: MXRoyale question - styleName
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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 <ah...@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" <gr...@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....
> >
> >
> >
>
>
>
Re: MXRoyale question - styleName
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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 <ah...@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" <gr...@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....
>
>
>
Re: MXRoyale question - styleName
Posted by Greg Dove <gr...@gmail.com>.
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 <ah...@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" <gr...@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....
>
>
>
Re: MXRoyale question - styleName
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <gr...@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....