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 <piotrzarzyck...@gmail.com>:
> 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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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%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
http://about.me/carlosrovira
