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

Reply via email to