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%7C63654996780581082
>>>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%7C63654996
>>>78
>> 
>>>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%7C63654996
>>>78
>> 
>>>05810829&sdata=hwiCSurseLEKUg%2BlgYMmVVgrZvWqY3Q0VBckXnCiF8Q%3D&reserved
>>>=0
>> >>*
>>
>>

Reply via email to