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 <greg.d...@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 <yishayj...@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" <greg.d...@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 <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....
>> > >
>> > >
>> > >
>> >
>> >
>> >
>>
>>
>>
