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 <aha...@adobe.com.invalid> wrote:
>
>
> On 2/23/18, 8:50 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> 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 <aha...@adobe.com.invalid> 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" <piotrzarzyck...@gmail.com>
> 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 <aha...@adobe.com.invalid>
> >>wrote:
> >> >
> >> >>
> >> >>
> >> >> 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.ap
> >> >>a
> >> >> >che.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com
> >> >> %7C55b6f3b3cb1b40e46bf108d
> >> >>
> >>
> >>>>>57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549967805810
> >>>>>82
> >> >>>9&
> >> >> >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%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%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549
> >>>>>96
> >> >>>78
> >> >>
> >>
> >>>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserv
> >>>>>ed
> >> >>>=0
> >> >> >>*
> >> >>
> >> >>
> >>
> >>
>
>
