Ok, maybe I had problems in the past due to what you say. Hope this changes remove that problems too
thanks 2018-02-23 19:29 GMT+01:00 Alex Harui <[email protected]>: > Hi Carlos, > > I think we've separated out basic.css and stopped misusing "className" in > the Basic components so typeNames should work as expected in subclasses > like MDL and possibly even Vivid. > > Piotr might as well finish up MDL so we can see if there might be issues > that affect Vivid. > > My 2 cents, > -Alex > > On 2/23/18, 10:21 AM, "[email protected] on behalf of Carlos Rovira" > <[email protected] on behalf of [email protected]> wrote: > > >Hi!, > > > >can't read all the thread right now, but I want to share a word of caution > >with MDL > >When I started that library, I had to fight a lot with typenames and > >classnames. > >Alex hopefully remember several emails about this topic. > >I ended with the current solution. As I excluded basic css, I think I was > >starting from a clean setup, > >but the way MDL css operates, make me use typenames in the current way. > > > >Don't know if that can be changed or not, maybe if some things changed in > >royale new versions, that could happen, > >but I think maybe that's not the case, and could not have solution due to > >how MDL is done. > > > >Anyway, you know what I think about MDL library future. We should not have > >to invest many time with it, since I expect vivid to > >take its place. But anyone here is free to invest the time where he/she > >prefers. > > > >Thanks > > > > > > > >2018-02-23 18:36 GMT+01:00 Piotr Zarzycki <[email protected]>: > > > >> Understand! :) Now I can agree with you that typeNames could be > >>protected. > >> Definitely. > >> > >> Let me play farther with MDL and see where I end up. > >> > >> On Fri, Feb 23, 2018, 18:28 Alex Harui <[email protected]> > wrote: > >> > >> > > >> > > >> > On 2/23/18, 8:50 AM, "Piotr Zarzycki" <[email protected]> > >>wrote: > >> > > >> > >Just the opposite. The typeNames get rid of everything what is setup > >>in > >> > >the > >> > >classList. > >> > > > >> > >But className is being add typeNames. This is what is happen: > >> > > > >> > >typeNames=mdl-card > >> > >classList.add("someclass") > >> > > > >> > >In addedToParent: > >> > >className += typeNames > >> > >classList is being wipped out and filled by className. > >> > > > >> > >That is ok? > >> > > >> > I don't know if that is "ok", but that is expected because you are > >> > manipulating element.classList directly but element.classList is > >>mapped > >> to > >> > className + typeNames. > >> > > >> > Here's a rough analogy: If you have an ArrayList wrap and track an > >>Array > >> > and then directly manipulate the Array, you can't guarantee that the > >> > ArrayList will still track the array. > >> > > >> > UIBase wraps an HTMLElement. The APIs on UIBase are supposed to be > >> > proxied into the element. If you manipulate the element directly, you > >> > have to sync up the wrapper's properties. > >> > > >> > Either work with the UIBase APIs to get the classList you want, or > >>after > >> > manipulating classList, update classNames as needed so the next > >>setting > >> of > >> > className or the addToParent call does not disturb your manipulated > >> > classList. > >> > > >> > -Alex > >> > > > >> > >On Fri, Feb 23, 2018, 17:26 Alex Harui <[email protected]> > >> wrote: > >> > > > >> > >> TypeNames is supposed to override what is in classList. ClassList > >> > >>should > >> > >> contain two sets of names. Immutable ones that come from typeNames > >> like > >> > >> TextInput or Card that map to the component that is pointed to by > >> > >> element.royale_wrapper. That allows us to "extend" the set of > >> > >> TypeSelectors as folks in Flex are used to. Then the rest of the > >> names > >> > >>in > >> > >> classList map to className that custom Views or the user can set. > >> > >> > >> > >> So if your code wants to manipulate classList directly, it might be > >> > >>easier > >> > >> to manipulate className, or else, re-populate classname after > >> > >>manipulating > >> > >> classList by updating className with everything other than what is > >> > >> specified in typeNames. > >> > >> > >> > >> If you are saying that the shadow code is trying to get rid of > >> whatever > >> > >> was specified in typeNames, I suppose that's "ok" but that would > >>be a > >> > >>new > >> > >> pattern. It is more likely that if typeNames was set to Card that > >> there > >> > >> should be few if any properties in the Card selector that shadow > >> should > >> > >> affect. There really shouldn't be a reason to kick the names in > >> > >>typenames > >> > >> out of the classList. > >> > >> > >> > >> Of course, I could be wrong... > >> > >> -Alex > >> > >> > >> > >> On 2/23/18, 8:16 AM, "Piotr Zarzycki" <[email protected]> > >> > wrote: > >> > >> > >> > >> >Reading what you are saying here regarding classList and > >>className w > >> > >>have > >> > >> >a > >> > >> >bug. typeNames shouldn't override what is inside classList, but > >>this > >> is > >> > >> >what has happened in addedToParent. > >> > >> > > >> > >> >Am I understand you correctly? > >> > >> > > >> > >> > > >> > >> >On Fri, Feb 23, 2018, 17:11 Alex Harui <[email protected]> > >> > >>wrote: > >> > >> > > >> > >> >> > >> > >> >> > >> > >> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki" > >><[email protected]> > >> > >> wrote: > >> > >> >> > >> > >> >> >Alex, > >> > >> >> > > >> > >> >> >I have started to work on MDL and move all typeNames from > >> > >> >>createElement to > >> > >> >> >constructor. Unfortunately something is not right here. > >> > >> >> > > >> > >> >> >1) I still need to exclude BasicJS.swc:default.css - I did add > >> > >>theme to > >> > >> >> >MaterialDesignLite module maven build - it didn't help. > >> > >> >> >2) If I cannot setup typeNames and classNames inside my > >>component, > >> > >>how > >> > >> >>can > >> > >> >> >I achieve switching some UI parts of the component ? In MDL it > >>is > >> > >>quite > >> > >> >> >common that if I would like to change component I'm adding to > >>it > >> css > >> > >> >> >class. > >> > >> >> >[1] - This is the example. If I remove line it doesn't work. > >>There > >> > >>are > >> > >> >> >several places in MDL where we are doing such things. It is > >>common > >> > >>in > >> > >> >>JS > >> > >> >> >world doing such things. > >> > >> >> > >> > >> >> That's because the JS world doesn't have strong typing. They > >>can > >> > >> >> transform a TextInput into a TextArea and not care. I suspect > >>that > >> > >>if > >> > >> >>you > >> > >> >> set shadow at runtime it won't have an effect because typeNames > >>is > >> > >>not > >> > >> >> re-evaluated after adddedToParent. The className property is > >> > >>suppose to > >> > >> >> combine with typeNames and result in the element.classList by > >> setting > >> > >> >>(in > >> > >> >> addedToParent) the element.className to the space-separated > >>list of > >> > >> >> everything in typeNames and className. So, if MDL code > >>manipulates > >> > >> >> element.classList, I think it should be echoing those changes > >>into > >> > >>the > >> > >> >> className property, not typeNames. typeNames should be > >>considered > >> > >> >> "write-once" or "write during constructor" and not changed > >> > >>afterwards. > >> > >> >>It > >> > >> >> is the set of things that go in the element.classList that > >>should > >> be > >> > >> >> immutable. As immutable as declaring a true subclass. > >>className > >> is > >> > >>for > >> > >> >> the things that go in element.classList that can change at > >>runtime. > >> > >> >> > >> > >> >> My 2 cents, > >> > >> >> -Alex > >> > >> >> > >> > >> >> > > >> > >> >> >typeNames = element.className; > >> > >> >> > > >> > >> >> >Thoughts ? > >> > >> >> > > >> > >> >> >[1] > >> > >> >> > > >> > >> >> > >> > >> >> > >> > >> > >> > >> > >> > https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fpaste.ap > >> > >> >>a > >> > >> >> >che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com > >> > >> >> %7C55b6f3b3cb1b40e46bf108d > >> > >> >> > >> > >> > >> > >>>>>57ad2b6df%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636549967805810 > >> > >>>>>82 > >> > >> >>>9& > >> > >> >> >sdata=i9EZFYDPNqo4lakPPe1lB0NDfajXmq > hMnDX7bxiBecc%3D&reserved=0 > >> > >> >> > > >> > >> >> >Thanks, > >> > >> >> >Piotr > >> > >> >> > > >> > >> >> > > >> > >> >> >2018-02-23 15:55 GMT+01:00 Piotr Zarzycki > >> > >><[email protected]>: > >> > >> >> > > >> > >> >> >> Peter, > >> > >> >> >> > >> > >> >> >> That is interesting what you are saying. What will happen > >>then > >> if > >> > >>you > >> > >> >> >>have > >> > >> >> >> class which extends other one. The parent class is setting > >> > >>typeNames > >> > >> >>and > >> > >> >> >> derived one also before super? The parent one will override > >>it? > >> > >> >> >> > >> > >> >> >> I cannot check now how typeNames is implemented. > >> > >> >> >> > >> > >> >> >> Piotr > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> On Fri, Feb 23, 2018, 15:13 Peter Ent > >><[email protected]> > >> > >> wrote: > >> > >> >> >> > >> > >> >> >>> I have been guilty of this and have been using typeNames > >>now. > >> > >>I've > >> > >> >> >>>found > >> > >> >> >>> that I need to set typeNames before calling super() in the > >> > >> >> >>>constructor. I > >> > >> >> >>> thought it was done afterwards, but if I set typeNames after > >> > >>calling > >> > >> >> >>> super(), the typeName I set does not show up in the HTML > >> > >>produced. > >> > >> >> >>> > >> > >> >> >>> Also, suppose I have this: A Menu with a label inside of it. > >> > >>People > >> > >> >> >>>will > >> > >> >> >>> want to change the background color of the menu and the > >>color > >> of > >> > >>the > >> > >> >> >>> label's text. If I were doing this in plain HTML/JS/CSS, I > >> would > >> > >> >>set a > >> > >> >> >>> selector: .Menu .Label { color: blue; } but that's not > >> > >>supported in > >> > >> >> >>>the > >> > >> >> >>> Flash Player. So when I set up the typeName for the label > >> inside > >> > >>of > >> > >> >>the > >> > >> >> >>> Menu should I set it to: Menu_Label or MenuLabel or > >>Menu-Label? > >> > >>And > >> > >> >>is > >> > >> >> >>> using "." in a selector name a good idea? I would think the > >>CSS > >> > >> >> >>>processor > >> > >> >> >>> in the browser would be confused between ".x.y" and ".x .y" > >> which > >> > >> >>can > >> > >> >> >>>also > >> > >> >> >>> be written as ".x.y". Basically, we should have a consist > >> naming > >> > >> >> >>>pattern > >> > >> >> >>> here. > >> > >> >> >>> > >> > >> >> >>> ‹peter > >> > >> >> >>> > >> > >> >> >>> On 2/23/18, 4:09 AM, "Gabe Harbs" <[email protected]> > >> wrote: > >> > >> >> >>> > >> > >> >> >>> >There¹s some edge cases which seem problematic. One > >>example: > >> > >> >> >>> >ComboBoxBiew has the following: > >> > >> >> >>> > input = new TextInput(); > >> > >> >> >>> > input.className = "ComboBoxTextInput"; > >> > >> >> >>> > > >> > >> >> >>> > button = new TextButton(); > >> > >> >> >>> > button.className = > >> > >> >> >>> >"opt_org-apache.royale-html-ComboBox_Button"; > >> > >> >> >>> > > >> > >> >> >>> >Input and button are both external to the view class, but > >>are > >> > >> >>managed > >> > >> >> >>>by > >> > >> >> >>> >the view class. On the other hand, there is a chance that > >>the > >> > >>user > >> > >> >> >>>might > >> > >> >> >>> >wan to style them. I¹m not sure whether className or > >>typeNames > >> > >>is > >> > >> >>more > >> > >> >> >>> >appropriate hereŠ > >> > >> >> >>> > > >> > >> >> >>> >Harbs > >> > >> >> >>> > > >> > >> >> >>> >> On Feb 23, 2018, at 11:03 AM, Gabe Harbs > >> > >><[email protected]> > >> > >> >> >>> wrote: > >> > >> >> >>> >> > >> > >> >> >>> >> I¹ll help. > >> > >> >> >>> >> > >> > >> >> >>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui > >> > >> >><[email protected] > >> > >> >> > > >> > >> >> >>> >>>wrote: > >> > >> >> >>> >>> > >> > >> >> >>> >>> Quick note before I shut down for the night. > >> > >> >> >>> >>> > >> > >> >> >>> >>> UIBase has both a typeNames and className property. > >> > >>TypeNames > >> > >> >>is > >> > >> >> >>>used > >> > >> >> >>> >>>to > >> > >> >> >>> >>> emulate Flex-like type selectors in the CSS lookup. It > >> > >>should > >> > >> >>be > >> > >> >> >>>set > >> > >> >> >>> >>>in > >> > >> >> >>> >>> the constructor and never set from outside the class. > >> There > >> > >> >>are a > >> > >> >> >>>few > >> > >> >> >>> >>> classes in Basic and lots of classes in MDL that should > >>be > >> > >> >> >>>upgraded to > >> > >> >> >>> >>>set > >> > >> >> >>> >>> typeNames in the constructor. Subclasses can append to > >>the > >> > >>base > >> > >> >> >>> >>>class's > >> > >> >> >>> >>> typeNames > >> > >> >> >>> >>> > >> > >> >> >>> >>> className is the opposite. It should never be set > >>inside > >> the > >> > >> >> >>> >>>component's > >> > >> >> >>> >>> class. It is for users of that component to set styles > >>on > >> > >>the > >> > >> >> >>> >>>component. > >> > >> >> >>> >>> > >> > >> >> >>> >>> Can we get a volunteer to clean this up? > >> > >> >> >>> >>> > >> > >> >> >>> >>> Thanks, > >> > >> >> >>> >>> -Alex > >> > >> >> >>> >>> > >> > >> >> >>> >> > >> > >> >> >>> > > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> > > >> > >> >> > > >> > >> >> >-- > >> > >> >> > > >> > >> >> >Piotr Zarzycki > >> > >> >> > > >> > >> >> >Patreon: > >> > >> >> >* > >> > >> >> > >> > >> >> > >> > >> > >> > >> > >> > https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fwww.patr > >> > >> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com > >> > >> >> %7C55b6f3b3cb1b40 > >> > >> >> > >> > >> > >> > >>>>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636549 > >> > >>>>>96 > >> > >> >>>78 > >> > >> >> > >> > >> > >> > >>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q > >> %3D&reserv > >> > >>>>>ed > >> > >> >>>=0 > >> > >> >> >< > >> > >> >> > >> > >> >> > >> > >> > >> > >> > >> > https://na01.safelinks.protection.outlook.com/?url= > >> https%3A%2F%2Fwww.patr > >> > >> >> >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com > >> > >> >> %7C55b6f3b3cb1b40 > >> > >> >> > >> > >> > >> > >>>>>e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178de > >> cee1%7C0%7C0%7C636549 > >> > >>>>>96 > >> > >> >>>78 > >> > >> >> > >> > >> > >> > >>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q > >> %3D&reserv > >> > >>>>>ed > >> > >> >>>=0 > >> > >> >> >>* > >> > >> >> > >> > >> >> > >> > >> > >> > >> > >> > > >> > > >> > > > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7Cf09a55618e334334731e08d5 > >7aea628e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636550069456141742&s > >data=dJ5lw%2Bh9g2E%2Bi8CTXbVYeon6R7s5bZVGsb79lzfkl9g%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira
