On 2/23/18, 7:32 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> 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.apa >che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com%7C55b6f3b3cb1b40e46bf108d >57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549967805810829& >sdata=i9EZFYDPNqo4lakPPe1lB0NDfajXmqhMnDX7bxiBecc%3D&reserved=0 > >Thanks, >Piotr > > >2018-02-23 15:55 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>: > >> 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 <p...@adobe.com.invalid> 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" <harbs.li...@gmail.com> 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 <harbs.li...@gmail.com> >>> wrote: >>> >> >>> >> I¹ll help. >>> >> >>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui <aha...@adobe.com.INVALID> >>> >>>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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365499678 >05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserved=0 ><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr >eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C55b6f3b3cb1b40 >e46bf108d57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365499678 >05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserved=0 >>*
