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.... >> > > >> > > >> > > >> > >> > >> > >> >> >>