Just compiler.  No need for asjs changes at this time I think.

I'm still unclear on why you need to manipulate classList directly.  Is
there some code that is in the JS from Material that manipulates
classList?  Or are you just trying to swap out a name on the classList?
If the latter, why not just create some utility function that operates on
className and not the underlying element?

-Aleex

On 2/23/18, 11:58 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com> wrote:

>You did merge vivid compiler changes or also changes from asjs repository.
>
>As for my work on MDL. I ended up with something like that [1]. The
>question now how to propagate that code ? This is code for the component
>which manipulates classList. Should I create some parent class ? General/
>for MDL only, or Bead which will be included into such classes ?
>Theoretically bead could listen for initComplete.
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2F1dy2&data=02%7C01%7Caharui%40adobe.com%7C8e313e7d7f9d4608759f08d
>57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636550127203173382&
>sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%3D&reserved=0
>
>Thanks,
>Piotr
>
>2018-02-23 20:53 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
>
>> I think I have Maven using the basic.css appropriately.  There is no way
>> to default to including a SWC in Maven and then not use it in a child
>> project, so all example poms that aren't MDL need to bring in the
>> BasicTheme.
>>
>> Also, I had to merge the compiler change from vivid-ui-set branch to get
>> the theme SWC to work in Maven.
>>
>> -Alex
>>
>> On 2/23/18, 8:04 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:
>>
>> >MDL does not want the basic.css theme.  That is why we are moving
>>styles
>> >from Basic:swc's defaults.css to themes/basic.css.  I see that the
>>Maven
>> >plugin doesn't allow specification of a theme, so that's another task.
>> I
>> >can do it if nobody wants to take that on.  So, yes, move the Button
>> >selectors from defaults.css to basic.css if that helps, but I will say
>> >that I didn't notice those styles taking effect in my local version of
>> >MDLTabsExample and assumed that mdl had overridden those styles.  As
>> >Carlos said, in the end we want basic.css to be compliant CSS so don't
>> >move anything with ClassReference as the value without discussing
>>first.
>> >
>> >TypeNames should be set after the call to super().  Look at Label and
>> >MultilineLabel.  They are working fine for me.  They are being used in
>> >RoyaleStore.  There might have been issues before yesterday because
>>lots
>> >of Basic components were setting ClassName, but I went and cleaned
>>that up
>> >although I could have missed a few.
>> >
>> >In complex Views, you have two choices:  Make a subclass or assign the
>> >className.  We should try to set set typeNames.  In fact, maybe we
>>should
>> >make typeNames protected.
>> >
>> >So, for ComboBoxView, the current code is setting a custom className
>>which
>> >is valid.  Users can then style it further by adding a
>>.ComboBoxTextInput
>> >selector to their CSS. However, class selectors are not pruned by the
>> >compiler.  So in other cases, we have created a real subclass (in this
>> >case "ComboBoxTextInput extends TextInput) and then the CSS would not
>>have
>> >the "." in front so it would look like a type selector and the compiler
>> >would prune it from apps that don't use a ComboBox.  Not sure which is
>> >better/faster,
>> >
>> >Regarding Peter's point about Labels in Menus.  The issue isn't that
>>Flash
>> >can't handle it.  It is that our SimpleCSSValuesImpl lookup doesn't
>>handle
>> >descendant and other advanced selectors.  The techniques for
>>ComboBoxView
>> >is how we avoid requiring a more complex lookup on the SWF side.  The
>>menu
>> >code should not be setting typeNames on other things, only itself.  I'm
>> >not sure if on the JS side, avoiding descendant selectors speeds
>>things up
>> >in the browser or not.  We could create an IValuesImpl with descendant
>> >selector support on the SWF side and probably will someday.  Volunteers
>> >are welcome to take that on.
>> >
>> >Of course, I could be wrong...
>> >-Alex
>> >
>> >
>> >On 2/23/18, 7:37 AM, "Piotr Zarzycki" <piotrzarzyck...@gmail.com>
>>wrote:
>> >
>> >>A bit more on point 1. and let's take for the example simple Button.
>>We
>> >>have some styles for Button in Basic.css. MDL Button extends
>>TextButton -
>> >>some styles naturally has been added from default.css.
>> >>
>> >>If I create theme I should achieve that my theme classes will override
>> >>default.css Button styles and I should be good yes ?
>> >>
>> >>Am I understand it correctly ?
>> >>Thanks, Piotr
>> >>
>> >>
>> >>2018-02-23 16:32 GMT+01:00 Piotr Zarzycki <piotrzarzyck...@gmail.com>:
>> >>
>> >>> 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.
>> >>>
>> >>> typeNames = element.className;
>> >>>
>> >>> Thoughts ?
>> >>>
>> >>> [1]
>> >>>https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.a
>> >>>p
>> >>>ache.org%2Fat0H&data=02%7C01%7Caharui%40adobe.com%
>> 7Ca44c142f0ddc455c70bf
>> >>>0
>> >>>8d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549970664822
>> >>>4
>> >>>53&sdata=1sSgdfBy%2BAv%2FsFIYwVFFHvVlhtJ3w3TW%
>> 2FiDEyPVYGmo%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.pa
>> >>>t
>> >>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7Ca44c142f0dd
>> >>>c
>> >>>455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549
>> >>>9
>> >>>70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>> FFjSWC8LaxmWI%3D&reserve
>> >>>d
>> >>>=0
>> >>>
>> >>><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pa
>> >>>t
>> >>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7Ca44c142f0dd
>> >>>c
>> >>>455c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549
>> >>>9
>> >>>70664822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>> FFjSWC8LaxmWI%3D&reserve
>> >>>d
>> >>>=0>*
>> >>>
>> >>
>> >>
>> >>
>> >>--
>> >>
>> >>Piotr Zarzycki
>> >>
>> >>Patreon:
>> >>*https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>> >>r
>> >>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7Ca44c142f0ddc4
>> >>5
>> >>5c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549970
>> >>6
>> 
>>>>64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJRFFjSWC8LaxmWI%3D&reserved=
>>>>0
>> >><https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fwww.pat
>> >>r
>> >>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com
>> %7Ca44c142f0ddc4
>> >>5
>> >>5c70bf08d57ad361e6%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C0%7C636549970
>> >>6
>> >>64822453&sdata=RxqP6b0L0BmWiiX3t6QdtbiA3YwoJR
>> FFjSWC8LaxmWI%3D&reserved=0>
>> >>*
>> >
>>
>>
>
>
>-- 
>
>Piotr Zarzycki
>
>Patreon: 
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C8e313e7d7f9d46
>08759f08d57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365501272
>03173382&sdata=CTWhfUy0ILGvvx3HwRbmnkSZ3Nf5aylHwldhGDulDOE%3D&reserved=0
><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7C8e313e7d7f9d46
>08759f08d57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365501272
>03173382&sdata=CTWhfUy0ILGvvx3HwRbmnkSZ3Nf5aylHwldhGDulDOE%3D&reserved=0>*

Reply via email to