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
>>*

Reply via email to