Re: typeNames vs className

[Hugo Ferreira]

Thanks.

Harbs  escreveu no dia sábado, 12/02/2022 à(s) 23:54:

> typeNames are class names set by the class which should not be changed by
> client code.
>
> className is what you set in an application for styling.
>
> > On Feb 12, 2022, at 10:14 PM, Hugo Ferreira 
> wrote:
> >
> > Hi,
> >
> > For me seems that same,  typeNames is converted at runtime to className
> but
> > is so, what the reason to have a second property ?
>
>

Re: typeNames vs className

[Harbs]

typeNames are class names set by the class which should not be changed by 
client code.

className is what you set in an application for styling.

> On Feb 12, 2022, at 10:14 PM, Hugo Ferreira  wrote:
> 
> Hi,
> 
> For me seems that same,  typeNames is converted at runtime to className but
> is so, what the reason to have a second property ?

Re: TypeNames vs ClassName

[Carlos Rovira]

Ok Yishay, good to know it. thanks for reporting :)

El lun., 18 feb. 2019 a las 16:19, Yishay Weiss ()
escribió:

> Hi Carlos,
>
>
>
> After updating from dev it looks like it’s working now.
>
>
>
> Thanks.
>
>
>
> 
> From: Carlos Rovira 
> Sent: Thursday, February 14, 2019 7:28:19 PM
> To: dev@royale.apache.org
> Subject: Re: TypeNames vs ClassName
>
> HI Yishay,
>
> A working example is in TDJ ( https://royale.apache.org/tourdejewel )
> go to layouts. First one is a group with a className:
>
> Jewel BasicLayout (width200, height:200px)
>
> code:
>
> 
> 
>  y
> ="30"/>
>  y="60"/>
>  style="bottom:0;right:0"/>
> 
>
> If is not working for you, maybe we have a bug at some place.
>
> Carlos
>
>
> El jue., 14 feb. 2019 a las 15:45, yishayw ()
> escribió:
>
> > Confused about this, now that I'm using Jewel.
> >
> > I want to add shadow to a Jewel group. So I do this:
> >
> >  id="cFormSelector"/>
> >
> > But then I see raisedShadow removed in in run-time in favor of classes
> such
> > as "itemsExpand itemsCenter itemsCentered layout vertical"
> >
> > Where should I be specifying my application className then?
> >
> >
> >
> >
> > --
> > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 
Carlos Rovira
http://about.me/carlosrovira

RE: TypeNames vs ClassName

[Yishay Weiss]

Hi Carlos,



After updating from dev it looks like it’s working now.



Thanks.




From: Carlos Rovira 
Sent: Thursday, February 14, 2019 7:28:19 PM
To: dev@royale.apache.org
Subject: Re: TypeNames vs ClassName

HI Yishay,

A working example is in TDJ ( https://royale.apache.org/tourdejewel )
go to layouts. First one is a group with a className:

Jewel BasicLayout (width200, height:200px)

code:








If is not working for you, maybe we have a bug at some place.

Carlos


El jue., 14 feb. 2019 a las 15:45, yishayw ()
escribió:

> Confused about this, now that I'm using Jewel.
>
> I want to add shadow to a Jewel group. So I do this:
>
> 
>
> But then I see raisedShadow removed in in run-time in favor of classes such
> as "itemsExpand itemsCenter itemsCentered layout vertical"
>
> Where should I be specifying my application className then?
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>


--
Carlos Rovira
http://about.me/carlosrovira

Re: TypeNames vs ClassName

[Piotr Zarzycki]

In this place it's worth to mention link which explain what actually
emulation components are ->
https://github.com/apache/royale-asjs/wiki/emulation-components

Thanks,
Piotr

On Sun, Feb 17, 2019, 10:57 AM Carlos Rovira 
wrote:

> Hi Yannick,
>
> do you mean the HTML/JS/CSS generated code? as you compile the project
> you'll see in "js-debug" and "js-release" folders. You can as well use web
> inspector tools in browsers.
>
> About Flex code: there's no automatic migration tool. So you can follow
> some paths: One is to go with emulation components for MX (This is
> MXRoyale), that is developed by various contributors.
> Another one is to migrate as much as you can of your AS3 logic and create a
> new UI version using different UI Sets in Royale like: Jewel, Basic,
> Express or MDL.
>
> There's no one unique response, and all depends on the project, and
> strategy you think could be better in your case.
>
>
> El vie., 15 feb. 2019 a las 20:28, yannick delsahut (<
> y.delsa...@silverstark.fr>) escribió:
>
> > Carlos
> > Thank you i see your sample
> > Is ther a way to see code generated. I don't know if code of my sample
> > coud be transferm with Apache Royal
> > AS3 is converted? Is there a framework?
> > If you put our project Flex 3.6.0 does Royal product reuse code or
> > impossible.
> >
> > Thank you
> > yannick
> >
> > -Message d'origine-
> > De : Carlos Rovira [mailto:carlosrov...@apache.org]
> > Envoyé : jeudi 14 février 2019 18:28
> > À : dev@royale.apache.org
> > Objet : Re: TypeNames vs ClassName
> >
> > HI Yishay,
> >
> > A working example is in TDJ ( https://royale.apache.org/tourdejewel )
> > go to layouts. First one is a group with a className:
> >
> > Jewel BasicLayout (width200, height:200px)
> >
> > code:
> >
> > 
> > 
> >  x="30"
> > y
> > ="30"/>
> >  x="60"
> > y="60"/>
> >  > style="bottom:0;right:0"/>
> > 
> >
> > If is not working for you, maybe we have a bug at some place.
> >
> > Carlos
> >
> >
> > El jue., 14 feb. 2019 a las 15:45, yishayw ()
> > escribió:
> >
> > > Confused about this, now that I'm using Jewel.
> > >
> > > I want to add shadow to a Jewel group. So I do this:
> > >
> > >  > id="cFormSelector"/>
> > >
> > > But then I see raisedShadow removed in in run-time in favor of classes
> > such
> > > as "itemsExpand itemsCenter itemsCentered layout vertical"
> > >
> > > Where should I be specifying my application className then?
> > >
> > >
> > >
> > >
> > > --
> > > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>

Re: TypeNames vs ClassName

[Carlos Rovira]

Hi Yannick,

do you mean the HTML/JS/CSS generated code? as you compile the project
you'll see in "js-debug" and "js-release" folders. You can as well use web
inspector tools in browsers.

About Flex code: there's no automatic migration tool. So you can follow
some paths: One is to go with emulation components for MX (This is
MXRoyale), that is developed by various contributors.
Another one is to migrate as much as you can of your AS3 logic and create a
new UI version using different UI Sets in Royale like: Jewel, Basic,
Express or MDL.

There's no one unique response, and all depends on the project, and
strategy you think could be better in your case.


El vie., 15 feb. 2019 a las 20:28, yannick delsahut (<
y.delsa...@silverstark.fr>) escribió:

> Carlos
> Thank you i see your sample
> Is ther a way to see code generated. I don't know if code of my sample
> coud be transferm with Apache Royal
> AS3 is converted? Is there a framework?
> If you put our project Flex 3.6.0 does Royal product reuse code or
> impossible.
>
> Thank you
> yannick
>
> -Message d'origine-
> De : Carlos Rovira [mailto:carlosrov...@apache.org]
> Envoyé : jeudi 14 février 2019 18:28
> À : dev@royale.apache.org
> Objet : Re: TypeNames vs ClassName
>
> HI Yishay,
>
> A working example is in TDJ ( https://royale.apache.org/tourdejewel )
> go to layouts. First one is a group with a className:
>
> Jewel BasicLayout (width200, height:200px)
>
> code:
>
> 
> 
>  y
> ="30"/>
>  y="60"/>
>  style="bottom:0;right:0"/>
> 
>
> If is not working for you, maybe we have a bug at some place.
>
> Carlos
>
>
> El jue., 14 feb. 2019 a las 15:45, yishayw ()
> escribió:
>
> > Confused about this, now that I'm using Jewel.
> >
> > I want to add shadow to a Jewel group. So I do this:
> >
> >  id="cFormSelector"/>
> >
> > But then I see raisedShadow removed in in run-time in favor of classes
> such
> > as "itemsExpand itemsCenter itemsCentered layout vertical"
> >
> > Where should I be specifying my application className then?
> >
> >
> >
> >
> > --
> > Sent from: http://apache-royale-development.20373.n8.nabble.com/
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>


-- 
Carlos Rovira
http://about.me/carlosrovira

RE: TypeNames vs ClassName

[yannick delsahut]

Carlos
Thank you i see your sample
Is ther a way to see code generated. I don't know if code of my sample coud be 
transferm with Apache Royal
AS3 is converted? Is there a framework?
If you put our project Flex 3.6.0 does Royal product reuse code or impossible.

Thank you
yannick

-Message d'origine-
De : Carlos Rovira [mailto:carlosrov...@apache.org] 
Envoyé : jeudi 14 février 2019 18:28
À : dev@royale.apache.org
Objet : Re: TypeNames vs ClassName

HI Yishay,

A working example is in TDJ ( https://royale.apache.org/tourdejewel )
go to layouts. First one is a group with a className:

Jewel BasicLayout (width200, height:200px)

code:








If is not working for you, maybe we have a bug at some place.

Carlos


El jue., 14 feb. 2019 a las 15:45, yishayw ()
escribió:

> Confused about this, now that I'm using Jewel.
>
> I want to add shadow to a Jewel group. So I do this:
>
> 
>
> But then I see raisedShadow removed in in run-time in favor of classes such
> as "itemsExpand itemsCenter itemsCentered layout vertical"
>
> Where should I be specifying my application className then?
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: TypeNames vs ClassName

[Carlos Rovira]

HI Yishay,

A working example is in TDJ ( https://royale.apache.org/tourdejewel )
go to layouts. First one is a group with a className:

Jewel BasicLayout (width200, height:200px)

code:








If is not working for you, maybe we have a bug at some place.

Carlos


El jue., 14 feb. 2019 a las 15:45, yishayw ()
escribió:

> Confused about this, now that I'm using Jewel.
>
> I want to add shadow to a Jewel group. So I do this:
>
> 
>
> But then I see raisedShadow removed in in run-time in favor of classes such
> as "itemsExpand itemsCenter itemsCentered layout vertical"
>
> Where should I be specifying my application className then?
>
>
>
>
> --
> Sent from: http://apache-royale-development.20373.n8.nabble.com/
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: TypeNames vs ClassName

[yishayw]

Confused about this, now that I'm using Jewel.

I want to add shadow to a Jewel group. So I do this:



But then I see raisedShadow removed in in run-time in favor of classes such
as "itemsExpand itemsCenter itemsCentered layout vertical"

Where should I be specifying my application className then?




--
Sent from: http://apache-royale-development.20373.n8.nabble.com/

Re: TypeNames vs ClassName

[Carlos Rovira]

HI Alex,

ok, I think I'll be subclassing in my branch and see where I get, in this
way the Piotr and Harbs can continue with things as they expect to.
In the other way, maybe it could seem that I'm worried to much about how
html looks, and maybe things like the layouts can wait, but I think is
important
to get some structural points set in a concrete way in order to grow from
there in a better way. As I progress in my journey to get all this pieces
ok I feel more confortable, and
I think, having a good foundation with only 1 or 2 components (like button,
textbutton,...) then will make me go fast with the rest of components

thanks

2018-03-12 19:09 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> I think people are more uncomfortable with the proposal to use
> element.classList than any issue about order.  It is hard for me to truly
> understand without seeing code so I think you should push it to your
> branch.
>
> I agree with Piotr that we can't make the users (app dev) use classList.
> Folks are going to use className out of habit or because they are
> borrowing a code snippet from the web.
>
> But most important, real users like Alina need components that work and
> I'm not convinced she's going to look under-the-hood.  It is frustrating
> to me that we have lots of emulation components to write but instead we
> are discussing details of typeNames and classNames.  IMO, it just isn't as
> important.  If it isn't broken, don't fix it.  Learn to live with some
> imperfections.  The big picture is that migration has to work.
>
> Your work on having a default look is important because that will be the
> default look for Alina's and others apps, but again, I don't agree that it
> is important to make the underlying implementation perfect.  Nobody will
> even look under the hood unless there are enough emulation components that
> have a chance of working, even imperfectly.
>
> My 2 cents,
> -Alex
>
> On 3/12/18, 10:58 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >since Piotr and Harbs seems not to be very comfortable with the change, I
> >can subclass UIBase for Jewel and make that changes there. I don't want to
> >conflict in such central point of the framework,
> >Will it be ok for all of us?
> >
> >2018-03-12 18:56 GMT+01:00 Alex Harui :
> >
> >> IMO, the order isn't going to make or break Royale.  Leave it as you
> >>have
> >> it and we'll see what our users think.
> >>
> >> -Alex
> >>
> >> On 3/12/18, 10:49 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >Hi
> >> >
> >> >sorry guys, I changed it since I thought I would not matter anyone.
> >>For me
> >> >is just the opposite. Feels very strange to me see things right to
> >>left,
> >> >is like description of folders, bread crumbs and something like this
> >>that
> >> >use to be from parent to child, and left to right
> >> >
> >> >I do that as well since for example Harbs said doesn't mind how final
> >>code
> >> >looks, but for me is important.
> >> >
> >> >do you want I reverse the commit? Is there a way to make it
> >>configurable
> >> >and be all happy? maybe I should subclass UIBase fo Jewel...
> >> >
> >> >
> >> >2018-03-12 18:01 GMT+01:00 Piotr Zarzycki :
> >> >
> >> >> 2018-03-12 17:14 GMT+01:00 Alex Harui :
> >> >>
> >> >> > If HTMLElement.classList is exposed to the user (the app developer)
> >> >>then
> >> >> > they can remove any of the items that were added from the
> >>typenames.
> >> >> > There is no way to enforce immutability of the typenames.  We can
> >> >>choose
> >> >> > to give up on that and require that app developers be careful, but
> >>I'd
> >> >> > rather not.
> >> >> >
> >> >> > Given that, if you've found a way to eliminate the need for
> >> >>CSSClassList,
> >> >> > that's great.
> >> >> >
> >> >> > IMO, the immutable things from typenames should be last in the
> >>list.
> >> >>My
> >> >> > eye reads left to right and doesn't want to have to skip over stuff
> >> >>that
> >> >> > will be the same.
> >> >> >
> >> >> >
> >> >>
> >> >> *TOTALLY *agree with that. I tend to omit stuff because it looks the
> >> >>same,
> >> >> so having typedefs at the beginning makes it so like that.
> >> >>
> >> >> Piotr
> >> >>
> >> >>
> >> >>
> >> >> > My 2 cents,
> >> >> > -Alex
> >> >> >
> >> >> > On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >> >> Rovira"
> >> >> > 
> >>wrote:
> >> >> >
> >> >> > >Hi
> >> >> > >
> >> >> > >I made some simplification that works ok in Jewel:
> >> >> > >
> >> >> > >1.- remove CSSClassList and use element.classList since is native
> >>and
> >> >> > >supported in all browsers we target, this simplifies code, and
> >> >>removes
> >> >> 

Re: TypeNames vs ClassName

[Alex Harui]

Hi Carlos,

I think people are more uncomfortable with the proposal to use
element.classList than any issue about order.  It is hard for me to truly
understand without seeing code so I think you should push it to your
branch.

I agree with Piotr that we can't make the users (app dev) use classList.
Folks are going to use className out of habit or because they are
borrowing a code snippet from the web.

But most important, real users like Alina need components that work and
I'm not convinced she's going to look under-the-hood.  It is frustrating
to me that we have lots of emulation components to write but instead we
are discussing details of typeNames and classNames.  IMO, it just isn't as
important.  If it isn't broken, don't fix it.  Learn to live with some
imperfections.  The big picture is that migration has to work.

Your work on having a default look is important because that will be the
default look for Alina's and others apps, but again, I don't agree that it
is important to make the underlying implementation perfect.  Nobody will
even look under the hood unless there are enough emulation components that
have a chance of working, even imperfectly.

My 2 cents,
-Alex

On 3/12/18, 10:58 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>since Piotr and Harbs seems not to be very comfortable with the change, I
>can subclass UIBase for Jewel and make that changes there. I don't want to
>conflict in such central point of the framework,
>Will it be ok for all of us?
>
>2018-03-12 18:56 GMT+01:00 Alex Harui :
>
>> IMO, the order isn't going to make or break Royale.  Leave it as you
>>have
>> it and we'll see what our users think.
>>
>> -Alex
>>
>> On 3/12/18, 10:49 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi
>> >
>> >sorry guys, I changed it since I thought I would not matter anyone.
>>For me
>> >is just the opposite. Feels very strange to me see things right to
>>left,
>> >is like description of folders, bread crumbs and something like this
>>that
>> >use to be from parent to child, and left to right
>> >
>> >I do that as well since for example Harbs said doesn't mind how final
>>code
>> >looks, but for me is important.
>> >
>> >do you want I reverse the commit? Is there a way to make it
>>configurable
>> >and be all happy? maybe I should subclass UIBase fo Jewel...
>> >
>> >
>> >2018-03-12 18:01 GMT+01:00 Piotr Zarzycki :
>> >
>> >> 2018-03-12 17:14 GMT+01:00 Alex Harui :
>> >>
>> >> > If HTMLElement.classList is exposed to the user (the app developer)
>> >>then
>> >> > they can remove any of the items that were added from the
>>typenames.
>> >> > There is no way to enforce immutability of the typenames.  We can
>> >>choose
>> >> > to give up on that and require that app developers be careful, but
>>I'd
>> >> > rather not.
>> >> >
>> >> > Given that, if you've found a way to eliminate the need for
>> >>CSSClassList,
>> >> > that's great.
>> >> >
>> >> > IMO, the immutable things from typenames should be last in the
>>list.
>> >>My
>> >> > eye reads left to right and doesn't want to have to skip over stuff
>> >>that
>> >> > will be the same.
>> >> >
>> >> >
>> >>
>> >> *TOTALLY *agree with that. I tend to omit stuff because it looks the
>> >>same,
>> >> so having typedefs at the beginning makes it so like that.
>> >>
>> >> Piotr
>> >>
>> >>
>> >>
>> >> > My 2 cents,
>> >> > -Alex
>> >> >
>> >> > On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >> Rovira"
>> >> > 
>>wrote:
>> >> >
>> >> > >Hi
>> >> > >
>> >> > >I made some simplification that works ok in Jewel:
>> >> > >
>> >> > >1.- remove CSSClassList and use element.classList since is native
>>and
>> >> > >supported in all browsers we target, this simplifies code, and
>> >>removes
>> >> > >classes from core.
>> >> > >2.- I still need to use some additional code that can be
>>simplified.
>> >>I'm
>> >> > >doing:
>> >> > >
>> >> > >element.classList.toggle("primary", value);
>> >> > >setClassName(computeFinalClassNames());
>> >> > >classList has its own toggle function that makes super easy to
>>manage
>> >> adds
>> >> > >and removes, so no need to have a custom function in royale
>> >> > >
>> >> > >that uses:
>> >> > >
>> >> > >COMPILE::JS
>> >> > >override protected function computeFinalClassNames():String
>> >> > >{
>> >> > >return super.computeFinalClassNames() + " " + element.classList;
>> >> > >}
>> >> > >
>> >> > >I'd like to remove that and change the "setClassName" call to
>> >>nothing,
>> >> if
>> >> > >we change UIBase to simple use classList
>> >> > >
>> >> > >My guess is that we can have "typenames" and "classNames" but once
>> >>all
>> >> > >set,
>> >> > >all can be managed with classList to 

Re: TypeNames vs ClassName

[Carlos Rovira]

Hi Alex,

since Piotr and Harbs seems not to be very comfortable with the change, I
can subclass UIBase for Jewel and make that changes there. I don't want to
conflict in such central point of the framework,
Will it be ok for all of us?

2018-03-12 18:56 GMT+01:00 Alex Harui :

> IMO, the order isn't going to make or break Royale.  Leave it as you have
> it and we'll see what our users think.
>
> -Alex
>
> On 3/12/18, 10:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi
> >
> >sorry guys, I changed it since I thought I would not matter anyone. For me
> >is just the opposite. Feels very strange to me see things right to left,
> >is like description of folders, bread crumbs and something like this that
> >use to be from parent to child, and left to right
> >
> >I do that as well since for example Harbs said doesn't mind how final code
> >looks, but for me is important.
> >
> >do you want I reverse the commit? Is there a way to make it configurable
> >and be all happy? maybe I should subclass UIBase fo Jewel...
> >
> >
> >2018-03-12 18:01 GMT+01:00 Piotr Zarzycki :
> >
> >> 2018-03-12 17:14 GMT+01:00 Alex Harui :
> >>
> >> > If HTMLElement.classList is exposed to the user (the app developer)
> >>then
> >> > they can remove any of the items that were added from the typenames.
> >> > There is no way to enforce immutability of the typenames.  We can
> >>choose
> >> > to give up on that and require that app developers be careful, but I'd
> >> > rather not.
> >> >
> >> > Given that, if you've found a way to eliminate the need for
> >>CSSClassList,
> >> > that's great.
> >> >
> >> > IMO, the immutable things from typenames should be last in the list.
> >>My
> >> > eye reads left to right and doesn't want to have to skip over stuff
> >>that
> >> > will be the same.
> >> >
> >> >
> >>
> >> *TOTALLY *agree with that. I tend to omit stuff because it looks the
> >>same,
> >> so having typedefs at the beginning makes it so like that.
> >>
> >> Piotr
> >>
> >>
> >>
> >> > My 2 cents,
> >> > -Alex
> >> >
> >> > On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >> Rovira"
> >> >  wrote:
> >> >
> >> > >Hi
> >> > >
> >> > >I made some simplification that works ok in Jewel:
> >> > >
> >> > >1.- remove CSSClassList and use element.classList since is native and
> >> > >supported in all browsers we target, this simplifies code, and
> >>removes
> >> > >classes from core.
> >> > >2.- I still need to use some additional code that can be simplified.
> >>I'm
> >> > >doing:
> >> > >
> >> > >element.classList.toggle("primary", value);
> >> > >setClassName(computeFinalClassNames());
> >> > >classList has its own toggle function that makes super easy to manage
> >> adds
> >> > >and removes, so no need to have a custom function in royale
> >> > >
> >> > >that uses:
> >> > >
> >> > >COMPILE::JS
> >> > >override protected function computeFinalClassNames():String
> >> > >{
> >> > >return super.computeFinalClassNames() + " " + element.classList;
> >> > >}
> >> > >
> >> > >I'd like to remove that and change the "setClassName" call to
> >>nothing,
> >> if
> >> > >we change UIBase to simple use classList
> >> > >
> >> > >My guess is that we can have "typenames" and "classNames" but once
> >>all
> >> > >set,
> >> > >all can be managed with classList to add/remove since this is native
> >>and
> >> > >manages all itself
> >> > >
> >> > >thoughts?
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >2018-03-12 14:01 GMT+01:00 Carlos Rovira :
> >> > >
> >> > >> Hi,
> >> > >>
> >> > >> long thread and very useful read here. Since Jewel is very similar
> >>to
> >> > >>MDL
> >> > >> in adding/removing classes I want to comment here some things:
> >> > >>
> >> > >> 1.- I just changed jewel typenames to the constructor and things
> >>works
> >> > >>ok,
> >> > >> I could remove the createElement override
> >> > >> 2.- I have into account the use of typenames as something inmutable
> >> (as
> >> > >> part of definition of a component) and classNames as things that
> >>are
> >> > >>put by
> >> > >> developer, or change at runtime due to some user operation
> >> > >>
> >> > >> Then:
> >> > >>
> >> > >> 3.- Why not use classList [1] instead of create our own
> >>CSSClassList ?
> >> > >>is
> >> > >> well supported in the browsers we are targeting
> >> > >>
> >> > >> Something more "light" :)
> >> > >>
> >> > >> 4.- I know that order in html classes are not relevant, in the
> >> > >>execution.
> >> > >> And most of people here doesn't mind if typenames are before or
> >>after
> >> > >> classNames. So hope this doesn't make any problem to anyone here:
> >> > >> Can I change the code to put typeNames before classNames in
> >> > >> computeFinalClassNames? I think this not affects anyone since is 

Re: TypeNames vs ClassName

[Carlos Rovira]

Hi Piotr,

I was reding from the begging and saw when the CSSClassList came.

I think Harbs solution is ok, the only problem I see is that in MDL, and
Jewel, we need to have functions per class that manages
add/remove of classes and override of compute function. That's what I don't
like of current solution.

As well I don't see in all the thread a mention to element.classList

for the two problems you mention, I expect very few lines in the
jewel-framework.css (css rules very close to frmaework code)
but anyway, I think debugging will not help you with something like this
when you have a line in code that sets display:block or
changes the elements classes.

For second, the code you're referring was not final in any way, I committed
since I want to fix and commit other things
I'm still trying and testing different approaches as I get to final
conclusions, so please don't take that as something final.

About searching vertical layout (if that would be final code), you only
need to search in jewel-framework.css that will only hold ClassReference
properties
in css rules and things like this (layouts) that are very close to the code
and will never go to a theme.

I think my approach is less monolithic since I'm separating concerns.

Piotr, I must say I'm very happy with today findings, but I need to
continue evolving it to avoid that you and others look to an unfinished
work
and take conclusions of things that will not be as they are currently



2018-03-12 17:58 GMT+01:00 Piotr Zarzycki :

> Hi Carlos,
>
> That's why we are using Harb's solution with his own class list. If you
> went through this long thread carefully I have an issue which end up with
> that solution. The problem was exactly as Harb's mention. Try it yourself.
>
> Another great things which Harb's bring up here is why I also like Royale.
>
> 1) I had really hard time to debug things when something was in CSS file
> only not as inline in some Bead or Code. - That was really pain and I had
> quite short css file. Imagine having 1000 lines in such file ?
> 2) I saw your commit and one question which come up to my mind. If you have
> following line:
>
> child.className += " layout vertical";
>
> You hit in your IDE CTRL/CMD and try to click on " layout vertical" - does
> it jump to the proper css classes in file ?
>
> If not - That is another disadvantage of that approach - How do I find my
> "layout vertical" class among 1000 lines and many css files in the project
> ?
>
> I really really don't want that our framework will turns into an monolithic
> AngularJS. Just because the other are doing things in that way we don't
> have to follow, because we turn things in a mess.
>
> I will shot you some thoughts to the code on GitHub.
>
> Thanks, Piotr
>
>
> 2018-03-12 17:21 GMT+01:00 Harbs :
>
> > I’m pretty sure your solution will only work if the user doesn’t set a
> > className of their own. Setting className overwrites the entire
> classList.
> >
> > > On Mar 12, 2018, at 5:45 PM, Carlos Rovira 
> > wrote:
> > >
> > > Hi
> > >
> > > I made some simplification that works ok in Jewel:
> > >
> > > 1.- remove CSSClassList and use element.classList since is native and
> > > supported in all browsers we target, this simplifies code, and removes
> > > classes from core.
> > > 2.- I still need to use some additional code that can be simplified.
> I'm
> > > doing:
> > >
> > > element.classList.toggle("primary", value);
> > > setClassName(computeFinalClassNames());
> > > classList has its own toggle function that makes super easy to manage
> > adds
> > > and removes, so no need to have a custom function in royale
> > >
> > > that uses:
> > >
> > > COMPILE::JS
> > > override protected function computeFinalClassNames():String
> > > {
> > > return super.computeFinalClassNames() + " " + element.classList;
> > > }
> > >
> > > I'd like to remove that and change the "setClassName" call to nothing,
> if
> > > we change UIBase to simple use classList
> > >
> > > My guess is that we can have "typenames" and "classNames" but once all
> > set,
> > > all can be managed with classList to add/remove since this is native
> and
> > > manages all itself
> > >
> > > thoughts?
> > >
> > >
> > >
> > >
> > >
> > > 2018-03-12 14:01 GMT+01:00 Carlos Rovira :
> > >
> > >> Hi,
> > >>
> > >> long thread and very useful read here. Since Jewel is very similar to
> > MDL
> > >> in adding/removing classes I want to comment here some things:
> > >>
> > >> 1.- I just changed jewel typenames to the constructor and things works
> > ok,
> > >> I could remove the createElement override
> > >> 2.- I have into account the use of typenames as something inmutable
> (as
> > >> part of definition of a component) and classNames as things that are
> > put by
> > >> developer, or change at runtime due to some user operation
> > >>
> > >> Then:
> > >>
> > >> 3.- Why not use classList [1] instead of create 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

2018-03-12 17:14 GMT+01:00 Alex Harui :

> If HTMLElement.classList is exposed to the user (the app developer) then
> they can remove any of the items that were added from the typenames.
> There is no way to enforce immutability of the typenames.  We can choose
> to give up on that and require that app developers be careful, but I'd
> rather not.
>
> Given that, if you've found a way to eliminate the need for CSSClassList,
> that's great.
>
> IMO, the immutable things from typenames should be last in the list.  My
> eye reads left to right and doesn't want to have to skip over stuff that
> will be the same.
>
>

*TOTALLY *agree with that. I tend to omit stuff because it looks the same,
so having typedefs at the beginning makes it so like that.

Piotr



> My 2 cents,
> -Alex
>
> On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi
> >
> >I made some simplification that works ok in Jewel:
> >
> >1.- remove CSSClassList and use element.classList since is native and
> >supported in all browsers we target, this simplifies code, and removes
> >classes from core.
> >2.- I still need to use some additional code that can be simplified. I'm
> >doing:
> >
> >element.classList.toggle("primary", value);
> >setClassName(computeFinalClassNames());
> >classList has its own toggle function that makes super easy to manage adds
> >and removes, so no need to have a custom function in royale
> >
> >that uses:
> >
> >COMPILE::JS
> >override protected function computeFinalClassNames():String
> >{
> >return super.computeFinalClassNames() + " " + element.classList;
> >}
> >
> >I'd like to remove that and change the "setClassName" call to nothing, if
> >we change UIBase to simple use classList
> >
> >My guess is that we can have "typenames" and "classNames" but once all
> >set,
> >all can be managed with classList to add/remove since this is native and
> >manages all itself
> >
> >thoughts?
> >
> >
> >
> >
> >
> >2018-03-12 14:01 GMT+01:00 Carlos Rovira :
> >
> >> Hi,
> >>
> >> long thread and very useful read here. Since Jewel is very similar to
> >>MDL
> >> in adding/removing classes I want to comment here some things:
> >>
> >> 1.- I just changed jewel typenames to the constructor and things works
> >>ok,
> >> I could remove the createElement override
> >> 2.- I have into account the use of typenames as something inmutable (as
> >> part of definition of a component) and classNames as things that are
> >>put by
> >> developer, or change at runtime due to some user operation
> >>
> >> Then:
> >>
> >> 3.- Why not use classList [1] instead of create our own CSSClassList ?
> >>is
> >> well supported in the browsers we are targeting
> >>
> >> Something more "light" :)
> >>
> >> 4.- I know that order in html classes are not relevant, in the
> >>execution.
> >> And most of people here doesn't mind if typenames are before or after
> >> classNames. So hope this doesn't make any problem to anyone here:
> >> Can I change the code to put typeNames before classNames in
> >> computeFinalClassNames? I think this not affects anyone since is a small
> >> change and helps me to get organized classnames and identify things. I
> >> think is better to see in final html typeNames first then classNames so
> >> "inheritance" (to call it some way), could be easy detected by the eye
> >>
> >> Thanks
> >>
> >> Carlos
> >>
> >>
> >> [1]
> >>https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.w3sc
> >>hools.com%2FJsref%2Fprop_element_classlist.asp=02%
> 7C01%7Caharui%40ad
> >>obe.com%7C5fee37306b5f47f8664608d588305aef%
> 7Cfa7b1b5a7b34438794aed2c178de
> >>cee1%7C0%7C0%7C636564663624913122=EjW00lpVegbpFVp2%2FzQz%
> 2FQZnsNcB1
> >>G6R%2BkMSMIjboX0%3D=0
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Carlos Rovira
> >>
> >>https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%
> >>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C5fee37306b5f47f8664608
> >>d588305aef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C63656466362491312
> >>2=XjaCDhDlj5GDGyIiHc7fKzg8zsKxIrcEoVel%2Ffj7qmI%3D=0
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C5fee37306b5f47f8664608d5
> >88305aef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636564663624913122
> >data=XjaCDhDlj5GDGyIiHc7fKzg8zsKxIrcEoVel%2Ffj7qmI%3D=0
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: TypeNames vs ClassName

[Alex Harui]

Well, it isn't fair if someone writes to element.className, but we control
what happens when someone writes to UIBase.className.  I just want it to
be as simple as possible and PAYG.

-Alex

On 3/12/18, 9:21 AM, "Harbs"  wrote:

>I’m pretty sure your solution will only work if the user doesn’t set a
>className of their own. Setting className overwrites the entire classList.
>
>> On Mar 12, 2018, at 5:45 PM, Carlos Rovira 
>>wrote:
>> 
>> Hi
>> 
>> I made some simplification that works ok in Jewel:
>> 
>> 1.- remove CSSClassList and use element.classList since is native and
>> supported in all browsers we target, this simplifies code, and removes
>> classes from core.
>> 2.- I still need to use some additional code that can be simplified. I'm
>> doing:
>> 
>> element.classList.toggle("primary", value);
>> setClassName(computeFinalClassNames());
>> classList has its own toggle function that makes super easy to manage
>>adds
>> and removes, so no need to have a custom function in royale
>> 
>> that uses:
>> 
>> COMPILE::JS
>> override protected function computeFinalClassNames():String
>> {
>> return super.computeFinalClassNames() + " " + element.classList;
>> }
>> 
>> I'd like to remove that and change the "setClassName" call to nothing,
>>if
>> we change UIBase to simple use classList
>> 
>> My guess is that we can have "typenames" and "classNames" but once all
>>set,
>> all can be managed with classList to add/remove since this is native and
>> manages all itself
>> 
>> thoughts?
>> 
>> 
>> 
>> 
>> 
>> 2018-03-12 14:01 GMT+01:00 Carlos Rovira :
>> 
>>> Hi,
>>> 
>>> long thread and very useful read here. Since Jewel is very similar to
>>>MDL
>>> in adding/removing classes I want to comment here some things:
>>> 
>>> 1.- I just changed jewel typenames to the constructor and things works
>>>ok,
>>> I could remove the createElement override
>>> 2.- I have into account the use of typenames as something inmutable (as
>>> part of definition of a component) and classNames as things that are
>>>put by
>>> developer, or change at runtime due to some user operation
>>> 
>>> Then:
>>> 
>>> 3.- Why not use classList [1] instead of create our own CSSClassList ?
>>>is
>>> well supported in the browsers we are targeting
>>> 
>>> Something more "light" :)
>>> 
>>> 4.- I know that order in html classes are not relevant, in the
>>>execution.
>>> And most of people here doesn't mind if typenames are before or after
>>> classNames. So hope this doesn't make any problem to anyone here:
>>> Can I change the code to put typeNames before classNames in
>>> computeFinalClassNames? I think this not affects anyone since is a
>>>small
>>> change and helps me to get organized classnames and identify things. I
>>> think is better to see in final html typeNames first then classNames so
>>> "inheritance" (to call it some way), could be easy detected by the eye
>>> 
>>> Thanks
>>> 
>>> Carlos
>>> 
>>> 
>>> [1] 
>>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3s
>>>chools.com%2FJsref%2Fprop_element_classlist.asp=02%7C01%7Caharui%40
>>>adobe.com%7C8ce390a012154f8f2a8a08d588354aa0%7Cfa7b1b5a7b34438794aed2c17
>>>8decee1%7C0%7C0%7C636564684909764090=OOh4TK5LKB75CGn6U4%2BeaVC%2Fi
>>>V%2BHgGzDj8fqrBB%2BCcs%3D=0
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Carlos Rovira
>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C8ce390a012154f8f2a8a
>>>08d588354aa0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656468490976
>>>4090=HDNJQ8VZuNS5lhOBU2ZsRrGQAgG5qOxiIQJKkOaTZV4%3D=0
>>> 
>>> 
>> 
>> 
>> -- 
>> Carlos Rovira
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C8ce390a012154f8f2a8a08
>>d588354aa0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656468490976409
>>0=HDNJQ8VZuNS5lhOBU2ZsRrGQAgG5qOxiIQJKkOaTZV4%3D=0
>

Re: TypeNames vs ClassName

[Harbs]

I’m pretty sure your solution will only work if the user doesn’t set a 
className of their own. Setting className overwrites the entire classList.

> On Mar 12, 2018, at 5:45 PM, Carlos Rovira  wrote:
> 
> Hi
> 
> I made some simplification that works ok in Jewel:
> 
> 1.- remove CSSClassList and use element.classList since is native and
> supported in all browsers we target, this simplifies code, and removes
> classes from core.
> 2.- I still need to use some additional code that can be simplified. I'm
> doing:
> 
> element.classList.toggle("primary", value);
> setClassName(computeFinalClassNames());
> classList has its own toggle function that makes super easy to manage adds
> and removes, so no need to have a custom function in royale
> 
> that uses:
> 
> COMPILE::JS
> override protected function computeFinalClassNames():String
> {
> return super.computeFinalClassNames() + " " + element.classList;
> }
> 
> I'd like to remove that and change the "setClassName" call to nothing, if
> we change UIBase to simple use classList
> 
> My guess is that we can have "typenames" and "classNames" but once all set,
> all can be managed with classList to add/remove since this is native and
> manages all itself
> 
> thoughts?
> 
> 
> 
> 
> 
> 2018-03-12 14:01 GMT+01:00 Carlos Rovira :
> 
>> Hi,
>> 
>> long thread and very useful read here. Since Jewel is very similar to MDL
>> in adding/removing classes I want to comment here some things:
>> 
>> 1.- I just changed jewel typenames to the constructor and things works ok,
>> I could remove the createElement override
>> 2.- I have into account the use of typenames as something inmutable (as
>> part of definition of a component) and classNames as things that are put by
>> developer, or change at runtime due to some user operation
>> 
>> Then:
>> 
>> 3.- Why not use classList [1] instead of create our own CSSClassList ? is
>> well supported in the browsers we are targeting
>> 
>> Something more "light" :)
>> 
>> 4.- I know that order in html classes are not relevant, in the execution.
>> And most of people here doesn't mind if typenames are before or after
>> classNames. So hope this doesn't make any problem to anyone here:
>> Can I change the code to put typeNames before classNames in
>> computeFinalClassNames? I think this not affects anyone since is a small
>> change and helps me to get organized classnames and identify things. I
>> think is better to see in final html typeNames first then classNames so
>> "inheritance" (to call it some way), could be easy detected by the eye
>> 
>> Thanks
>> 
>> Carlos
>> 
>> 
>> [1] https://www.w3schools.com/Jsref/prop_element_classlist.asp
>> 
>> 
>> 
>> 
>> 
>> 
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>> 
>> 
> 
> 
> -- 
> Carlos Rovira
> http://about.me/carlosrovira

Re: TypeNames vs ClassName

[Alex Harui]

If HTMLElement.classList is exposed to the user (the app developer) then
they can remove any of the items that were added from the typenames.
There is no way to enforce immutability of the typenames.  We can choose
to give up on that and require that app developers be careful, but I'd
rather not.

Given that, if you've found a way to eliminate the need for CSSClassList,
that's great.

IMO, the immutable things from typenames should be last in the list.  My
eye reads left to right and doesn't want to have to skip over stuff that
will be the same.

My 2 cents,
-Alex

On 3/12/18, 8:45 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi
>
>I made some simplification that works ok in Jewel:
>
>1.- remove CSSClassList and use element.classList since is native and
>supported in all browsers we target, this simplifies code, and removes
>classes from core.
>2.- I still need to use some additional code that can be simplified. I'm
>doing:
>
>element.classList.toggle("primary", value);
>setClassName(computeFinalClassNames());
>classList has its own toggle function that makes super easy to manage adds
>and removes, so no need to have a custom function in royale
>
>that uses:
>
>COMPILE::JS
>override protected function computeFinalClassNames():String
>{
>return super.computeFinalClassNames() + " " + element.classList;
>}
>
>I'd like to remove that and change the "setClassName" call to nothing, if
>we change UIBase to simple use classList
>
>My guess is that we can have "typenames" and "classNames" but once all
>set,
>all can be managed with classList to add/remove since this is native and
>manages all itself
>
>thoughts?
>
>
>
>
>
>2018-03-12 14:01 GMT+01:00 Carlos Rovira :
>
>> Hi,
>>
>> long thread and very useful read here. Since Jewel is very similar to
>>MDL
>> in adding/removing classes I want to comment here some things:
>>
>> 1.- I just changed jewel typenames to the constructor and things works
>>ok,
>> I could remove the createElement override
>> 2.- I have into account the use of typenames as something inmutable (as
>> part of definition of a component) and classNames as things that are
>>put by
>> developer, or change at runtime due to some user operation
>>
>> Then:
>>
>> 3.- Why not use classList [1] instead of create our own CSSClassList ?
>>is
>> well supported in the browsers we are targeting
>>
>> Something more "light" :)
>>
>> 4.- I know that order in html classes are not relevant, in the
>>execution.
>> And most of people here doesn't mind if typenames are before or after
>> classNames. So hope this doesn't make any problem to anyone here:
>> Can I change the code to put typeNames before classNames in
>> computeFinalClassNames? I think this not affects anyone since is a small
>> change and helps me to get organized classnames and identify things. I
>> think is better to see in final html typeNames first then classNames so
>> "inheritance" (to call it some way), could be easy detected by the eye
>>
>> Thanks
>>
>> Carlos
>>
>>
>> [1] 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3sc
>>hools.com%2FJsref%2Fprop_element_classlist.asp=02%7C01%7Caharui%40ad
>>obe.com%7C5fee37306b5f47f8664608d588305aef%7Cfa7b1b5a7b34438794aed2c178de
>>cee1%7C0%7C0%7C636564663624913122=EjW00lpVegbpFVp2%2FzQz%2FQZnsNcB1
>>G6R%2BkMSMIjboX0%3D=0
>>
>>
>>
>>
>>
>>
>> --
>> Carlos Rovira
>> 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C5fee37306b5f47f8664608
>>d588305aef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63656466362491312
>>2=XjaCDhDlj5GDGyIiHc7fKzg8zsKxIrcEoVel%2Ffj7qmI%3D=0
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C5fee37306b5f47f8664608d5
>88305aef%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636564663624913122
>data=XjaCDhDlj5GDGyIiHc7fKzg8zsKxIrcEoVel%2Ffj7qmI%3D=0

Re: TypeNames vs ClassName

[Carlos Rovira]

Hi

I made some simplification that works ok in Jewel:

1.- remove CSSClassList and use element.classList since is native and
supported in all browsers we target, this simplifies code, and removes
classes from core.
2.- I still need to use some additional code that can be simplified. I'm
doing:

element.classList.toggle("primary", value);
setClassName(computeFinalClassNames());
classList has its own toggle function that makes super easy to manage adds
and removes, so no need to have a custom function in royale

that uses:

COMPILE::JS
override protected function computeFinalClassNames():String
{
return super.computeFinalClassNames() + " " + element.classList;
}

I'd like to remove that and change the "setClassName" call to nothing, if
we change UIBase to simple use classList

My guess is that we can have "typenames" and "classNames" but once all set,
all can be managed with classList to add/remove since this is native and
manages all itself

thoughts?





2018-03-12 14:01 GMT+01:00 Carlos Rovira :

> Hi,
>
> long thread and very useful read here. Since Jewel is very similar to MDL
> in adding/removing classes I want to comment here some things:
>
> 1.- I just changed jewel typenames to the constructor and things works ok,
> I could remove the createElement override
> 2.- I have into account the use of typenames as something inmutable (as
> part of definition of a component) and classNames as things that are put by
> developer, or change at runtime due to some user operation
>
> Then:
>
> 3.- Why not use classList [1] instead of create our own CSSClassList ? is
> well supported in the browsers we are targeting
>
> Something more "light" :)
>
> 4.- I know that order in html classes are not relevant, in the execution.
> And most of people here doesn't mind if typenames are before or after
> classNames. So hope this doesn't make any problem to anyone here:
> Can I change the code to put typeNames before classNames in
> computeFinalClassNames? I think this not affects anyone since is a small
> change and helps me to get organized classnames and identify things. I
> think is better to see in final html typeNames first then classNames so
> "inheritance" (to call it some way), could be easy detected by the eye
>
> Thanks
>
> Carlos
>
>
> [1] https://www.w3schools.com/Jsref/prop_element_classlist.asp
>
>
>
>
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>
>


-- 
Carlos Rovira
http://about.me/carlosrovira

Re: TypeNames vs ClassName

[Carlos Rovira]

Hi,

long thread and very useful read here. Since Jewel is very similar to MDL
in adding/removing classes I want to comment here some things:

1.- I just changed jewel typenames to the constructor and things works ok,
I could remove the createElement override
2.- I have into account the use of typenames as something inmutable (as
part of definition of a component) and classNames as things that are put by
developer, or change at runtime due to some user operation

Then:

3.- Why not use classList [1] instead of create our own CSSClassList ? is
well supported in the browsers we are targeting

Something more "light" :)

4.- I know that order in html classes are not relevant, in the execution.
And most of people here doesn't mind if typenames are before or after
classNames. So hope this doesn't make any problem to anyone here:
Can I change the code to put typeNames before classNames in
computeFinalClassNames? I think this not affects anyone since is a small
change and helps me to get organized classnames and identify things. I
think is better to see in final html typeNames first then classNames so
"inheritance" (to call it some way), could be easy detected by the eye

Thanks

Carlos


[1] https://www.w3schools.com/Jsref/prop_element_classlist.asp






-- 
Carlos Rovira
http://about.me/carlosrovira

Re: TypeNames vs ClassName

[Alex Harui]

Harbs please post code snippets so we can understand what you are
referring to.  I'm not too concerned about how much code is baked into
MDL, but I'm more interested in the notion that there are just-in-case
patterns that are somehow more optimal than on-demand patterns.  I'm
thinking there are ways to write the on-demand patterns so they are better
in all measurements than just-in-case.

Let's start with a scenario or two and use MDL Button since it is an
actual thing used in some examples.  Isn't scenario #1 just using a plain
MDL Button with no attributes?  And scenario #2 using a MDL Button with
some attribute?

What code runs when no attributes and with one attribute with and without
your proposed CSSClassList class?

Thanks,
-Alex

On 3/5/18, 3:11 AM, "Harbs"  wrote:

>
>> On Mar 5, 2018, at 2:18 AM, Alex Harui  wrote:
>> 
>> Why are there so many empty strings and why do the cot so much?  Should
>> we reference a single global empty string?
>
>If you mean in XML, I eliminated initializing *everything* in XML unless
>needed and I saw a drastic reduction in use of memory. I also reuse Names
>which likewise reduced a lot of memory usage.
>
>In this case, it’s necessary to initialize the strings or add checking
>code.
>
>> I don't think I follow why just-in-case code is less than
>>not-just-in-case
>> code.  I don't think I've ever really seen that.  Can you provide more
>> detail?
>
>There *is no* "just in case" code here. We *need* to add one of three
>things to the MDL Button class and there’s trade-offs between all three.
>
>1. Empty strings with string concatenation
>2. An array to hold the strings
>3. A class which constructs the array and fills it as needed.
>
>#1 adds the most code and IMO overhead to the MDL Button class
>#2 initializes an array or has to add a getter which lazy initializes the
>array.
>#3 has an initially empty object which lazy intializes an array and
>populates it as needed.
>
>#2 and #3 are roughly equivalent in terms of object initialization.
>There’s not much difference between initializing and object or an array
>in JS.
>
>#2 puts the “add”, “remove” and “compute” code inside the Button class,
>while #3 moves it out into its own class which could be reused in other
>situations.
>
>Moving it into a class does add a bit of code inherent to classes in
>Royale, but I maintain that it’s minimal, and the value of being able to
>reuse it at no extra cost makes it justifiable.
>
>It is probably possible that we can have a package level function which
>returns an IStringList which would in fact be a javascript
>object/function which has the methods built in at no extra code cost, but
>that feels a bit hacky...
>
>Harbs
>
>* In truth there is a bit of just in case code in the CSSClassList class.
>There is range checking in the add method which could probably be
>removed. The range checking in the remove method is probably needed
>because we’re not enforcing initialization of booleans.
>
>> 
>> -Alex
>> 
>> On 3/4/18, 5:24 AM, "Harbs"  wrote:
>> 
>>> 
 On Mar 2, 2018, at 6:46 PM, Alex Harui 
wrote:
 
 Again, the principles of PAYG are that there is as little Just-in-case
 code as possible.  AIUI, every MDL user will be downloading and
 initializing the ClassList prototype just-in-case.  This is not true
of
 Strings.  It isn't just the cost of instantiation.  There are download
 and
 class initialization costs.
>>> 
>>> Not every MDL user. Only users of Button (and possibly Card). The final
>>> minimized (non-gzipped) size of the class is 492 bytes. I’m actually
>>>not
>>> sre why it’s not even smaller. I’m getting odd code which looks like
>>> this: 
>>> 
>>>AT.prototype.add=AT.prototype.add;AT.prototype.remove=AT.prototype.remov
>>>e;
>>> I’m not sure why goog is outputting this.
>>> 
>>> While there are download costs, about half of those costs are offset by
>>> less string initialization and concatenation code in Button. The more
>>> classes which use the class will offset the cost of the class even
>>> further.
>>> 
 Array operations are not cheap in Flash, not
 sure about JS.
>>> 
>>> In JS, the array operations in use are abot the same as the string
>>> operations. In fact, it’s going to be cheaper and use less RAM if not
>>>all
>>> the properties are used.
>>> 
>>> So, it’s a toss between a slightly higher download size which gets
>>> amortized the more it’s used vs memory resources. I’m not sure why
>>>you’re
>>> considering it more PAYG to avoid the use of the class.
>>> 
>>> As a data point: I found that empty strings in XML classes added many
>>>MB
>>> of RAM usage when XML was used heavily in my app. While I doubt someone
>>> will be using thousands of MDL Buttons, RAM from empty strings are
>>> sometimes worthy of consideration.
>>> 
>>> The “costs” one way or the other here is pretty minimal no matter which
>>> waywe go.

Re: TypeNames vs ClassName

[Harbs]

> On Mar 5, 2018, at 2:18 AM, Alex Harui  wrote:
> 
> Why are there so many empty strings and why do the cost so much?  Should
> we reference a single global empty string?

If you mean in XML, I eliminated initializing *everything* in XML unless needed 
and I saw a drastic reduction in use of memory. I also reuse Names which 
likewise reduced a lot of memory usage.

In this case, it’s necessary to initialize the strings or add checking code.

> I don't think I follow why just-in-case code is less than not-just-in-case
> code.  I don't think I've ever really seen that.  Can you provide more
> detail?

There *is no* "just in case" code here. We *need* to add one of three things to 
the MDL Button class and there’s trade-offs between all three.

1. Empty strings with string concatenation
2. An array to hold the strings
3. A class which constructs the array and fills it as needed.

#1 adds the most code and IMO overhead to the MDL Button class
#2 initializes an array or has to add a getter which lazy initializes the array.
#3 has an initially empty object which lazy initializes an array and populates 
it as needed.

#2 and #3 are roughly equivalent in terms of object initialization. There’s not 
much difference between initializing and object or an array in JS.

#2 puts the “add”, “remove” and “compute” code inside the Button class, while 
#3 moves it out into its own class which could be reused in other situations.

Moving it into a class does add a bit of code inherent to classes in Royale, 
but I maintain that it’s minimal, and the value of being able to reuse it at no 
extra cost makes it justifiable.

It is probably possible that we can have a package level function which returns 
an IStringList which would in fact be a javascript object/function which has 
the methods built in at no extra code cost, but that feels a bit hacky...

Harbs

* In truth there is a bit of just in case code in the CSSClassList class. There 
is range checking in the add method which could probably be removed. The range 
checking in the remove method is probably needed because we’re not enforcing 
initialization of booleans.

> 
> -Alex
> 
> On 3/4/18, 5:24 AM, "Harbs"  wrote:
> 
>> 
>>> On Mar 2, 2018, at 6:46 PM, Alex Harui  wrote:
>>> 
>>> Again, the principles of PAYG are that there is as little Just-in-case
>>> code as possible.  AIUI, every MDL user will be downloading and
>>> initializing the ClassList prototype just-in-case.  This is not true of
>>> Strings.  It isn't just the cost of instantiation.  There are download
>>> and
>>> class initialization costs.
>> 
>> Not every MDL user. Only users of Button (and possibly Card). The final
>> minimized (non-gzipped) size of the class is 492 bytes. I’m actually not
>> sure why it’s not even smaller. I’m getting odd code which looks like
>> this: 
>> AT.prototype.add=AT.prototype.add;AT.prototype.remove=AT.prototype.remove;
>> I’m not sure why goog is outputting this.
>> 
>> While there are download costs, about half of those costs are offset by
>> less string initialization and concatenation code in Button. The more
>> classes which use the class will offset the cost of the class even
>> further.
>> 
>>> Array operations are not cheap in Flash, not
>>> sure about JS.
>> 
>> In JS, the array operations in use are about the same as the string
>> operations. In fact, it’s going to be cheaper and use less RAM if not all
>> the properties are used.
>> 
>> So, it’s a toss between a slightly higher download size which gets
>> amortized the more it’s used vs memory resources. I’m not sure why you’re
>> considering it more PAYG to avoid the use of the class.
>> 
>> As a data point: I found that empty strings in XML classes added many MB
>> of RAM usage when XML was used heavily in my app. While I doubt someone
>> will be using thousands of MDL Buttons, RAM from empty strings are
>> sometimes worthy of consideration.
>> 
>> The “costs” one way or the other here is pretty minimal no matter which
>> way we go.
>> 
>>> There may be other space-delimited lists in world and having a generic
>>> top-level function "addToSpaceDelimitedList" and
>>> "removeFromSpaceDelimitedList" would be opt-in by the users who choose
>>> to
>>> manipulate their classNames with these helper functions.  It does not
>>> make
>>> sense to me to bake use of these functions into MDL.  The only portion
>>> of
>>> the final classname that needs manipulation like this is the className
>>> property itself, not the attribute pieces or typenames.  Also, with
>>> separate will named utility functions, folks could use these functions
>>> if
>>> they run into other space delimited lists.
>> 
>> I’m not sure what you mean here. The class can be used in any context. If
>> there are other contexts, it might make sense to rename the class. Are
>> you referring to arrays or strings? I’m pretty sure we’re going to come
>> up with other uses for passing 

Re: TypeNames vs ClassName

[Harbs]

> On Mar 2, 2018, at 6:46 PM, Alex Harui  wrote:
> 
> Again, the principles of PAYG are that there is as little Just-in-case
> code as possible.  AIUI, every MDL user will be downloading and
> initializing the ClassList prototype just-in-case.  This is not true of
> Strings.  It isn't just the cost of instantiation.  There are download and
> class initialization costs.

Not every MDL user. Only users of Button (and possibly Card). The final 
minimized (non-gzipped) size of the class is 492 bytes. I’m actually not sure 
why it’s not even smaller. I’m getting odd code which looks like this: 
AT.prototype.add=AT.prototype.add;AT.prototype.remove=AT.prototype.remove; I’m 
not sure why goog is outputting this.

While there are download costs, about half of those costs are offset by less 
string initialization and concatenation code in Button. The more classes which 
use the class will offset the cost of the class even further.

>  Array operations are not cheap in Flash, not
> sure about JS.

In JS, the array operations in use are about the same as the string operations. 
In fact, it’s going to be cheaper and use less RAM if not all the properties 
are used.

So, it’s a toss between a slightly higher download size which gets amortized 
the more it’s used vs memory resources. I’m not sure why you’re considering it 
more PAYG to avoid the use of the class.

As a data point: I found that empty strings in XML classes added many MB of RAM 
usage when XML was used heavily in my app. While I doubt someone will be using 
thousands of MDL Buttons, RAM from empty strings are sometimes worthy of 
consideration.

The “costs” one way or the other here is pretty minimal no matter which way we 
go.

> There may be other space-delimited lists in world and having a generic
> top-level function "addToSpaceDelimitedList" and
> "removeFromSpaceDelimitedList" would be opt-in by the users who choose to
> manipulate their classNames with these helper functions.  It does not make
> sense to me to bake use of these functions into MDL.  The only portion of
> the final classname that needs manipulation like this is the className
> property itself, not the attribute pieces or typenames.  Also, with
> separate will named utility functions, folks could use these functions if
> they run into other space delimited lists.

I’m not sure what you mean here. The class can be used in any context. If there 
are other contexts, it might make sense to rename the class. Are you referring 
to arrays or strings? I’m pretty sure we’re going to come up with other uses 
for passing around class lists in a way that make this class useful.

Harbs

> My 2 cents,
> -Alex
> 
> On 3/2/18, 1:36 AM, "Harbs"  > wrote:
> 
>> I do agree that this is pretty low on the list of priorities. I did not
>> have a head to work on anything “serious” and the class lists was a nice
>> distraction for me. I’m certainly fine with however Piotr handles this. I
>> would like to point out a few things:
>> 
>> 1. Object instantiation is pretty cheap in JS. A CSSClassList object is
>> no heavier than an empty String. 8 empty strings use more memory than a
>> single CSSClassList.
>> 2. Array.join() is about the same computational-wise as string
>> concatenation.
>> 3. The “list” is not being added anywhere the empty strings would not be
>> added, so it’s no less PAYG than strings.
>> 4. An instantiated class such as this would fit better in case we need to
>> play with class lists in beads because the CSSClassList object could be
>> passed around and modified by different classes without exposing private
>> variables and/or strands and beads needing to know about each other. I
>> don’t think static utility classes are any less PAYG in this case.
>> 
>> Thanks,
>> Harbs
>> 
>>> On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki 
>>> wrote:
>>> 
>>> Hi Harbs,
>>> 
>>> As much as I like Array approach I took Alex's words more serious that
>>> having an Array in the game here could be more heavier than String
>>> concatenation. It's earlier in the discussion.
>>> 
>>> Piotr
>>> 
>>> 
>>> 2018-03-02 3:26 GMT+01:00 Alex Harui :
>>> 
 Very nice, but IMO, this is over-engineering.  We are talking about a
 space-delimited list where some portion of it is considered "fixed"
 another portion is user-settable and another portion comes from other
 attributes.  Some generic StringUtils or ListUtils might be more PAYG,
 especially if they are opt-in and just used to manage the user-settable
 portion.  Think of it this way:  Every MDL app needs to carry around
 ClassList even if they never change the classname.  I don't care too
 much
 since it is in MDL and not in the core, so keep it if you want to, but
 I
 can think of lots of other tasks we should be working on than creating
 cool classes to manage a list of strings.
 

Re: TypeNames vs ClassName

[Alex Harui]

Again, the principles of PAYG are that there is as little Just-in-case
code as possible.  AIUI, every MDL user will be downloading and
initializing the ClassList prototype just-in-case.  This is not true of
Strings.  It isn't just the cost of instantiation.  There are download and
class initialization costs.  Array operations are not cheap in Flash, not
sure about JS.

There may be other space-delimited lists in world and having a generic
top-level function "addToSpaceDelimitedList" and
"removeFromSpaceDelimitedList" would be opt-in by the users who choose to
manipulate their classNames with these helper functions.  It does not make
sense to me to bake use of these functions into MDL.  The only portion of
the final classname that needs manipulation like this is the className
property itself, not the attribute pieces or typenames.  Also, with
separate will named utility functions, folks could use these functions if
they run into other space delimited lists.

My 2 cents,
-Alex

On 3/2/18, 1:36 AM, "Harbs"  wrote:

>I do agree that this is pretty low on the list of priorities. I did not
>have a head to work on anything “serious” and the class lists was a nice
>distraction for me. I’m certainly fine with however Piotr handles this. I
>would like to point out a few things:
>
>1. Object instantiation is pretty cheap in JS. A CSSClassList object is
>no heavier than an empty String. 8 empty strings use more memory than a
>single CSSClassList.
>2. Array.join() is about the same computational-wise as string
>concatenation.
>3. The “list” is not being added anywhere the empty strings would not be
>added, so it’s no less PAYG than strings.
>4. An instantiated class such as this would fit better in case we need to
>play with class lists in beads because the CSSClassList object could be
>passed around and modified by different classes without exposing private
>variables and/or strands and beads needing to know about each other. I
>don’t think static utility classes are any less PAYG in this case.
>
>Thanks,
>Harbs
>
>> On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki 
>>wrote:
>> 
>> Hi Harbs,
>> 
>> As much as I like Array approach I took Alex's words more serious that
>> having an Array in the game here could be more heavier than String
>> concatenation. It's earlier in the discussion.
>> 
>> Piotr
>> 
>> 
>> 2018-03-02 3:26 GMT+01:00 Alex Harui :
>> 
>>> Very nice, but IMO, this is over-engineering.  We are talking about a
>>> space-delimited list where some portion of it is considered "fixed"
>>> another portion is user-settable and another portion comes from other
>>> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
>>> especially if they are opt-in and just used to manage the user-settable
>>> portion.  Think of it this way:  Every MDL app needs to carry around
>>> ClassList even if they never change the classname.  I don't care too
>>>much
>>> since it is in MDL and not in the core, so keep it if you want to, but
>>>I
>>> can think of lots of other tasks we should be working on than creating
>>> cool classes to manage a list of strings.
>>> 
>>> My 2 cents,
>>> -Alex
>>> 
>>> On 3/1/18, 3:51 PM, "Harbs"  wrote:
>>> 
 What do you think of the CSSClassList class I just committed?
 
 I *think* that makes the pattern more recognizable and probably is
less
 heavy if more than one class can be used.
 
 Harbs
 
> On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki
>
> wrote:
> 
> Harbs, Alex,
> 
> I just pushed implementation of computeFinalClassNames to
> branch feature/type_names_class_name_issue124. You can review
> implementation in this commit [1] and example of usage in Card and
> Button.
> 
> I have tested with Harbs example [3] and with Card by changing
>orders.
> It's
> working.
> 
> [1]
> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fbit.ly%2F
> 
>2HTHaFQ=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57f
>cf
>>> 6
> c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>>> 7C636555451956879397
> =5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
> [2]
> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fbit.ly%2F
> 
>2oJgKOf=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57f
>cf
>>> 6
> c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>>> 7C636555451956879397
> =8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
> [3]
> https://na01.safelinks.protection.outlook.com/?url=
>>> http%3A%2F%2Fbit.ly%2F
> 
>2F734nx=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57f
>cf
>>> 6
> c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>>> 7C636555451956879397
> =9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
> 
> Waiting for your review.
> 
> 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Harbs,

Thanks for such a good explanation. I think I will go with your class.



2018-03-02 10:36 GMT+01:00 Harbs :

> I do agree that this is pretty low on the list of priorities. I did not
> have a head to work on anything “serious” and the class lists was a nice
> distraction for me. I’m certainly fine with however Piotr handles this. I
> would like to point out a few things:
>
> 1. Object instantiation is pretty cheap in JS. A CSSClassList object is no
> heavier than an empty String. 8 empty strings use more memory than a single
> CSSClassList.
> 2. Array.join() is about the same computational-wise as string
> concatenation.
> 3. The “list” is not being added anywhere the empty strings would not be
> added, so it’s no less PAYG than strings.
> 4. An instantiated class such as this would fit better in case we need to
> play with class lists in beads because the CSSClassList object could be
> passed around and modified by different classes without exposing private
> variables and/or strands and beads needing to know about each other. I
> don’t think static utility classes are any less PAYG in this case.
>
> Thanks,
> Harbs
>
> > On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki 
> wrote:
> >
> > Hi Harbs,
> >
> > As much as I like Array approach I took Alex's words more serious that
> > having an Array in the game here could be more heavier than String
> > concatenation. It's earlier in the discussion.
> >
> > Piotr
> >
> >
> > 2018-03-02 3:26 GMT+01:00 Alex Harui :
> >
> >> Very nice, but IMO, this is over-engineering.  We are talking about a
> >> space-delimited list where some portion of it is considered "fixed"
> >> another portion is user-settable and another portion comes from other
> >> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
> >> especially if they are opt-in and just used to manage the user-settable
> >> portion.  Think of it this way:  Every MDL app needs to carry around
> >> ClassList even if they never change the classname.  I don't care too
> much
> >> since it is in MDL and not in the core, so keep it if you want to, but I
> >> can think of lots of other tasks we should be working on than creating
> >> cool classes to manage a list of strings.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 3/1/18, 3:51 PM, "Harbs"  wrote:
> >>
> >>> What do you think of the CSSClassList class I just committed?
> >>>
> >>> I *think* that makes the pattern more recognizable and probably is less
> >>> heavy if more than one class can be used.
> >>>
> >>> Harbs
> >>>
>  On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
>  wrote:
> 
>  Harbs, Alex,
> 
>  I just pushed implementation of computeFinalClassNames to
>  branch feature/type_names_class_name_issue124. You can review
>  implementation in this commit [1] and example of usage in Card and
>  Button.
> 
>  I have tested with Harbs example [3] and with Card by changing orders.
>  It's
>  working.
> 
>  [1]
>  https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fbit.ly%2F
>  2HTHaFQ=02%7C01%7Caharui%40adobe.com%
> 7C9ba2ae2d1a6e4fdc774508d57fcf
> >> 6
>  c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
> >> 7C636555451956879397
>  =5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
>  [2]
>  https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fbit.ly%2F
>  2oJgKOf=02%7C01%7Caharui%40adobe.com%
> 7C9ba2ae2d1a6e4fdc774508d57fcf
> >> 6
>  c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
> >> 7C636555451956879397
>  =8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
>  [3]
>  https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fbit.ly%2F
>  2F734nx=02%7C01%7Caharui%40adobe.com%
> 7C9ba2ae2d1a6e4fdc774508d57fcf
> >> 6
>  c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
> >> 7C636555451956879397
>  =9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
> 
>  Waiting for your review.
> 
>  Thanks,
>  Piotr
> 
> 
>  2018-02-28 23:31 GMT+01:00 Piotr Zarzycki  >:
> 
> > Let me play with implementation of that function. It seems to me that
> > will
> > be much cleaner than current solution.
> >
> > If user actually wanted to do anythin with className - let the
> > overriding
> > speaks.
> >
> >
> >
> > On Wed, Feb 28, 2018, 21:51 Alex Harui 
> > wrote:
> >
> >> On 2/28/18, 12:27 PM, "Harbs"  wrote:
> >>
> >>> OK. I think that will work for DML components, but what if there’s
> a
> >>> bead
> >>> which needs to add class names? What would be the “right” way to do
> >>> that?
> >>> A bead cannot override the function on the strand.
> >>
> >> Do we have beads that 

Re: TypeNames vs ClassName

[Harbs]

I do agree that this is pretty low on the list of priorities. I did not have a 
head to work on anything “serious” and the class lists was a nice distraction 
for me. I’m certainly fine with however Piotr handles this. I would like to 
point out a few things:

1. Object instantiation is pretty cheap in JS. A CSSClassList object is no 
heavier than an empty String. 8 empty strings use more memory than a single 
CSSClassList.
2. Array.join() is about the same computational-wise as string concatenation.
3. The “list” is not being added anywhere the empty strings would not be added, 
so it’s no less PAYG than strings.
4. An instantiated class such as this would fit better in case we need to play 
with class lists in beads because the CSSClassList object could be passed 
around and modified by different classes without exposing private variables 
and/or strands and beads needing to know about each other. I don’t think static 
utility classes are any less PAYG in this case.

Thanks,
Harbs

> On Mar 2, 2018, at 7:42 AM, Piotr Zarzycki  wrote:
> 
> Hi Harbs,
> 
> As much as I like Array approach I took Alex's words more serious that
> having an Array in the game here could be more heavier than String
> concatenation. It's earlier in the discussion.
> 
> Piotr
> 
> 
> 2018-03-02 3:26 GMT+01:00 Alex Harui :
> 
>> Very nice, but IMO, this is over-engineering.  We are talking about a
>> space-delimited list where some portion of it is considered "fixed"
>> another portion is user-settable and another portion comes from other
>> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
>> especially if they are opt-in and just used to manage the user-settable
>> portion.  Think of it this way:  Every MDL app needs to carry around
>> ClassList even if they never change the classname.  I don't care too much
>> since it is in MDL and not in the core, so keep it if you want to, but I
>> can think of lots of other tasks we should be working on than creating
>> cool classes to manage a list of strings.
>> 
>> My 2 cents,
>> -Alex
>> 
>> On 3/1/18, 3:51 PM, "Harbs"  wrote:
>> 
>>> What do you think of the CSSClassList class I just committed?
>>> 
>>> I *think* that makes the pattern more recognizable and probably is less
>>> heavy if more than one class can be used.
>>> 
>>> Harbs
>>> 
 On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki 
 wrote:
 
 Harbs, Alex,
 
 I just pushed implementation of computeFinalClassNames to
 branch feature/type_names_class_name_issue124. You can review
 implementation in this commit [1] and example of usage in Card and
 Button.
 
 I have tested with Harbs example [3] and with Card by changing orders.
 It's
 working.
 
 [1]
 https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fbit.ly%2F
 2HTHaFQ=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf
>> 6
 c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>> 7C636555451956879397
 =5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
 [2]
 https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fbit.ly%2F
 2oJgKOf=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf
>> 6
 c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>> 7C636555451956879397
 =8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
 [3]
 https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fbit.ly%2F
 2F734nx=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf
>> 6
 c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%
>> 7C636555451956879397
 =9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
 
 Waiting for your review.
 
 Thanks,
 Piotr
 
 
 2018-02-28 23:31 GMT+01:00 Piotr Zarzycki :
 
> Let me play with implementation of that function. It seems to me that
> will
> be much cleaner than current solution.
> 
> If user actually wanted to do anythin with className - let the
> overriding
> speaks.
> 
> 
> 
> On Wed, Feb 28, 2018, 21:51 Alex Harui 
> wrote:
> 
>> On 2/28/18, 12:27 PM, "Harbs"  wrote:
>> 
>>> OK. I think that will work for DML components, but what if there’s a
>>> bead
>>> which needs to add class names? What would be the “right” way to do
>>> that?
>>> A bead cannot override the function on the strand.
>> 
>> Do we have beads that manipulate className?
>> 
>> IMO, the principle behind how to handle that is knowing whether you
>> are
>> sharing something or not.  There may not be one right way to handle
>> it,
>> but if I had to handle it, I would have the bead set something in the
>> model or presentation model of the component.  And the component would
>> override 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Maybe let's do this in that way. I could stay with your solution where I'm
using that array class, but we could move it to the MDL module. Since this
problem is specific right now to that. Maybe the computation won't be so
large like it is in case of MDL, where you have 5-6 properties and you need
to compute them.

Just wanted to move forward cause it's again quite a bit of work going
through all components.

Thoughts ?

2018-03-02 6:42 GMT+01:00 Piotr Zarzycki :

> Hi Harbs,
>
> As much as I like Array approach I took Alex's words more serious that
> having an Array in the game here could be more heavier than String
> concatenation. It's earlier in the discussion.
>
> Piotr
>
>
> 2018-03-02 3:26 GMT+01:00 Alex Harui :
>
>> Very nice, but IMO, this is over-engineering.  We are talking about a
>> space-delimited list where some portion of it is considered "fixed"
>> another portion is user-settable and another portion comes from other
>> attributes.  Some generic StringUtils or ListUtils might be more PAYG,
>> especially if they are opt-in and just used to manage the user-settable
>> portion.  Think of it this way:  Every MDL app needs to carry around
>> ClassList even if they never change the classname.  I don't care too much
>> since it is in MDL and not in the core, so keep it if you want to, but I
>> can think of lots of other tasks we should be working on than creating
>> cool classes to manage a list of strings.
>>
>> My 2 cents,
>> -Alex
>>
>> On 3/1/18, 3:51 PM, "Harbs"  wrote:
>>
>> >What do you think of the CSSClassList class I just committed?
>> >
>> >I *think* that makes the pattern more recognizable and probably is less
>> >heavy if more than one class can be used.
>> >
>> >Harbs
>> >
>> >> On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki > >
>> >>wrote:
>> >>
>> >> Harbs, Alex,
>> >>
>> >> I just pushed implementation of computeFinalClassNames to
>> >> branch feature/type_names_class_name_issue124. You can review
>> >> implementation in this commit [1] and example of usage in Card and
>> >>Button.
>> >>
>> >> I have tested with Harbs example [3] and with Card by changing orders.
>> >>It's
>> >> working.
>> >>
>> >> [1]
>> >>https://na01.safelinks.protection.outlook.com/?url=http%
>> 3A%2F%2Fbit.ly%2F
>> >>2HTHaFQ=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4f
>> dc774508d57fcf6
>> >>c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636555451
>> 956879397
>> >>=5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
>> >> [2]
>> >>https://na01.safelinks.protection.outlook.com/?url=http%
>> 3A%2F%2Fbit.ly%2F
>> >>2oJgKOf=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4f
>> dc774508d57fcf6
>> >>c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636555451
>> 956879397
>> >>=8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
>> >> [3]
>> >>https://na01.safelinks.protection.outlook.com/?url=http%
>> 3A%2F%2Fbit.ly%2F
>> >>2F734nx=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4f
>> dc774508d57fcf6
>> >>c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636555451
>> 956879397
>> >>=9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
>> >>
>> >> Waiting for your review.
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >>
>> >> 2018-02-28 23:31 GMT+01:00 Piotr Zarzycki :
>> >>
>> >>> Let me play with implementation of that function. It seems to me that
>> >>>will
>> >>> be much cleaner than current solution.
>> >>>
>> >>> If user actually wanted to do anythin with className - let the
>> >>>overriding
>> >>> speaks.
>> >>>
>> >>>
>> >>>
>> >>> On Wed, Feb 28, 2018, 21:51 Alex Harui 
>> >>>wrote:
>> >>>
>>  On 2/28/18, 12:27 PM, "Harbs"  wrote:
>> 
>> > OK. I think that will work for DML components, but what if there’s a
>> >bead
>> > which needs to add class names? What would be the “right” way to do
>> >that?
>> > A bead cannot override the function on the strand.
>> 
>>  Do we have beads that manipulate className?
>> 
>>  IMO, the principle behind how to handle that is knowing whether you
>> are
>>  sharing something or not.  There may not be one right way to handle
>> it,
>>  but if I had to handle it, I would have the bead set something in the
>>  model or presentation model of the component.  And the component
>> would
>>  override computeFinalClassNames to take that into account.
>> 
>> 
>>  Although having just written that, maybe this computeFinalClassNames
>>  should be in the view instead of on the base class so it is
>> replaceable
>>  instead of overridable.
>> 
>>  Thoughts?
>>  -Alex
>> >
>> >> On Feb 28, 2018, at 10:17 PM, Alex Harui > >
>> >> wrote:
>> >>
>> >> I think you are missing that the element.className is set to
>> >> computeFinalClassNames.  So the user is welcome to manipulate the

Re: TypeNames vs ClassName

[Alex Harui]

Very nice, but IMO, this is over-engineering.  We are talking about a
space-delimited list where some portion of it is considered "fixed"
another portion is user-settable and another portion comes from other
attributes.  Some generic StringUtils or ListUtils might be more PAYG,
especially if they are opt-in and just used to manage the user-settable
portion.  Think of it this way:  Every MDL app needs to carry around
ClassList even if they never change the classname.  I don't care too much
since it is in MDL and not in the core, so keep it if you want to, but I
can think of lots of other tasks we should be working on than creating
cool classes to manage a list of strings.

My 2 cents,
-Alex

On 3/1/18, 3:51 PM, "Harbs"  wrote:

>What do you think of the CSSClassList class I just committed?
>
>I *think* that makes the pattern more recognizable and probably is less
>heavy if more than one class can be used.
>
>Harbs
>
>> On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki 
>>wrote:
>> 
>> Harbs, Alex,
>> 
>> I just pushed implementation of computeFinalClassNames to
>> branch feature/type_names_class_name_issue124. You can review
>> implementation in this commit [1] and example of usage in Card and
>>Button.
>> 
>> I have tested with Harbs example [3] and with Card by changing orders.
>>It's
>> working.
>> 
>> [1] 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbit.ly%2F
>>2HTHaFQ=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf6
>>c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636555451956879397
>>=5EDairk%2BdGWuPE20vIR8jGFcRSflwqQIcw48oCPydYU%3D=0
>> [2] 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbit.ly%2F
>>2oJgKOf=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf6
>>c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636555451956879397
>>=8hIfKGYzhaInYfubnf3lUKbYZWRUANzEcWHj3Pkn3Ho%3D=0
>> [3] 
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbit.ly%2F
>>2F734nx=02%7C01%7Caharui%40adobe.com%7C9ba2ae2d1a6e4fdc774508d57fcf6
>>c56%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636555451956879397
>>=9I9q1KjL5VNE5CJSAVTtwN9hhR2rco4ovIzJjQ74%2FeY%3D=0
>> 
>> Waiting for your review.
>> 
>> Thanks,
>> Piotr
>> 
>> 
>> 2018-02-28 23:31 GMT+01:00 Piotr Zarzycki :
>> 
>>> Let me play with implementation of that function. It seems to me that
>>>will
>>> be much cleaner than current solution.
>>> 
>>> If user actually wanted to do anythin with className - let the
>>>overriding
>>> speaks.
>>> 
>>> 
>>> 
>>> On Wed, Feb 28, 2018, 21:51 Alex Harui 
>>>wrote:
>>> 
 On 2/28/18, 12:27 PM, "Harbs"  wrote:
 
> OK. I think that will work for DML components, but what if there’s a
>bead
> which needs to add class names? What would be the “right” way to do
>that?
> A bead cannot override the function on the strand.
 
 Do we have beads that manipulate className?
 
 IMO, the principle behind how to handle that is knowing whether you
are
 sharing something or not.  There may not be one right way to handle
it,
 but if I had to handle it, I would have the bead set something in the
 model or presentation model of the component.  And the component would
 override computeFinalClassNames to take that into account.
 
 
 Although having just written that, maybe this computeFinalClassNames
 should be in the view instead of on the base class so it is
replaceable
 instead of overridable.
 
 Thoughts?
 -Alex
> 
>> On Feb 28, 2018, at 10:17 PM, Alex Harui 
>> wrote:
>> 
>> I think you are missing that the element.className is set to
>> computeFinalClassNames.  So the user is welcome to manipulate the
>> UIBase.className however they see fit.  They can assign it a whole
>>new
>> space-delimited list if they want.  But what gets set on
>> element.className
>> is computed from typeNames and className by default, and MDL would
>> override it to factor in fab, raised, colored into the computing of
>>the
>> final classnames.
>> 
>> I would prefer that we don't make requirements on users as to what
>>they
>> can or can't do with the className property, like requiring them to
>>use
>> addClassName/removeClassNames.  MXML and States might set className,
 as
>> could any other AS logic.  I think folks may even be used to setting
>> className in JavaScript.  So letting UIBase.className be the
>>"variable"
>> part and having computeFinalClassNames be the way the "fixed" part
>>is
>> handled makes sense to me.
>> 
>> Of course, I could be wrong...
>> -Alex
>> 
>> On 2/28/18, 12:03 PM, "Harbs"  wrote:
>> 
>>> The problem which sparked this whole issue is like this:
>>> 
>>> 

Re: TypeNames vs ClassName

[Harbs]

What do you think of the CSSClassList class I just committed?

I *think* that makes the pattern more recognizable and probably is less heavy 
if more than one class can be used.

Harbs

> On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki  wrote:
> 
> Harbs, Alex,
> 
> I just pushed implementation of computeFinalClassNames to
> branch feature/type_names_class_name_issue124. You can review
> implementation in this commit [1] and example of usage in Card and Button.
> 
> I have tested with Harbs example [3] and with Card by changing orders. It's
> working.
> 
> [1] http://bit.ly/2HTHaFQ
> [2] http://bit.ly/2oJgKOf
> [3] http://bit.ly/2F734nx
> 
> Waiting for your review.
> 
> Thanks,
> Piotr
> 
> 
> 2018-02-28 23:31 GMT+01:00 Piotr Zarzycki :
> 
>> Let me play with implementation of that function. It seems to me that will
>> be much cleaner than current solution.
>> 
>> If user actually wanted to do anythin with className - let the overriding
>> speaks.
>> 
>> 
>> 
>> On Wed, Feb 28, 2018, 21:51 Alex Harui  wrote:
>> 
>>> On 2/28/18, 12:27 PM, "Harbs"  wrote:
>>> 
 OK. I think that will work for DML components, but what if there’s a bead
 which needs to add class names? What would be the “right” way to do that?
 A bead cannot override the function on the strand.
>>> 
>>> Do we have beads that manipulate className?
>>> 
>>> IMO, the principle behind how to handle that is knowing whether you are
>>> sharing something or not.  There may not be one right way to handle it,
>>> but if I had to handle it, I would have the bead set something in the
>>> model or presentation model of the component.  And the component would
>>> override computeFinalClassNames to take that into account.
>>> 
>>> 
>>> Although having just written that, maybe this computeFinalClassNames
>>> should be in the view instead of on the base class so it is replaceable
>>> instead of overridable.
>>> 
>>> Thoughts?
>>> -Alex
 
> On Feb 28, 2018, at 10:17 PM, Alex Harui 
> wrote:
> 
> I think you are missing that the element.className is set to
> computeFinalClassNames.  So the user is welcome to manipulate the
> UIBase.className however they see fit.  They can assign it a whole new
> space-delimited list if they want.  But what gets set on
> element.className
> is computed from typeNames and className by default, and MDL would
> override it to factor in fab, raised, colored into the computing of the
> final classnames.
> 
> I would prefer that we don't make requirements on users as to what they
> can or can't do with the className property, like requiring them to use
> addClassName/removeClassNames.  MXML and States might set className,
>>> as
> could any other AS logic.  I think folks may even be used to setting
> className in JavaScript.  So letting UIBase.className be the "variable"
> part and having computeFinalClassNames be the way the "fixed" part is
> handled makes sense to me.
> 
> Of course, I could be wrong...
> -Alex
> 
> On 2/28/18, 12:03 PM, "Harbs"  wrote:
> 
>> The problem which sparked this whole issue is like this:
>> 
>> 1. We have some components (i.e. in MDL) which add “pieces” to the
>> class
>> names (such as “fab”, “raised”, “colored”, etc.
>> 2. The client might subsequently set the className to something else.
>> 3. When the component sets the “pieces” first and the client sets the
>> className later, the client will overwrite these “pieces” which were
>> added by the component.
>> 
>> My suggestion to have addClassName() and removeClassName() was to have
>> a
>> “safe” way to add class names which would get computed together with
>> the
>> className when the className is replaced.
>> 
>> The way you have it seems to just be modifying the existing className
>> property. If that’s overwritten by a client, the logic falls apart.
>> 
>> It feels like only having typeNames which are set inside the component
>> and className which is set outside the component is not really enough.
>> (Unless I’m missing something.)
>> 
>> Harbs
>> 
>>> On Feb 28, 2018, at 9:31 PM, Alex Harui 
>>> wrote:
>>> 
>>> On 2/28/18, 10:44 AM, "Harbs"  wrote:
>>> 
 If it’s not public, I don’t see how a utility method could call it
 though.
>>> 
>>> I didn't think the utility methods like addClassName/removeClassName
>>> would
>>> need to alter computeFinalClassNames().
>>> 
>>> AIUI, for most UIBase subclasses, the final element.className is a
>>> mix
>>> of
>>> the className property and the typeNames.  The typenames are thought
>>> to
>>> be
>>> "fixed" and the 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Harbs, Alex,

I just pushed implementation of computeFinalClassNames to
branch feature/type_names_class_name_issue124. You can review
implementation in this commit [1] and example of usage in Card and Button.

I have tested with Harbs example [3] and with Card by changing orders. It's
working.

[1] http://bit.ly/2HTHaFQ
[2] http://bit.ly/2oJgKOf
[3] http://bit.ly/2F734nx

Waiting for your review.

Thanks,
Piotr


2018-02-28 23:31 GMT+01:00 Piotr Zarzycki :

> Let me play with implementation of that function. It seems to me that will
> be much cleaner than current solution.
>
> If user actually wanted to do anythin with className - let the overriding
> speaks.
>
>
>
> On Wed, Feb 28, 2018, 21:51 Alex Harui  wrote:
>
>> On 2/28/18, 12:27 PM, "Harbs"  wrote:
>>
>> >OK. I think that will work for DML components, but what if there’s a bead
>> >which needs to add class names? What would be the “right” way to do that?
>> >A bead cannot override the function on the strand.
>>
>> Do we have beads that manipulate className?
>>
>> IMO, the principle behind how to handle that is knowing whether you are
>> sharing something or not.  There may not be one right way to handle it,
>> but if I had to handle it, I would have the bead set something in the
>> model or presentation model of the component.  And the component would
>> override computeFinalClassNames to take that into account.
>>
>>
>> Although having just written that, maybe this computeFinalClassNames
>> should be in the view instead of on the base class so it is replaceable
>> instead of overridable.
>>
>> Thoughts?
>> -Alex
>> >
>> >> On Feb 28, 2018, at 10:17 PM, Alex Harui 
>> >>wrote:
>> >>
>> >> I think you are missing that the element.className is set to
>> >> computeFinalClassNames.  So the user is welcome to manipulate the
>> >> UIBase.className however they see fit.  They can assign it a whole new
>> >> space-delimited list if they want.  But what gets set on
>> >>element.className
>> >> is computed from typeNames and className by default, and MDL would
>> >> override it to factor in fab, raised, colored into the computing of the
>> >> final classnames.
>> >>
>> >> I would prefer that we don't make requirements on users as to what they
>> >> can or can't do with the className property, like requiring them to use
>> >> addClassName/removeClassNames.  MXML and States might set className,
>> as
>> >> could any other AS logic.  I think folks may even be used to setting
>> >> className in JavaScript.  So letting UIBase.className be the "variable"
>> >> part and having computeFinalClassNames be the way the "fixed" part is
>> >> handled makes sense to me.
>> >>
>> >> Of course, I could be wrong...
>> >> -Alex
>> >>
>> >> On 2/28/18, 12:03 PM, "Harbs"  wrote:
>> >>
>> >>> The problem which sparked this whole issue is like this:
>> >>>
>> >>> 1. We have some components (i.e. in MDL) which add “pieces” to the
>> >>>class
>> >>> names (such as “fab”, “raised”, “colored”, etc.
>> >>> 2. The client might subsequently set the className to something else.
>> >>> 3. When the component sets the “pieces” first and the client sets the
>> >>> className later, the client will overwrite these “pieces” which were
>> >>> added by the component.
>> >>>
>> >>> My suggestion to have addClassName() and removeClassName() was to have
>> >>>a
>> >>> “safe” way to add class names which would get computed together with
>> >>>the
>> >>> className when the className is replaced.
>> >>>
>> >>> The way you have it seems to just be modifying the existing className
>> >>> property. If that’s overwritten by a client, the logic falls apart.
>> >>>
>> >>> It feels like only having typeNames which are set inside the component
>> >>> and className which is set outside the component is not really enough.
>> >>> (Unless I’m missing something.)
>> >>>
>> >>> Harbs
>> >>>
>>  On Feb 28, 2018, at 9:31 PM, Alex Harui 
>>  wrote:
>> 
>>  On 2/28/18, 10:44 AM, "Harbs"  wrote:
>> 
>> > If it’s not public, I don’t see how a utility method could call it
>> > though.
>> 
>>  I didn't think the utility methods like addClassName/removeClassName
>>  would
>>  need to alter computeFinalClassNames().
>> 
>>  AIUI, for most UIBase subclasses, the final element.className is a
>> mix
>>  of
>>  the className property and the typeNames.  The typenames are thought
>> to
>>  be
>>  "fixed" and the space-delimited list of names in className are the
>> ones
>>  the user wants to manipulate in their code.  So, I would expect them
>> to
>>  write:
>> 
>>  org.apache.royale.utils.addClassName(myComponent, "pinkStyles");
>> 
>> 
>>  addClassName should just do something like:
>> 
>>  myComponent.className += value;
>> 
>>  That 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Let me play with implementation of that function. It seems to me that will
be much cleaner than current solution.

If user actually wanted to do anythin with className - let the overriding
speaks.



On Wed, Feb 28, 2018, 21:51 Alex Harui  wrote:

> On 2/28/18, 12:27 PM, "Harbs"  wrote:
>
> >OK. I think that will work for DML components, but what if there’s a bead
> >which needs to add class names? What would be the “right” way to do that?
> >A bead cannot override the function on the strand.
>
> Do we have beads that manipulate className?
>
> IMO, the principle behind how to handle that is knowing whether you are
> sharing something or not.  There may not be one right way to handle it,
> but if I had to handle it, I would have the bead set something in the
> model or presentation model of the component.  And the component would
> override computeFinalClassNames to take that into account.
>
>
> Although having just written that, maybe this computeFinalClassNames
> should be in the view instead of on the base class so it is replaceable
> instead of overridable.
>
> Thoughts?
> -Alex
> >
> >> On Feb 28, 2018, at 10:17 PM, Alex Harui 
> >>wrote:
> >>
> >> I think you are missing that the element.className is set to
> >> computeFinalClassNames.  So the user is welcome to manipulate the
> >> UIBase.className however they see fit.  They can assign it a whole new
> >> space-delimited list if they want.  But what gets set on
> >>element.className
> >> is computed from typeNames and className by default, and MDL would
> >> override it to factor in fab, raised, colored into the computing of the
> >> final classnames.
> >>
> >> I would prefer that we don't make requirements on users as to what they
> >> can or can't do with the className property, like requiring them to use
> >> addClassName/removeClassNames.  MXML and States might set className, as
> >> could any other AS logic.  I think folks may even be used to setting
> >> className in JavaScript.  So letting UIBase.className be the "variable"
> >> part and having computeFinalClassNames be the way the "fixed" part is
> >> handled makes sense to me.
> >>
> >> Of course, I could be wrong...
> >> -Alex
> >>
> >> On 2/28/18, 12:03 PM, "Harbs"  wrote:
> >>
> >>> The problem which sparked this whole issue is like this:
> >>>
> >>> 1. We have some components (i.e. in MDL) which add “pieces” to the
> >>>class
> >>> names (such as “fab”, “raised”, “colored”, etc.
> >>> 2. The client might subsequently set the className to something else.
> >>> 3. When the component sets the “pieces” first and the client sets the
> >>> className later, the client will overwrite these “pieces” which were
> >>> added by the component.
> >>>
> >>> My suggestion to have addClassName() and removeClassName() was to have
> >>>a
> >>> “safe” way to add class names which would get computed together with
> >>>the
> >>> className when the className is replaced.
> >>>
> >>> The way you have it seems to just be modifying the existing className
> >>> property. If that’s overwritten by a client, the logic falls apart.
> >>>
> >>> It feels like only having typeNames which are set inside the component
> >>> and className which is set outside the component is not really enough.
> >>> (Unless I’m missing something.)
> >>>
> >>> Harbs
> >>>
>  On Feb 28, 2018, at 9:31 PM, Alex Harui 
>  wrote:
> 
>  On 2/28/18, 10:44 AM, "Harbs"  wrote:
> 
> > If it’s not public, I don’t see how a utility method could call it
> > though.
> 
>  I didn't think the utility methods like addClassName/removeClassName
>  would
>  need to alter computeFinalClassNames().
> 
>  AIUI, for most UIBase subclasses, the final element.className is a mix
>  of
>  the className property and the typeNames.  The typenames are thought
> to
>  be
>  "fixed" and the space-delimited list of names in className are the
> ones
>  the user wants to manipulate in their code.  So, I would expect them
> to
>  write:
> 
>  org.apache.royale.utils.addClassName(myComponent, "pinkStyles");
> 
> 
>  addClassName should just do something like:
> 
>  myComponent.className += value;
> 
>  That will call the className setter that will run:
> 
>  element.className = computeFinalClassNames();
> 
>  If you call
> 
>  org.apache.royale.utils.removeClassName(myComponent, "pinkStyles");
> 
>  removeClassName should just do something like:
> 
>  Var s:String = myComponent.className;
>  Var c:int = s.indexOf(nameToRemove + " ");
>  If (c != -1)
> s = s.substr(0, c) + s.substr(c + nameToRemove.length + 1);
>  Else
>  {
> c= s.indexOf(" " + nameToRemove);
> if (c != -1)
>   s = s.substr(0, c);  // remove last item
>  

Re: TypeNames vs ClassName

[Harbs]

The problem which sparked this whole issue is like this:

1. We have some components (i.e. in MDL) which add “pieces” to the class names 
(such as “fab”, “raised”, “colored”, etc.
2. The client might subsequently set the className to something else.
3. When the component sets the “pieces” first and the client sets the className 
later, the client will overwrite these “pieces” which were added by the 
component.

My suggestion to have addClassName() and removeClassName() was to have a “safe” 
way to add class names which would get computed together with the className 
when the className is replaced.

The way you have it seems to just be modifying the existing className property. 
If that’s overwritten by a client, the logic falls apart.

It feels like only having typeNames which are set inside the component and 
className which is set outside the component is not really enough. (Unless I’m 
missing something.)

Harbs

> On Feb 28, 2018, at 9:31 PM, Alex Harui  wrote:
> 
> On 2/28/18, 10:44 AM, "Harbs"  wrote:
> 
>> If it’s not public, I don’t see how a utility method could call it though.
> 
> I didn't think the utility methods like addClassName/removeClassName would
> need to alter computeFinalClassNames().
> 
> AIUI, for most UIBase subclasses, the final element.className is a mix of
> the className property and the typeNames.  The typenames are thought to be
> "fixed" and the space-delimited list of names in className are the ones
> the user wants to manipulate in their code.  So, I would expect them to
> write:
> 
>  org.apache.royale.utils.addClassName(myComponent, "pinkStyles");
> 
> 
> addClassName should just do something like:
> 
>  myComponent.className += value;
> 
> That will call the className setter that will run:
> 
>  element.className = computeFinalClassNames();
> 
> If you call
> 
>  org.apache.royale.utils.removeClassName(myComponent, "pinkStyles");
> 
> removeClassName should just do something like:
> 
>  Var s:String = myComponent.className;
>  Var c:int = s.indexOf(nameToRemove + " ");
>  If (c != -1)
> s = s.substr(0, c) + s.substr(c + nameToRemove.length + 1);
>  Else
>  {
> c= s.indexOf(" " + nameToRemove);
> if (c != -1)
>   s = s.substr(0, c);  // remove last item
>  }
>  myComponent.className = s;
> 
> 
> 
> It seems like it should be that simple.  What am I missing?
> 
> -Alex
> 
> 
>> 
>>> On Feb 28, 2018, at 8:21 PM, Alex Harui 
>>> wrote:
>>> 
>>> 
>>> 
>>> On 2/28/18, 9:50 AM, "Piotr Zarzycki" >> > wrote:
>>> 
 Ok Understand, but do you agree that  computeFinalClassNames - is
 something
 which is in the UIBase ?
>>> 
>>> Yes, and probably protected instead of public.  The one in UIBase just
>>> appends typenames to className.  It gets overridden in MDL where needed
>>> for shadow and other attributes.
>>> 
>>> My 2 cents,
>>> -Alex
 
 2018-02-28 18:47 GMT+01:00 Alex Harui :
 
> I think that in the shadow setter, it would change _shadow and call
> setClassName(computeFinalClassNames());
> 
> On 2/28/18, 9:33 AM, "Piotr Zarzycki" 
> wrote:
> 
>> Alex,
>> 
>> So we are getting back to the idea where you proposed to have
>> function
>> which computes everything.
>> 
>> override public function computeFinalClassNames():String
>> {
>> return super.computeFinalClassNames() + " " + _shadow;
>> }
>> 
>> Where does that function should be placed ? Does that function should
> be
>> called in addedToParent plus whenever someone change _shadow ? -
>> 
>> Because I really don't know how to handle scenario where you have
>> some
>> property isActive = true/false and I need to add/remove class. - In
>> the
>> first launch I use  computeFinalClassNames, but how to handle
>> changing
> ?
>> 
>> Thanks, Piotr
>> 
>> 
>> 2018-02-28 18:26 GMT+01:00 Alex Harui :
>> 
>>> Hi Piotr,
>>> 
>>> I think am I not communicating the principles effectively.
>>> 
>>> First, IMO, addClassName and removeClassName should not be in
>>> UIBase.
>>> Lots of apps can be written without needing these methods.  I think
> they
>>> can be written as utility functions.
>>> 
>>> Second, the computation of the final element.className should
> represent
>>> the state of the component, so I don't get why you need an
>>> _internalClassName or should ever set it to "".  The computation for
> a
>>> component with a shadow would be to check the shadow property and if
> it
>>> is
>>> true, add a className for the shadow to the list.  Then I think you
>>> wouldn't have the problem you showed in the animated GIF.  When the
>>> classname property is set from the 

Re: TypeNames vs ClassName

[Alex Harui]

On 2/28/18, 10:44 AM, "Harbs"  wrote:

>If it’s not public, I don’t see how a utility method could call it though.

I didn't think the utility methods like addClassName/removeClassName would
need to alter computeFinalClassNames().

AIUI, for most UIBase subclasses, the final element.className is a mix of
the className property and the typeNames.  The typenames are thought to be
"fixed" and the space-delimited list of names in className are the ones
the user wants to manipulate in their code.  So, I would expect them to
write:

  org.apache.royale.utils.addClassName(myComponent, "pinkStyles");


addClassName should just do something like:

  myComponent.className += value;

That will call the className setter that will run:

  element.className = computeFinalClassNames();

If you call

  org.apache.royale.utils.removeClassName(myComponent, "pinkStyles");

removeClassName should just do something like:

  Var s:String = myComponent.className;
  Var c:int = s.indexOf(nameToRemove + " ");
  If (c != -1)
 s = s.substr(0, c) + s.substr(c + nameToRemove.length + 1);
  Else
  {
 c= s.indexOf(" " + nameToRemove);
 if (c != -1)
   s = s.substr(0, c);  // remove last item
  }
  myComponent.className = s;



It seems like it should be that simple.  What am I missing?

-Alex


>
>> On Feb 28, 2018, at 8:21 PM, Alex Harui 
>>wrote:
>> 
>> 
>> 
>> On 2/28/18, 9:50 AM, "Piotr Zarzycki" >> wrote:
>> 
>>> Ok Understand, but do you agree that  computeFinalClassNames - is
>>> something
>>> which is in the UIBase ?
>> 
>> Yes, and probably protected instead of public.  The one in UIBase just
>> appends typenames to className.  It gets overridden in MDL where needed
>> for shadow and other attributes.
>> 
>> My 2 cents,
>> -Alex
>>> 
>>> 2018-02-28 18:47 GMT+01:00 Alex Harui :
>>> 
 I think that in the shadow setter, it would change _shadow and call
 setClassName(computeFinalClassNames());
 
 On 2/28/18, 9:33 AM, "Piotr Zarzycki" 
wrote:
 
> Alex,
> 
> So we are getting back to the idea where you proposed to have
>function
> which computes everything.
> 
> override public function computeFinalClassNames():String
> {
> return super.computeFinalClassNames() + " " + _shadow;
> }
> 
> Where does that function should be placed ? Does that function should
 be
> called in addedToParent plus whenever someone change _shadow ? -
> 
> Because I really don't know how to handle scenario where you have
>some
> property isActive = true/false and I need to add/remove class. - In
>the
> first launch I use  computeFinalClassNames, but how to handle
>changing
 ?
> 
> Thanks, Piotr
> 
> 
> 2018-02-28 18:26 GMT+01:00 Alex Harui :
> 
>> Hi Piotr,
>> 
>> I think am I not communicating the principles effectively.
>> 
>> First, IMO, addClassName and removeClassName should not be in
>>UIBase.
>> Lots of apps can be written without needing these methods.  I think
 they
>> can be written as utility functions.
>> 
>> Second, the computation of the final element.className should
 represent
>> the state of the component, so I don't get why you need an
>> _internalClassName or should ever set it to "".  The computation for
 a
>> component with a shadow would be to check the shadow property and if
 it
>> is
>> true, add a className for the shadow to the list.  Then I think you
>> wouldn't have the problem you showed in the animated GIF.  When the
>> classname property is set from the outside by MXMLDataInterpreter or
>> even
>> user-written code, those classNames are added to the list with the
>> typeNames and the shadow className if shadow is true and then set on
 the
>> element.
>> 
>> Finally, for addClassName and removeClassName, and all other Royale
>> code,
>> we don't want to do much if any parameter checking.  That is also
>> just-in-case code.  The production code should not be passing in
 null or
>> other bad values.  And once you fix that, then the checks that you
 have
>> written do not add value.  I have proposed that there are debug-only
>> code
>> that does parameter checking.  There is a goog.DEBUG flag you can
>>use
>> for
>> that.
>> 
>> HTH,
>> -Alex
>> 
>> On 2/28/18, 12:40 AM, "Piotr Zarzycki" 
>> wrote:
>> 
>>> Hi Alex,
>>> 
>>> Sorry about that. Let me show you code and I recorded GIF with
 problem
>>> debugging.
>>> 
>>> *Code in UIBase which I have implemented:*
>>> addClassName and removeClassName [1].
>>> addedToParent what is happen with internal 

Re: TypeNames vs ClassName

[Harbs]

If it’s not public, I don’t see how a utility method could call it though.

> On Feb 28, 2018, at 8:21 PM, Alex Harui  wrote:
> 
> 
> 
> On 2/28/18, 9:50 AM, "Piotr Zarzycki"  > wrote:
> 
>> Ok Understand, but do you agree that  computeFinalClassNames - is
>> something
>> which is in the UIBase ?
> 
> Yes, and probably protected instead of public.  The one in UIBase just
> appends typenames to className.  It gets overridden in MDL where needed
> for shadow and other attributes.
> 
> My 2 cents,
> -Alex
>> 
>> 2018-02-28 18:47 GMT+01:00 Alex Harui :
>> 
>>> I think that in the shadow setter, it would change _shadow and call
>>> setClassName(computeFinalClassNames());
>>> 
>>> On 2/28/18, 9:33 AM, "Piotr Zarzycki"  wrote:
>>> 
 Alex,
 
 So we are getting back to the idea where you proposed to have function
 which computes everything.
 
 override public function computeFinalClassNames():String
 {
 return super.computeFinalClassNames() + " " + _shadow;
 }
 
 Where does that function should be placed ? Does that function should
>>> be
 called in addedToParent plus whenever someone change _shadow ? -
 
 Because I really don't know how to handle scenario where you have some
 property isActive = true/false and I need to add/remove class. - In the
 first launch I use  computeFinalClassNames, but how to handle changing
>>> ?
 
 Thanks, Piotr
 
 
 2018-02-28 18:26 GMT+01:00 Alex Harui :
 
> Hi Piotr,
> 
> I think am I not communicating the principles effectively.
> 
> First, IMO, addClassName and removeClassName should not be in UIBase.
> Lots of apps can be written without needing these methods.  I think
>>> they
> can be written as utility functions.
> 
> Second, the computation of the final element.className should
>>> represent
> the state of the component, so I don't get why you need an
> _internalClassName or should ever set it to "".  The computation for
>>> a
> component with a shadow would be to check the shadow property and if
>>> it
> is
> true, add a className for the shadow to the list.  Then I think you
> wouldn't have the problem you showed in the animated GIF.  When the
> classname property is set from the outside by MXMLDataInterpreter or
> even
> user-written code, those classNames are added to the list with the
> typeNames and the shadow className if shadow is true and then set on
>>> the
> element.
> 
> Finally, for addClassName and removeClassName, and all other Royale
> code,
> we don't want to do much if any parameter checking.  That is also
> just-in-case code.  The production code should not be passing in
>>> null or
> other bad values.  And once you fix that, then the checks that you
>>> have
> written do not add value.  I have proposed that there are debug-only
> code
> that does parameter checking.  There is a goog.DEBUG flag you can use
> for
> that.
> 
> HTH,
> -Alex
> 
> On 2/28/18, 12:40 AM, "Piotr Zarzycki" 
> wrote:
> 
>> Hi Alex,
>> 
>> Sorry about that. Let me show you code and I recorded GIF with
>>> problem
>> debugging.
>> 
>> *Code in UIBase which I have implemented:*
>> addClassName and removeClassName [1].
>> addedToParent what is happen with internal field which I have added
>>> [2]
>> 
>> *Code for Testing* [3] - I'm adding first className, than shadow.
>> 
>> *GIF* [4] We are starting from the constructor. Pay attention to the
>> moment
>> where className is being wiped out, later I have to use my internal
>> variable to get it back.
>> 
>> Does that more clean now ?
>> 
>> [1]
>> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
>> che.org%2FEumG=02%7C01%7Caharui%40adobe.com%
> 7Cee5c84b4e3ff4ddb578008d
>> 57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554040718214998&
>> sdata=cDT88OF63TdBMPxYY2vwMSIRxD%2FP3DvwHupj%2BQHsofw%3D=0
>> [2]
>> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
>> che.org%2FArmU=02%7C01%7Caharui%40adobe.com%
> 7Cee5c84b4e3ff4ddb578008d
>> 57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554040718214998&
>> sdata=m6whImrP70u7kzRxCbErlxCHWef8TKNejwm4Sr7bw7g%3D=0
>> [3]
>> https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
>> che.org%2FKrxq=02%7C01%7Caharui%40adobe.com%
> 7Cee5c84b4e3ff4ddb578008d
>> 57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554040718214998&
>> sdata=tpeUYSQIXGXtES8hyr7zSeet528ZTczSltcNccqRGDo%3D=0
>> [4]

Re: TypeNames vs ClassName

[Alex Harui]

On 2/28/18, 9:50 AM, "Piotr Zarzycki"  wrote:

>Ok Understand, but do you agree that  computeFinalClassNames - is
>something
>which is in the UIBase ?

Yes, and probably protected instead of public.  The one in UIBase just
appends typenames to className.  It gets overridden in MDL where needed
for shadow and other attributes.

My 2 cents,
-Alex
>
>2018-02-28 18:47 GMT+01:00 Alex Harui :
>
>> I think that in the shadow setter, it would change _shadow and call
>> setClassName(computeFinalClassNames());
>>
>> On 2/28/18, 9:33 AM, "Piotr Zarzycki"  wrote:
>>
>> >Alex,
>> >
>> >So we are getting back to the idea where you proposed to have function
>> >which computes everything.
>> >
>> >override public function computeFinalClassNames():String
>> >{
>> >  return super.computeFinalClassNames() + " " + _shadow;
>> >}
>> >
>> >Where does that function should be placed ? Does that function should
>>be
>> >called in addedToParent plus whenever someone change _shadow ? -
>> >
>> >Because I really don't know how to handle scenario where you have some
>> >property isActive = true/false and I need to add/remove class. - In the
>> >first launch I use  computeFinalClassNames, but how to handle changing
>>?
>> >
>> >Thanks, Piotr
>> >
>> >
>> >2018-02-28 18:26 GMT+01:00 Alex Harui :
>> >
>> >> Hi Piotr,
>> >>
>> >> I think am I not communicating the principles effectively.
>> >>
>> >> First, IMO, addClassName and removeClassName should not be in UIBase.
>> >> Lots of apps can be written without needing these methods.  I think
>>they
>> >> can be written as utility functions.
>> >>
>> >> Second, the computation of the final element.className should
>>represent
>> >> the state of the component, so I don't get why you need an
>> >> _internalClassName or should ever set it to "".  The computation for
>>a
>> >> component with a shadow would be to check the shadow property and if
>>it
>> >>is
>> >> true, add a className for the shadow to the list.  Then I think you
>> >> wouldn't have the problem you showed in the animated GIF.  When the
>> >> classname property is set from the outside by MXMLDataInterpreter or
>> >>even
>> >> user-written code, those classNames are added to the list with the
>> >> typeNames and the shadow className if shadow is true and then set on
>>the
>> >> element.
>> >>
>> >> Finally, for addClassName and removeClassName, and all other Royale
>> >>code,
>> >> we don't want to do much if any parameter checking.  That is also
>> >> just-in-case code.  The production code should not be passing in
>>null or
>> >> other bad values.  And once you fix that, then the checks that you
>>have
>> >> written do not add value.  I have proposed that there are debug-only
>> >>code
>> >> that does parameter checking.  There is a goog.DEBUG flag you can use
>> >>for
>> >> that.
>> >>
>> >> HTH,
>> >> -Alex
>> >>
>> >> On 2/28/18, 12:40 AM, "Piotr Zarzycki" 
>> >>wrote:
>> >>
>> >> >Hi Alex,
>> >> >
>> >> >Sorry about that. Let me show you code and I recorded GIF with
>>problem
>> >> >debugging.
>> >> >
>> >> >*Code in UIBase which I have implemented:*
>> >> >addClassName and removeClassName [1].
>> >> >addedToParent what is happen with internal field which I have added
>>[2]
>> >> >
>> >> >*Code for Testing* [3] - I'm adding first className, than shadow.
>> >> >
>> >> >*GIF* [4] We are starting from the constructor. Pay attention to the
>> >> >moment
>> >> >where className is being wiped out, later I have to use my internal
>> >> >variable to get it back.
>> >> >
>> >> >Does that more clean now ?
>> >> >
>> >> >[1]
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fpaste.apa
>> >> >che.org%2FEumG=02%7C01%7Caharui%40adobe.com%
>> >> 7Cee5c84b4e3ff4ddb578008d
>> >> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636554040718214998&
>> >> >sdata=cDT88OF63TdBMPxYY2vwMSIRxD%2FP3DvwHupj%2BQHsofw%3D=0
>> >> >[2]
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fpaste.apa
>> >> >che.org%2FArmU=02%7C01%7Caharui%40adobe.com%
>> >> 7Cee5c84b4e3ff4ddb578008d
>> >> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636554040718214998&
>> >> >sdata=m6whImrP70u7kzRxCbErlxCHWef8TKNejwm4Sr7bw7g%3D=0
>> >> >[3]
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fpaste.apa
>> >> >che.org%2FKrxq=02%7C01%7Caharui%40adobe.com%
>> >> 7Cee5c84b4e3ff4ddb578008d
>> >> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636554040718214998&
>> >> >sdata=tpeUYSQIXGXtES8hyr7zSeet528ZTczSltcNccqRGDo%3D=0
>> >> >[4]
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2F1drv.ms%2
>> >> >Fu%2Fs!ApVpLyjpHDC2hPtoCi65kIZZPwjSpQ=02%7C01%7Caharui%40adobe
>> .com
>> >> %7C
>> >> >ee5c84b4e3ff4ddb578008d57e87046f%7Cfa7b1b5a7b34438794aed2c178de
>> >> cee1%7C0%7C
>> >> 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Ok Understand, but do you agree that  computeFinalClassNames - is something
which is in the UIBase ?

2018-02-28 18:47 GMT+01:00 Alex Harui :

> I think that in the shadow setter, it would change _shadow and call
> setClassName(computeFinalClassNames());
>
> On 2/28/18, 9:33 AM, "Piotr Zarzycki"  wrote:
>
> >Alex,
> >
> >So we are getting back to the idea where you proposed to have function
> >which computes everything.
> >
> >override public function computeFinalClassNames():String
> >{
> >  return super.computeFinalClassNames() + " " + _shadow;
> >}
> >
> >Where does that function should be placed ? Does that function should be
> >called in addedToParent plus whenever someone change _shadow ? -
> >
> >Because I really don't know how to handle scenario where you have some
> >property isActive = true/false and I need to add/remove class. - In the
> >first launch I use  computeFinalClassNames, but how to handle changing ?
> >
> >Thanks, Piotr
> >
> >
> >2018-02-28 18:26 GMT+01:00 Alex Harui :
> >
> >> Hi Piotr,
> >>
> >> I think am I not communicating the principles effectively.
> >>
> >> First, IMO, addClassName and removeClassName should not be in UIBase.
> >> Lots of apps can be written without needing these methods.  I think they
> >> can be written as utility functions.
> >>
> >> Second, the computation of the final element.className should represent
> >> the state of the component, so I don't get why you need an
> >> _internalClassName or should ever set it to "".  The computation for a
> >> component with a shadow would be to check the shadow property and if it
> >>is
> >> true, add a className for the shadow to the list.  Then I think you
> >> wouldn't have the problem you showed in the animated GIF.  When the
> >> classname property is set from the outside by MXMLDataInterpreter or
> >>even
> >> user-written code, those classNames are added to the list with the
> >> typeNames and the shadow className if shadow is true and then set on the
> >> element.
> >>
> >> Finally, for addClassName and removeClassName, and all other Royale
> >>code,
> >> we don't want to do much if any parameter checking.  That is also
> >> just-in-case code.  The production code should not be passing in null or
> >> other bad values.  And once you fix that, then the checks that you have
> >> written do not add value.  I have proposed that there are debug-only
> >>code
> >> that does parameter checking.  There is a goog.DEBUG flag you can use
> >>for
> >> that.
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 2/28/18, 12:40 AM, "Piotr Zarzycki" 
> >>wrote:
> >>
> >> >Hi Alex,
> >> >
> >> >Sorry about that. Let me show you code and I recorded GIF with problem
> >> >debugging.
> >> >
> >> >*Code in UIBase which I have implemented:*
> >> >addClassName and removeClassName [1].
> >> >addedToParent what is happen with internal field which I have added [2]
> >> >
> >> >*Code for Testing* [3] - I'm adding first className, than shadow.
> >> >
> >> >*GIF* [4] We are starting from the constructor. Pay attention to the
> >> >moment
> >> >where className is being wiped out, later I have to use my internal
> >> >variable to get it back.
> >> >
> >> >Does that more clean now ?
> >> >
> >> >[1]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.apa
> >> >che.org%2FEumG=02%7C01%7Caharui%40adobe.com%
> >> 7Cee5c84b4e3ff4ddb578008d
> >> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636554040718214998&
> >> >sdata=cDT88OF63TdBMPxYY2vwMSIRxD%2FP3DvwHupj%2BQHsofw%3D=0
> >> >[2]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.apa
> >> >che.org%2FArmU=02%7C01%7Caharui%40adobe.com%
> >> 7Cee5c84b4e3ff4ddb578008d
> >> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636554040718214998&
> >> >sdata=m6whImrP70u7kzRxCbErlxCHWef8TKNejwm4Sr7bw7g%3D=0
> >> >[3]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.apa
> >> >che.org%2FKrxq=02%7C01%7Caharui%40adobe.com%
> >> 7Cee5c84b4e3ff4ddb578008d
> >> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636554040718214998&
> >> >sdata=tpeUYSQIXGXtES8hyr7zSeet528ZTczSltcNccqRGDo%3D=0
> >> >[4]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2F1drv.ms%2
> >> >Fu%2Fs!ApVpLyjpHDC2hPtoCi65kIZZPwjSpQ=02%7C01%7Caharui%40adobe
> .com
> >> %7C
> >> >ee5c84b4e3ff4ddb578008d57e87046f%7Cfa7b1b5a7b34438794aed2c178de
> >> cee1%7C0%7C
> >> >0%7C636554040718214998=eX%2FgZ0MA%2BdQJjcpYtMkk1pw3r0iVkdRa%
> >> 2F6TWRTG
> >> >10OY%3D=0
> >> >
> >> >Thanks,
> >> >Piotr
> >> >
> >> >2018-02-27 23:31 GMT+01:00 Alex Harui :
> >> >
> >> >> Hi Piotr,
> >> >>
> >> >> I could not understand this explanation. Might be better to show
> >>actual
> >> >> code.  For example in #3, there is a cssClass variable that I don't
> >>know
> >> >> about.  Also you 

Re: TypeNames vs ClassName

[Alex Harui]

I think that in the shadow setter, it would change _shadow and call
setClassName(computeFinalClassNames());

On 2/28/18, 9:33 AM, "Piotr Zarzycki"  wrote:

>Alex,
>
>So we are getting back to the idea where you proposed to have function
>which computes everything.
>
>override public function computeFinalClassNames():String
>{
>  return super.computeFinalClassNames() + " " + _shadow;
>}
>
>Where does that function should be placed ? Does that function should be
>called in addedToParent plus whenever someone change _shadow ? -
>
>Because I really don't know how to handle scenario where you have some
>property isActive = true/false and I need to add/remove class. - In the
>first launch I use  computeFinalClassNames, but how to handle changing ?
>
>Thanks, Piotr
>
>
>2018-02-28 18:26 GMT+01:00 Alex Harui :
>
>> Hi Piotr,
>>
>> I think am I not communicating the principles effectively.
>>
>> First, IMO, addClassName and removeClassName should not be in UIBase.
>> Lots of apps can be written without needing these methods.  I think they
>> can be written as utility functions.
>>
>> Second, the computation of the final element.className should represent
>> the state of the component, so I don't get why you need an
>> _internalClassName or should ever set it to "".  The computation for a
>> component with a shadow would be to check the shadow property and if it
>>is
>> true, add a className for the shadow to the list.  Then I think you
>> wouldn't have the problem you showed in the animated GIF.  When the
>> classname property is set from the outside by MXMLDataInterpreter or
>>even
>> user-written code, those classNames are added to the list with the
>> typeNames and the shadow className if shadow is true and then set on the
>> element.
>>
>> Finally, for addClassName and removeClassName, and all other Royale
>>code,
>> we don't want to do much if any parameter checking.  That is also
>> just-in-case code.  The production code should not be passing in null or
>> other bad values.  And once you fix that, then the checks that you have
>> written do not add value.  I have proposed that there are debug-only
>>code
>> that does parameter checking.  There is a goog.DEBUG flag you can use
>>for
>> that.
>>
>> HTH,
>> -Alex
>>
>> On 2/28/18, 12:40 AM, "Piotr Zarzycki" 
>>wrote:
>>
>> >Hi Alex,
>> >
>> >Sorry about that. Let me show you code and I recorded GIF with problem
>> >debugging.
>> >
>> >*Code in UIBase which I have implemented:*
>> >addClassName and removeClassName [1].
>> >addedToParent what is happen with internal field which I have added [2]
>> >
>> >*Code for Testing* [3] - I'm adding first className, than shadow.
>> >
>> >*GIF* [4] We are starting from the constructor. Pay attention to the
>> >moment
>> >where className is being wiped out, later I have to use my internal
>> >variable to get it back.
>> >
>> >Does that more clean now ?
>> >
>> >[1]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.apa
>> >che.org%2FEumG=02%7C01%7Caharui%40adobe.com%
>> 7Cee5c84b4e3ff4ddb578008d
>> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636554040718214998&
>> >sdata=cDT88OF63TdBMPxYY2vwMSIRxD%2FP3DvwHupj%2BQHsofw%3D=0
>> >[2]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.apa
>> >che.org%2FArmU=02%7C01%7Caharui%40adobe.com%
>> 7Cee5c84b4e3ff4ddb578008d
>> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636554040718214998&
>> >sdata=m6whImrP70u7kzRxCbErlxCHWef8TKNejwm4Sr7bw7g%3D=0
>> >[3]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.apa
>> >che.org%2FKrxq=02%7C01%7Caharui%40adobe.com%
>> 7Cee5c84b4e3ff4ddb578008d
>> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636554040718214998&
>> >sdata=tpeUYSQIXGXtES8hyr7zSeet528ZTczSltcNccqRGDo%3D=0
>> >[4]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2F1drv.ms%2
>> >Fu%2Fs!ApVpLyjpHDC2hPtoCi65kIZZPwjSpQ=02%7C01%7Caharui%40adobe.com
>> %7C
>> >ee5c84b4e3ff4ddb578008d57e87046f%7Cfa7b1b5a7b34438794aed2c178de
>> cee1%7C0%7C
>> >0%7C636554040718214998=eX%2FgZ0MA%2BdQJjcpYtMkk1pw3r0iVkdRa%
>> 2F6TWRTG
>> >10OY%3D=0
>> >
>> >Thanks,
>> >Piotr
>> >
>> >2018-02-27 23:31 GMT+01:00 Alex Harui :
>> >
>> >> Hi Piotr,
>> >>
>> >> I could not understand this explanation. Might be better to show
>>actual
>> >> code.  For example in #3, there is a cssClass variable that I don't
>>know
>> >> about.  Also you mention at the bottom setting something as empty,
>>but
>> >>I'm
>> >> not sure what that is.
>> >>
>> >> However, IMO, this code should be in utility functions, not in
>>UIBase.
>> >>I
>> >> think plenty of useful applications can be built without changing
>> >> classNames at runtime.
>> >>
>> >> I'm off-line for the next several hours so we can pick this up again
>>in
>> >> your morning.
>> >>
>> >> Thanks for working on it,
>> 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Alex,

So we are getting back to the idea where you proposed to have function
which computes everything.

override public function computeFinalClassNames():String
{
  return super.computeFinalClassNames() + " " + _shadow;
}

Where does that function should be placed ? Does that function should be
called in addedToParent plus whenever someone change _shadow ? -

Because I really don't know how to handle scenario where you have some
property isActive = true/false and I need to add/remove class. - In the
first launch I use  computeFinalClassNames, but how to handle changing ?

Thanks, Piotr


2018-02-28 18:26 GMT+01:00 Alex Harui :

> Hi Piotr,
>
> I think am I not communicating the principles effectively.
>
> First, IMO, addClassName and removeClassName should not be in UIBase.
> Lots of apps can be written without needing these methods.  I think they
> can be written as utility functions.
>
> Second, the computation of the final element.className should represent
> the state of the component, so I don't get why you need an
> _internalClassName or should ever set it to "".  The computation for a
> component with a shadow would be to check the shadow property and if it is
> true, add a className for the shadow to the list.  Then I think you
> wouldn't have the problem you showed in the animated GIF.  When the
> classname property is set from the outside by MXMLDataInterpreter or even
> user-written code, those classNames are added to the list with the
> typeNames and the shadow className if shadow is true and then set on the
> element.
>
> Finally, for addClassName and removeClassName, and all other Royale code,
> we don't want to do much if any parameter checking.  That is also
> just-in-case code.  The production code should not be passing in null or
> other bad values.  And once you fix that, then the checks that you have
> written do not add value.  I have proposed that there are debug-only code
> that does parameter checking.  There is a goog.DEBUG flag you can use for
> that.
>
> HTH,
> -Alex
>
> On 2/28/18, 12:40 AM, "Piotr Zarzycki"  wrote:
>
> >Hi Alex,
> >
> >Sorry about that. Let me show you code and I recorded GIF with problem
> >debugging.
> >
> >*Code in UIBase which I have implemented:*
> >addClassName and removeClassName [1].
> >addedToParent what is happen with internal field which I have added [2]
> >
> >*Code for Testing* [3] - I'm adding first className, than shadow.
> >
> >*GIF* [4] We are starting from the constructor. Pay attention to the
> >moment
> >where className is being wiped out, later I have to use my internal
> >variable to get it back.
> >
> >Does that more clean now ?
> >
> >[1]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2FEumG=02%7C01%7Caharui%40adobe.com%
> 7Cee5c84b4e3ff4ddb578008d
> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554040718214998&
> >sdata=cDT88OF63TdBMPxYY2vwMSIRxD%2FP3DvwHupj%2BQHsofw%3D=0
> >[2]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2FArmU=02%7C01%7Caharui%40adobe.com%
> 7Cee5c84b4e3ff4ddb578008d
> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554040718214998&
> >sdata=m6whImrP70u7kzRxCbErlxCHWef8TKNejwm4Sr7bw7g%3D=0
> >[3]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2FKrxq=02%7C01%7Caharui%40adobe.com%
> 7Cee5c84b4e3ff4ddb578008d
> >57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636554040718214998&
> >sdata=tpeUYSQIXGXtES8hyr7zSeet528ZTczSltcNccqRGDo%3D=0
> >[4]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2F1drv.ms%2
> >Fu%2Fs!ApVpLyjpHDC2hPtoCi65kIZZPwjSpQ=02%7C01%7Caharui%40adobe.com
> %7C
> >ee5c84b4e3ff4ddb578008d57e87046f%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C
> >0%7C636554040718214998=eX%2FgZ0MA%2BdQJjcpYtMkk1pw3r0iVkdRa%
> 2F6TWRTG
> >10OY%3D=0
> >
> >Thanks,
> >Piotr
> >
> >2018-02-27 23:31 GMT+01:00 Alex Harui :
> >
> >> Hi Piotr,
> >>
> >> I could not understand this explanation. Might be better to show actual
> >> code.  For example in #3, there is a cssClass variable that I don't know
> >> about.  Also you mention at the bottom setting something as empty, but
> >>I'm
> >> not sure what that is.
> >>
> >> However, IMO, this code should be in utility functions, not in UIBase.
> >>I
> >> think plenty of useful applications can be built without changing
> >> classNames at runtime.
> >>
> >> I'm off-line for the next several hours so we can pick this up again in
> >> your morning.
> >>
> >> Thanks for working on it,
> >> -Alex
> >>
> >> On 2/27/18, 2:21 PM, "Piotr Zarzycki" 
> wrote:
> >>
> >> >Here is how I'm thinking to resolve that issue. I would take Harb's
> >> >proposition and add to UIBase  addClassName() and removeClassName().
> >>Next
> >> >I
> >> >would add internal field _internalClassName:String.
> >> >
> >> 

Re: TypeNames vs ClassName

[Alex Harui]

Hi Piotr,

I think am I not communicating the principles effectively.

First, IMO, addClassName and removeClassName should not be in UIBase.
Lots of apps can be written without needing these methods.  I think they
can be written as utility functions.

Second, the computation of the final element.className should represent
the state of the component, so I don't get why you need an
_internalClassName or should ever set it to "".  The computation for a
component with a shadow would be to check the shadow property and if it is
true, add a className for the shadow to the list.  Then I think you
wouldn't have the problem you showed in the animated GIF.  When the
classname property is set from the outside by MXMLDataInterpreter or even
user-written code, those classNames are added to the list with the
typeNames and the shadow className if shadow is true and then set on the
element.

Finally, for addClassName and removeClassName, and all other Royale code,
we don't want to do much if any parameter checking.  That is also
just-in-case code.  The production code should not be passing in null or
other bad values.  And once you fix that, then the checks that you have
written do not add value.  I have proposed that there are debug-only code
that does parameter checking.  There is a goog.DEBUG flag you can use for
that.

HTH,
-Alex

On 2/28/18, 12:40 AM, "Piotr Zarzycki"  wrote:

>Hi Alex,
>
>Sorry about that. Let me show you code and I recorded GIF with problem
>debugging.
>
>*Code in UIBase which I have implemented:*
>addClassName and removeClassName [1].
>addedToParent what is happen with internal field which I have added [2]
>
>*Code for Testing* [3] - I'm adding first className, than shadow.
>
>*GIF* [4] We are starting from the constructor. Pay attention to the
>moment
>where className is being wiped out, later I have to use my internal
>variable to get it back.
>
>Does that more clean now ?
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FEumG=02%7C01%7Caharui%40adobe.com%7Cee5c84b4e3ff4ddb578008d
>57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554040718214998&
>sdata=cDT88OF63TdBMPxYY2vwMSIRxD%2FP3DvwHupj%2BQHsofw%3D=0
>[2] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FArmU=02%7C01%7Caharui%40adobe.com%7Cee5c84b4e3ff4ddb578008d
>57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554040718214998&
>sdata=m6whImrP70u7kzRxCbErlxCHWef8TKNejwm4Sr7bw7g%3D=0
>[3] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FKrxq=02%7C01%7Caharui%40adobe.com%7Cee5c84b4e3ff4ddb578008d
>57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636554040718214998&
>sdata=tpeUYSQIXGXtES8hyr7zSeet528ZTczSltcNccqRGDo%3D=0
>[4] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2F1drv.ms%2
>Fu%2Fs!ApVpLyjpHDC2hPtoCi65kIZZPwjSpQ=02%7C01%7Caharui%40adobe.com%7C
>ee5c84b4e3ff4ddb578008d57e87046f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C
>0%7C636554040718214998=eX%2FgZ0MA%2BdQJjcpYtMkk1pw3r0iVkdRa%2F6TWRTG
>10OY%3D=0
>
>Thanks,
>Piotr
>
>2018-02-27 23:31 GMT+01:00 Alex Harui :
>
>> Hi Piotr,
>>
>> I could not understand this explanation. Might be better to show actual
>> code.  For example in #3, there is a cssClass variable that I don't know
>> about.  Also you mention at the bottom setting something as empty, but
>>I'm
>> not sure what that is.
>>
>> However, IMO, this code should be in utility functions, not in UIBase.
>>I
>> think plenty of useful applications can be built without changing
>> classNames at runtime.
>>
>> I'm off-line for the next several hours so we can pick this up again in
>> your morning.
>>
>> Thanks for working on it,
>> -Alex
>>
>> On 2/27/18, 2:21 PM, "Piotr Zarzycki"  wrote:
>>
>> >Here is how I'm thinking to resolve that issue. I would take Harb's
>> >proposition and add to UIBase  addClassName() and removeClassName().
>>Next
>> >I
>> >would add internal field _internalClassName:String.
>> >
>> >addClassName(value):
>> >1) Will check if provided class name exits in _className and in
>> >_internalClassName.
>> >2) Will add to _internalClassName += value
>> >3) Assign to the element.className in the following way:
>>element.className
>> >= cssClass + " " + _className + " " + typeNames;
>> >
>> >removeClassName(value)
>> >1) Will check if provided classs name exists in  _className or in
>> >_internalClassName
>> >2) Make a replace to empty string if css class name exists.
>> >_className.replace(value, "");
>> >3) Assign to the element.className: element.className = _className + "
>>" +
>> >typeNames;
>> >
>> >In added to parent we are computing _internalClassName with _className
>>and
>> >typeNames. Then it's being set as empty.
>> >
>> >element.className =  _internalClassName  + " " + _className + " " +
>> >typeNames;
>> >
>> >I have implemented it and it seems to be working. Waiting 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Hi Alex,

Sorry about that. Let me show you code and I recorded GIF with problem
debugging.

*Code in UIBase which I have implemented:*
addClassName and removeClassName [1].
addedToParent what is happen with internal field which I have added [2]

*Code for Testing* [3] - I'm adding first className, than shadow.

*GIF* [4] We are starting from the constructor. Pay attention to the moment
where className is being wiped out, later I have to use my internal
variable to get it back.

Does that more clean now ?

[1] https://paste.apache.org/EumG
[2] https://paste.apache.org/ArmU
[3] https://paste.apache.org/Krxq
[4] https://1drv.ms/u/s!ApVpLyjpHDC2hPtoCi65kIZZPwjSpQ

Thanks,
Piotr

2018-02-27 23:31 GMT+01:00 Alex Harui :

> Hi Piotr,
>
> I could not understand this explanation. Might be better to show actual
> code.  For example in #3, there is a cssClass variable that I don't know
> about.  Also you mention at the bottom setting something as empty, but I'm
> not sure what that is.
>
> However, IMO, this code should be in utility functions, not in UIBase.  I
> think plenty of useful applications can be built without changing
> classNames at runtime.
>
> I'm off-line for the next several hours so we can pick this up again in
> your morning.
>
> Thanks for working on it,
> -Alex
>
> On 2/27/18, 2:21 PM, "Piotr Zarzycki"  wrote:
>
> >Here is how I'm thinking to resolve that issue. I would take Harb's
> >proposition and add to UIBase  addClassName() and removeClassName(). Next
> >I
> >would add internal field _internalClassName:String.
> >
> >addClassName(value):
> >1) Will check if provided class name exits in _className and in
> >_internalClassName.
> >2) Will add to _internalClassName += value
> >3) Assign to the element.className in the following way: element.className
> >= cssClass + " " + _className + " " + typeNames;
> >
> >removeClassName(value)
> >1) Will check if provided classs name exists in  _className or in
> >_internalClassName
> >2) Make a replace to empty string if css class name exists.
> >_className.replace(value, "");
> >3) Assign to the element.className: element.className = _className + " " +
> >typeNames;
> >
> >In added to parent we are computing _internalClassName with _className and
> >typeNames. Then it's being set as empty.
> >
> >element.className =  _internalClassName  + " " + _className + " " +
> >typeNames;
> >
> >I have implemented it and it seems to be working. Waiting for your
> >thoughts
> >on that solution. The last step where we are adding all three fields is
> >the
> >most important. Points 3 in addClassName and removeClassName are
> >necessary,
> >because user may want to more dynamically manipulate classes once
> >component
> >is created. Ex. "is-active" class is removed and added on demand.
> >
> >Thanks, Piotr
> >
> >
> >2018-02-27 13:38 GMT+01:00 Piotr Zarzycki :
> >
> >> I think I have analyzed everything and have some implementation
> >> proposition. I will try to provide it later today.
> >>
> >> Thanks, Piotr
> >>
> >> 2018-02-27 13:35 GMT+01:00 Harbs :
> >>
> >>> ExpandableSearch broke too.
> >>>
> >>> > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki
> >>>
> >>> wrote:
> >>> >
> >>> > Harbs,
> >>> >
> >>> > If you are using something more than MDL Dialog in your application
> >>>it
> >>> > would be great to get feedback whether I didn't break for you
> >>>anything.
> >>> :)
> >>>
> >>>
> >>
> >>
> >> --
> >>
> >> Piotr Zarzycki
> >>
> >> Patreon:
> >>*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com
> %7C45a065853ba1
> >>4a295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365536
> >>69427477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK
> 9liXcy%2BPg%3D
> >>rved=0
> >>
> >> https%3A%2F%2Fwww.pat
> >>reon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com
> %7C45a065853ba1
> >>4a295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365536
> >>69427477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK
> 9liXcy%2BPg%3D
> >>rved=0>*
> >>
> >
> >
> >
> >--
> >
> >Piotr Zarzycki
> >
> >Patreon:
> >*https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%
> 7C45a065853ba14a
> >295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365536694
> >27477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK
> 9liXcy%2BPg%3D
> >=0
> > https%3A%2F%2Fwww.patr
> >eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%
> 7C45a065853ba14a
> >295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C6365536694
> >27477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK
> 9liXcy%2BPg%3D
> >=0>*
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki

Re: TypeNames vs ClassName

[Alex Harui]

Hi Piotr,

I could not understand this explanation. Might be better to show actual
code.  For example in #3, there is a cssClass variable that I don't know
about.  Also you mention at the bottom setting something as empty, but I'm
not sure what that is.

However, IMO, this code should be in utility functions, not in UIBase.  I
think plenty of useful applications can be built without changing
classNames at runtime.

I'm off-line for the next several hours so we can pick this up again in
your morning.

Thanks for working on it,
-Alex

On 2/27/18, 2:21 PM, "Piotr Zarzycki"  wrote:

>Here is how I'm thinking to resolve that issue. I would take Harb's
>proposition and add to UIBase  addClassName() and removeClassName(). Next
>I
>would add internal field _internalClassName:String.
>
>addClassName(value):
>1) Will check if provided class name exits in _className and in
>_internalClassName.
>2) Will add to _internalClassName += value
>3) Assign to the element.className in the following way: element.className
>= cssClass + " " + _className + " " + typeNames;
>
>removeClassName(value)
>1) Will check if provided classs name exists in  _className or in
>_internalClassName
>2) Make a replace to empty string if css class name exists.
>_className.replace(value, "");
>3) Assign to the element.className: element.className = _className + " " +
>typeNames;
>
>In added to parent we are computing _internalClassName with _className and
>typeNames. Then it's being set as empty.
>
>element.className =  _internalClassName  + " " + _className + " " +
>typeNames;
>
>I have implemented it and it seems to be working. Waiting for your
>thoughts
>on that solution. The last step where we are adding all three fields is
>the
>most important. Points 3 in addClassName and removeClassName are
>necessary,
>because user may want to more dynamically manipulate classes once
>component
>is created. Ex. "is-active" class is removed and added on demand.
>
>Thanks, Piotr
>
>
>2018-02-27 13:38 GMT+01:00 Piotr Zarzycki :
>
>> I think I have analyzed everything and have some implementation
>> proposition. I will try to provide it later today.
>>
>> Thanks, Piotr
>>
>> 2018-02-27 13:35 GMT+01:00 Harbs :
>>
>>> ExpandableSearch broke too.
>>>
>>> > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki
>>>
>>> wrote:
>>> >
>>> > Harbs,
>>> >
>>> > If you are using something more than MDL Dialog in your application
>>>it
>>> > would be great to get feedback whether I didn't break for you
>>>anything.
>>> :)
>>>
>>>
>>
>>
>> --
>>
>> Piotr Zarzycki
>>
>> Patreon: 
>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pat
>>reon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C45a065853ba1
>>4a295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365536
>>69427477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK9liXcy%2BPg%3D
>>rved=0
>> 
>>>reon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C45a065853ba1
>>4a295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365536
>>69427477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK9liXcy%2BPg%3D
>>rved=0>*
>>
>
>
>
>-- 
>
>Piotr Zarzycki
>
>Patreon: 
>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patr
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C45a065853ba14a
>295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365536694
>27477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK9liXcy%2BPg%3D
>=0
>eon.com%2Fpiotrzarzycki=02%7C01%7Caharui%40adobe.com%7C45a065853ba14a
>295d9d08d57e3082b9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365536694
>27477536=tOlZF%2FWAGhqn1toqJCCqjc14NZU56MnZZK9liXcy%2BPg%3D
>=0>*

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Here is how I'm thinking to resolve that issue. I would take Harb's
proposition and add to UIBase  addClassName() and removeClassName(). Next I
would add internal field _internalClassName:String.

addClassName(value):
1) Will check if provided class name exits in _className and in
_internalClassName.
2) Will add to _internalClassName += value
3) Assign to the element.className in the following way: element.className
= cssClass + " " + _className + " " + typeNames;

removeClassName(value)
1) Will check if provided classs name exists in  _className or in
_internalClassName
2) Make a replace to empty string if css class name exists.
_className.replace(value, "");
3) Assign to the element.className: element.className = _className + " " +
typeNames;

In added to parent we are computing _internalClassName with _className and
typeNames. Then it's being set as empty.

element.className =  _internalClassName  + " " + _className + " " +
typeNames;

I have implemented it and it seems to be working. Waiting for your thoughts
on that solution. The last step where we are adding all three fields is the
most important. Points 3 in addClassName and removeClassName are necessary,
because user may want to more dynamically manipulate classes once component
is created. Ex. "is-active" class is removed and added on demand.

Thanks, Piotr


2018-02-27 13:38 GMT+01:00 Piotr Zarzycki :

> I think I have analyzed everything and have some implementation
> proposition. I will try to provide it later today.
>
> Thanks, Piotr
>
> 2018-02-27 13:35 GMT+01:00 Harbs :
>
>> ExpandableSearch broke too.
>>
>> > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki 
>> wrote:
>> >
>> > Harbs,
>> >
>> > If you are using something more than MDL Dialog in your application it
>> > would be great to get feedback whether I didn't break for you anything.
>> :)
>>
>>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: TypeNames vs ClassName

[Piotr Zarzycki]

I think I have analyzed everything and have some implementation
proposition. I will try to provide it later today.

Thanks, Piotr

2018-02-27 13:35 GMT+01:00 Harbs :

> ExpandableSearch broke too.
>
> > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki 
> wrote:
> >
> > Harbs,
> >
> > If you are using something more than MDL Dialog in your application it
> > would be great to get feedback whether I didn't break for you anything.
> :)
>
>


-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: TypeNames vs ClassName

[Harbs]

ExpandableSearch broke too.

> On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki  wrote:
> 
> Harbs,
> 
> If you are using something more than MDL Dialog in your application it
> would be great to get feedback whether I didn't break for you anything. :)

Re: TypeNames vs ClassName

[Piotr Zarzycki]

I know what you mean Harbs, but it may not be so easy to achieve. classList
and className at some point are wiped out.

When I was working on changes in MDL it happened in addedToParent.

The end of all process to save things was always concatenating.

I think having couple of functions is a good thing, but even that I would
have to use Array or classList than store it to make sure that is not wiped
out. Somewhere in the addedToParent probably make concatenation with all
stuff which is being gather.

I need to deeper look.

1) Having one function for computing leave to the creator of component how
he will store all the css class and then concatenate them.
2) Having separate functions end up that somewhere in our class we will
have Array, classList or whatever which later will be used to concatenation.

Piotr

On Mon, Feb 26, 2018, 21:26 Alex Harui  wrote:

> My thinking is that there are a set of defaults in typeNames that match
> fake type selectors and should almost never be changed at runtime.  What
> scenario made you want to change typeNames outside the component?
>
> Then there is another set of class names that you specify outside the
> component.  There should already be a classname setter for MXML.
> Specifying a space-delimited set of strings seems more common than using
> classList Array and Arrays are more painful to write in MXML.  HTMLElement
> already has a classList Array API.  I just think folks are more used to
> strings.
>
> So given a "Fixed" set and a "variable" set, you need to concatenate the
> two sets.  We could split the sets and use array APIs, but that might
> actually be slower.
>
> And then for MDL, there is a third set which is the set of attributes like
> "shadow" which is why you would override the computation.
>
> My 2 cents,
> -Alex
>
> On 2/26/18, 11:44 AM, "Harbs"  wrote:
>
> >I think my main point was that we wouldn’t need computeFinalClassNames()
> >which would be overridden in subclasses.
> >
> >If there’s simple a _classList:Array which would have something like:
> >protected function applyClassNames():void
> >{
> >   element.className = className ? className : “” + “ “ +
> _classList.join(“
> >“).trim();
> >}
> >
> >Which could replace the setClassName() method.
> >
> >The rest was simply how to go about building the _classList.
> >
> >We’re probably more or less saying the same thing.
> >
> >> On Feb 26, 2018, at 9:35 PM, Piotr Zarzycki 
> >>wrote:
> >>
> >> Harbs,
> >>
> >> You simply suggesting to have several functions instead of one which
> >> computes things?
> >>
> >>
> >>
> >> On Mon, Feb 26, 2018, 20:21 Harbs  wrote:
> >>
> >>> Yes. Very thorough explanation. Thanks.
> >>>
> >>> It seems to me like there should be functions for addClassName() and
> >>> removeClassName() which would add and remove the classNames from a
> >>>list.
> >>> When the className is computed, the list should be concatenated to
> >>> classNames (and possibly typeNames — although we might not need
> >>>typeNames
> >>> if there’s a general list). We might also want a clearClassNames()
> >>>method
> >>> to allow removal of “default” classNames for classes which have such a
> >>>need.
> >>>
> >>> I do think we also need a className setter so classNames could be
> >>> specified in mxml, but we might be able to do away with typeNames. That
> >>> might simplify things.
> >>>
> >>> My $0.02,
> >>> Harbs
> >>>
> >>>
>  On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki
> 
> >>> wrote:
> 
>  Hi Alex,
> 
>  Great reading and explanation. My first thought was to have something
> >>> which
>  computes className together, but currently it is needed for MDL only
>  almost. I went with this additional function Utility.
>  I think there won't be too much time when we will need such ability
> like
>  switching and adding shadow css classes etc.
> 
>  If other also think about such function I would be happy to implement
> it.
>  It will really get rid of a lot of dump code and even some
> workarounds in
>  MDL. Live would be much easier.
> 
>  +1 to have such functions.
> 
>  All of that should land on the Wiki or somewhere in the documentation.
> 
>  Waiting for thoughts from others.
> 
>  Thanks, Piotr
> 
>  2018-02-26 18:50 GMT+01:00 Alex Harui :
> 
> > Here's my view of this problem space.  This is my opinion, not
> >marching
> > orders.  Everything is up for discussion.  This is what the current
> >code
> > is trying to do, though.  Also, important note:  The order of names
> >in
> >>> the
> > HTMLElement.className does not matter.  CSS style precedence is
> >>> determined
> > by the order of declarations in the CSS file.  OK, lots of reading
> >>> ahead:
> >
> > HTML and JavaScript do not really have 

Re: TypeNames vs ClassName

[Alex Harui]

My thinking is that there are a set of defaults in typeNames that match
fake type selectors and should almost never be changed at runtime.  What
scenario made you want to change typeNames outside the component?

Then there is another set of class names that you specify outside the
component.  There should already be a classname setter for MXML.
Specifying a space-delimited set of strings seems more common than using
classList Array and Arrays are more painful to write in MXML.  HTMLElement
already has a classList Array API.  I just think folks are more used to
strings.

So given a "Fixed" set and a "variable" set, you need to concatenate the
two sets.  We could split the sets and use array APIs, but that might
actually be slower.

And then for MDL, there is a third set which is the set of attributes like
"shadow" which is why you would override the computation.

My 2 cents,
-Alex

On 2/26/18, 11:44 AM, "Harbs"  wrote:

>I think my main point was that we wouldn’t need computeFinalClassNames()
>which would be overridden in subclasses.
>
>If there’s simple a _classList:Array which would have something like:
>protected function applyClassNames():void
>{
>   element.className = className ? className : “” + “ “ + _classList.join(“
>“).trim();
>}
>
>Which could replace the setClassName() method.
>
>The rest was simply how to go about building the _classList.
>
>We’re probably more or less saying the same thing.
>
>> On Feb 26, 2018, at 9:35 PM, Piotr Zarzycki 
>>wrote:
>> 
>> Harbs,
>> 
>> You simply suggesting to have several functions instead of one which
>> computes things?
>> 
>> 
>> 
>> On Mon, Feb 26, 2018, 20:21 Harbs  wrote:
>> 
>>> Yes. Very thorough explanation. Thanks.
>>> 
>>> It seems to me like there should be functions for addClassName() and
>>> removeClassName() which would add and remove the classNames from a
>>>list.
>>> When the className is computed, the list should be concatenated to
>>> classNames (and possibly typeNames — although we might not need
>>>typeNames
>>> if there’s a general list). We might also want a clearClassNames()
>>>method
>>> to allow removal of “default” classNames for classes which have such a
>>>need.
>>> 
>>> I do think we also need a className setter so classNames could be
>>> specified in mxml, but we might be able to do away with typeNames. That
>>> might simplify things.
>>> 
>>> My $0.02,
>>> Harbs
>>> 
>>> 
 On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki

>>> wrote:
 
 Hi Alex,
 
 Great reading and explanation. My first thought was to have something
>>> which
 computes className together, but currently it is needed for MDL only
 almost. I went with this additional function Utility.
 I think there won't be too much time when we will need such ability
like
 switching and adding shadow css classes etc.
 
 If other also think about such function I would be happy to implement
it.
 It will really get rid of a lot of dump code and even some
workarounds in
 MDL. Live would be much easier.
 
 +1 to have such functions.
 
 All of that should land on the Wiki or somewhere in the documentation.
 
 Waiting for thoughts from others.
 
 Thanks, Piotr
 
 2018-02-26 18:50 GMT+01:00 Alex Harui :
 
> Here's my view of this problem space.  This is my opinion, not
>marching
> orders.  Everything is up for discussion.  This is what the current
>code
> is trying to do, though.  Also, important note:  The order of names
>in
>>> the
> HTMLElement.className does not matter.  CSS style precedence is
>>> determined
> by the order of declarations in the CSS file.  OK, lots of reading
>>> ahead:
> 
> HTML and JavaScript do not really have a first-class notion of a
>Class
> like we do in ActionScript.  IOW, no such thing as true subclassing,
> especially in a way that supports Reflection APIs like
> flash.utils.getQualifiedClassName.  So, there is a fixed set of
>types in
> the browser, such as Button, Input, Div (which, by the way, are
> implemented as instances of HTMLButtonElement, HTMLInputElement,
> HTMLDivElement and not just Button, Input, Div).  And thus, a fixed
>set
>>> of
> Type Selectors in CSS.  You can't really make up new Type selectors,
>>> AFAIK.
> 
> A CSS Class selector is the way that you can distinguish one set of,
>>> say,
> HTMLDivElements, from another set of HTMLDivElements.  Since you
>can't
> make subclasses and new type selectors, you set the HTML class or
> JavaScript HTMLElement.className/classList on individual HTML
>elements
>>> and
> declare them to be of class "BigButton" or whatever.  It is their
>form
>>> of
> subclassing.
> 
> In Flex/Flash/SWF/ActionScript, folks are used to being able to make

Re: TypeNames vs ClassName

[Harbs]

I think my main point was that we wouldn’t need computeFinalClassNames() which 
would be overridden in subclasses.

If there’s simple a _classList:Array which would have something like:
protected function applyClassNames():void
{
element.className = className ? className : “” + “ “ + 
_classList.join(“ “).trim();
}

Which could replace the setClassName() method.

The rest was simply how to go about building the _classList.

We’re probably more or less saying the same thing.

> On Feb 26, 2018, at 9:35 PM, Piotr Zarzycki  wrote:
> 
> Harbs,
> 
> You simply suggesting to have several functions instead of one which
> computes things?
> 
> 
> 
> On Mon, Feb 26, 2018, 20:21 Harbs  wrote:
> 
>> Yes. Very thorough explanation. Thanks.
>> 
>> It seems to me like there should be functions for addClassName() and
>> removeClassName() which would add and remove the classNames from a list.
>> When the className is computed, the list should be concatenated to
>> classNames (and possibly typeNames — although we might not need typeNames
>> if there’s a general list). We might also want a clearClassNames() method
>> to allow removal of “default” classNames for classes which have such a need.
>> 
>> I do think we also need a className setter so classNames could be
>> specified in mxml, but we might be able to do away with typeNames. That
>> might simplify things.
>> 
>> My $0.02,
>> Harbs
>> 
>> 
>>> On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki 
>> wrote:
>>> 
>>> Hi Alex,
>>> 
>>> Great reading and explanation. My first thought was to have something
>> which
>>> computes className together, but currently it is needed for MDL only
>>> almost. I went with this additional function Utility.
>>> I think there won't be too much time when we will need such ability like
>>> switching and adding shadow css classes etc.
>>> 
>>> If other also think about such function I would be happy to implement it.
>>> It will really get rid of a lot of dump code and even some workarounds in
>>> MDL. Live would be much easier.
>>> 
>>> +1 to have such functions.
>>> 
>>> All of that should land on the Wiki or somewhere in the documentation.
>>> 
>>> Waiting for thoughts from others.
>>> 
>>> Thanks, Piotr
>>> 
>>> 2018-02-26 18:50 GMT+01:00 Alex Harui :
>>> 
 Here's my view of this problem space.  This is my opinion, not marching
 orders.  Everything is up for discussion.  This is what the current code
 is trying to do, though.  Also, important note:  The order of names in
>> the
 HTMLElement.className does not matter.  CSS style precedence is
>> determined
 by the order of declarations in the CSS file.  OK, lots of reading
>> ahead:
 
 HTML and JavaScript do not really have a first-class notion of a Class
 like we do in ActionScript.  IOW, no such thing as true subclassing,
 especially in a way that supports Reflection APIs like
 flash.utils.getQualifiedClassName.  So, there is a fixed set of types in
 the browser, such as Button, Input, Div (which, by the way, are
 implemented as instances of HTMLButtonElement, HTMLInputElement,
 HTMLDivElement and not just Button, Input, Div).  And thus, a fixed set
>> of
 Type Selectors in CSS.  You can't really make up new Type selectors,
>> AFAIK.
 
 A CSS Class selector is the way that you can distinguish one set of,
>> say,
 HTMLDivElements, from another set of HTMLDivElements.  Since you can't
 make subclasses and new type selectors, you set the HTML class or
 JavaScript HTMLElement.className/classList on individual HTML elements
>> and
 declare them to be of class "BigButton" or whatever.  It is their form
>> of
 subclassing.
 
 In Flex/Flash/SWF/ActionScript, folks are used to being able to make a
 subclass of Button called BigButton.  And add a Type Selector for it in
>> a
 CSS file as "BigButton {}" and not ".BigButton {}".  And the Flex/Royale
 compilers know that if you don't have a BigButton in the final output,
>> it
 doesn't output the CSS for BigButton, making your app smaller.  If you
>> use
 class selectors and ".BigButton" the Flex/Royale compilers do not search
 the code to see if some code sets className to "BigButton" and it really
 probably never can since you might have code that does:
 
 var kinds:Array ["Big", "Little", "Puny"];
 Foo.className = kinds[i] + "Button";
 
 So, IMO, in Royale we want to leverage ActionScript types and pretend to
 extend the Type Selectors subsystem in CSS.  I think we can't actually
 truly do it since the "*" selector will be masked by our fake Type
 Selectors, but it should be good enough, and it allows the compiler to
 prune CSS that isn't used.
 
 So, I think we want a convention where each class sets the "typename"
 property to itself if it wants to support a fake Type Selector. 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Harbs,

You simply suggesting to have several functions instead of one which
computes things?



On Mon, Feb 26, 2018, 20:21 Harbs  wrote:

> Yes. Very thorough explanation. Thanks.
>
> It seems to me like there should be functions for addClassName() and
> removeClassName() which would add and remove the classNames from a list.
> When the className is computed, the list should be concatenated to
> classNames (and possibly typeNames — although we might not need typeNames
> if there’s a general list). We might also want a clearClassNames() method
> to allow removal of “default” classNames for classes which have such a need.
>
> I do think we also need a className setter so classNames could be
> specified in mxml, but we might be able to do away with typeNames. That
> might simplify things.
>
> My $0.02,
> Harbs
>
>
> > On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki 
> wrote:
> >
> > Hi Alex,
> >
> > Great reading and explanation. My first thought was to have something
> which
> > computes className together, but currently it is needed for MDL only
> > almost. I went with this additional function Utility.
> > I think there won't be too much time when we will need such ability like
> > switching and adding shadow css classes etc.
> >
> > If other also think about such function I would be happy to implement it.
> > It will really get rid of a lot of dump code and even some workarounds in
> > MDL. Live would be much easier.
> >
> > +1 to have such functions.
> >
> > All of that should land on the Wiki or somewhere in the documentation.
> >
> > Waiting for thoughts from others.
> >
> > Thanks, Piotr
> >
> > 2018-02-26 18:50 GMT+01:00 Alex Harui :
> >
> >> Here's my view of this problem space.  This is my opinion, not marching
> >> orders.  Everything is up for discussion.  This is what the current code
> >> is trying to do, though.  Also, important note:  The order of names in
> the
> >> HTMLElement.className does not matter.  CSS style precedence is
> determined
> >> by the order of declarations in the CSS file.  OK, lots of reading
> ahead:
> >>
> >> HTML and JavaScript do not really have a first-class notion of a Class
> >> like we do in ActionScript.  IOW, no such thing as true subclassing,
> >> especially in a way that supports Reflection APIs like
> >> flash.utils.getQualifiedClassName.  So, there is a fixed set of types in
> >> the browser, such as Button, Input, Div (which, by the way, are
> >> implemented as instances of HTMLButtonElement, HTMLInputElement,
> >> HTMLDivElement and not just Button, Input, Div).  And thus, a fixed set
> of
> >> Type Selectors in CSS.  You can't really make up new Type selectors,
> AFAIK.
> >>
> >> A CSS Class selector is the way that you can distinguish one set of,
> say,
> >> HTMLDivElements, from another set of HTMLDivElements.  Since you can't
> >> make subclasses and new type selectors, you set the HTML class or
> >> JavaScript HTMLElement.className/classList on individual HTML elements
> and
> >> declare them to be of class "BigButton" or whatever.  It is their form
> of
> >> subclassing.
> >>
> >> In Flex/Flash/SWF/ActionScript, folks are used to being able to make a
> >> subclass of Button called BigButton.  And add a Type Selector for it in
> a
> >> CSS file as "BigButton {}" and not ".BigButton {}".  And the Flex/Royale
> >> compilers know that if you don't have a BigButton in the final output,
> it
> >> doesn't output the CSS for BigButton, making your app smaller.  If you
> use
> >> class selectors and ".BigButton" the Flex/Royale compilers do not search
> >> the code to see if some code sets className to "BigButton" and it really
> >> probably never can since you might have code that does:
> >>
> >> var kinds:Array ["Big", "Little", "Puny"];
> >> Foo.className = kinds[i] + "Button";
> >>
> >> So, IMO, in Royale we want to leverage ActionScript types and pretend to
> >> extend the Type Selectors subsystem in CSS.  I think we can't actually
> >> truly do it since the "*" selector will be masked by our fake Type
> >> Selectors, but it should be good enough, and it allows the compiler to
> >> prune CSS that isn't used.
> >>
> >> So, I think we want a convention where each class sets the "typename"
> >> property to itself if it wants to support a fake Type Selector.  I
> >> considered having the compiler auto-generate it but that isn't really
> PAYG
> >> for small lightweight subclasses that won't ever have a fake Type
> Selector.
> >>
> >> Now in Flex, and Royale's SimpleCSSValuesImpl for SWF, Type Selectors
> from
> >> ancestor classes apply to subclasses.  We did that because it was a pain
> >> to have to copy all of Label's Type Selector into a MultilineLabel Type
> >> Selector and that duplication made the CSS file bigger.  So we want to
> >> mimic that on the JS side as well.
> >>
> >> So to make all of that happen, any new "type" of component should set
> >> typeName to itself 

Re: TypeNames vs ClassName

[Harbs]

Yes. Very thorough explanation. Thanks.

It seems to me like there should be functions for addClassName() and 
removeClassName() which would add and remove the classNames from a list. When 
the className is computed, the list should be concatenated to classNames (and 
possibly typeNames — although we might not need typeNames if there’s a general 
list). We might also want a clearClassNames() method to allow removal of 
“default” classNames for classes which have such a need.

I do think we also need a className setter so classNames could be specified in 
mxml, but we might be able to do away with typeNames. That might simplify 
things.

My $0.02,
Harbs


> On Feb 26, 2018, at 8:09 PM, Piotr Zarzycki  wrote:
> 
> Hi Alex,
> 
> Great reading and explanation. My first thought was to have something which
> computes className together, but currently it is needed for MDL only
> almost. I went with this additional function Utility.
> I think there won't be too much time when we will need such ability like
> switching and adding shadow css classes etc.
> 
> If other also think about such function I would be happy to implement it.
> It will really get rid of a lot of dump code and even some workarounds in
> MDL. Live would be much easier.
> 
> +1 to have such functions.
> 
> All of that should land on the Wiki or somewhere in the documentation.
> 
> Waiting for thoughts from others.
> 
> Thanks, Piotr
> 
> 2018-02-26 18:50 GMT+01:00 Alex Harui :
> 
>> Here's my view of this problem space.  This is my opinion, not marching
>> orders.  Everything is up for discussion.  This is what the current code
>> is trying to do, though.  Also, important note:  The order of names in the
>> HTMLElement.className does not matter.  CSS style precedence is determined
>> by the order of declarations in the CSS file.  OK, lots of reading ahead:
>> 
>> HTML and JavaScript do not really have a first-class notion of a Class
>> like we do in ActionScript.  IOW, no such thing as true subclassing,
>> especially in a way that supports Reflection APIs like
>> flash.utils.getQualifiedClassName.  So, there is a fixed set of types in
>> the browser, such as Button, Input, Div (which, by the way, are
>> implemented as instances of HTMLButtonElement, HTMLInputElement,
>> HTMLDivElement and not just Button, Input, Div).  And thus, a fixed set of
>> Type Selectors in CSS.  You can't really make up new Type selectors, AFAIK.
>> 
>> A CSS Class selector is the way that you can distinguish one set of, say,
>> HTMLDivElements, from another set of HTMLDivElements.  Since you can't
>> make subclasses and new type selectors, you set the HTML class or
>> JavaScript HTMLElement.className/classList on individual HTML elements and
>> declare them to be of class "BigButton" or whatever.  It is their form of
>> subclassing.
>> 
>> In Flex/Flash/SWF/ActionScript, folks are used to being able to make a
>> subclass of Button called BigButton.  And add a Type Selector for it in a
>> CSS file as "BigButton {}" and not ".BigButton {}".  And the Flex/Royale
>> compilers know that if you don't have a BigButton in the final output, it
>> doesn't output the CSS for BigButton, making your app smaller.  If you use
>> class selectors and ".BigButton" the Flex/Royale compilers do not search
>> the code to see if some code sets className to "BigButton" and it really
>> probably never can since you might have code that does:
>> 
>> var kinds:Array ["Big", "Little", "Puny"];
>> Foo.className = kinds[i] + "Button";
>> 
>> So, IMO, in Royale we want to leverage ActionScript types and pretend to
>> extend the Type Selectors subsystem in CSS.  I think we can't actually
>> truly do it since the "*" selector will be masked by our fake Type
>> Selectors, but it should be good enough, and it allows the compiler to
>> prune CSS that isn't used.
>> 
>> So, I think we want a convention where each class sets the "typename"
>> property to itself if it wants to support a fake Type Selector.  I
>> considered having the compiler auto-generate it but that isn't really PAYG
>> for small lightweight subclasses that won't ever have a fake Type Selector.
>> 
>> Now in Flex, and Royale's SimpleCSSValuesImpl for SWF, Type Selectors from
>> ancestor classes apply to subclasses.  We did that because it was a pain
>> to have to copy all of Label's Type Selector into a MultilineLabel Type
>> Selector and that duplication made the CSS file bigger.  So we want to
>> mimic that on the JS side as well.
>> 
>> So to make all of that happen, any new "type" of component should set
>> typeName to itself somewhere.  So Button and DataGrid should just have
>> typeNames="Button" or typeNames="DataGrid".  But subclasses of these types
>> can append themselves, so MultilineLabel does: typenames+="
>> MultilineLabel".  That gets appended to Label's typeNames so the
>> MultilineLabel's final typenames is "Label MultilineLabel".
>> 
>> Recently, I proposed that the 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Hi Alex,

Great reading and explanation. My first thought was to have something which
computes className together, but currently it is needed for MDL only
almost. I went with this additional function Utility.
I think there won't be too much time when we will need such ability like
switching and adding shadow css classes etc.

If other also think about such function I would be happy to implement it.
It will really get rid of a lot of dump code and even some workarounds in
MDL. Live would be much easier.

+1 to have such functions.

All of that should land on the Wiki or somewhere in the documentation.

Waiting for thoughts from others.

Thanks, Piotr

2018-02-26 18:50 GMT+01:00 Alex Harui :

> Here's my view of this problem space.  This is my opinion, not marching
> orders.  Everything is up for discussion.  This is what the current code
> is trying to do, though.  Also, important note:  The order of names in the
> HTMLElement.className does not matter.  CSS style precedence is determined
> by the order of declarations in the CSS file.  OK, lots of reading ahead:
>
> HTML and JavaScript do not really have a first-class notion of a Class
> like we do in ActionScript.  IOW, no such thing as true subclassing,
> especially in a way that supports Reflection APIs like
> flash.utils.getQualifiedClassName.  So, there is a fixed set of types in
> the browser, such as Button, Input, Div (which, by the way, are
> implemented as instances of HTMLButtonElement, HTMLInputElement,
> HTMLDivElement and not just Button, Input, Div).  And thus, a fixed set of
> Type Selectors in CSS.  You can't really make up new Type selectors, AFAIK.
>
> A CSS Class selector is the way that you can distinguish one set of, say,
> HTMLDivElements, from another set of HTMLDivElements.  Since you can't
> make subclasses and new type selectors, you set the HTML class or
> JavaScript HTMLElement.className/classList on individual HTML elements and
> declare them to be of class "BigButton" or whatever.  It is their form of
> subclassing.
>
> In Flex/Flash/SWF/ActionScript, folks are used to being able to make a
> subclass of Button called BigButton.  And add a Type Selector for it in a
> CSS file as "BigButton {}" and not ".BigButton {}".  And the Flex/Royale
> compilers know that if you don't have a BigButton in the final output, it
> doesn't output the CSS for BigButton, making your app smaller.  If you use
> class selectors and ".BigButton" the Flex/Royale compilers do not search
> the code to see if some code sets className to "BigButton" and it really
> probably never can since you might have code that does:
>
> var kinds:Array ["Big", "Little", "Puny"];
> Foo.className = kinds[i] + "Button";
>
> So, IMO, in Royale we want to leverage ActionScript types and pretend to
> extend the Type Selectors subsystem in CSS.  I think we can't actually
> truly do it since the "*" selector will be masked by our fake Type
> Selectors, but it should be good enough, and it allows the compiler to
> prune CSS that isn't used.
>
> So, I think we want a convention where each class sets the "typename"
> property to itself if it wants to support a fake Type Selector.  I
> considered having the compiler auto-generate it but that isn't really PAYG
> for small lightweight subclasses that won't ever have a fake Type Selector.
>
> Now in Flex, and Royale's SimpleCSSValuesImpl for SWF, Type Selectors from
> ancestor classes apply to subclasses.  We did that because it was a pain
> to have to copy all of Label's Type Selector into a MultilineLabel Type
> Selector and that duplication made the CSS file bigger.  So we want to
> mimic that on the JS side as well.
>
> So to make all of that happen, any new "type" of component should set
> typeName to itself somewhere.  So Button and DataGrid should just have
> typeNames="Button" or typeNames="DataGrid".  But subclasses of these types
> can append themselves, so MultilineLabel does: typenames+="
> MultilineLabel".  That gets appended to Label's typeNames so the
> MultilineLabel's final typenames is "Label MultilineLabel".
>
> Recently, I proposed that the best place to allow appending of typeNames
> is in the constructor.  It makes appending easier (after the call to
> super()) and eliminates the need for simple subclasses to have to add a
> createElement call just to override typenames.
>
> And that's why I think typeNames should never be set from "outside" the
> class and maybe we should make it protected.  It is there to represent a
> new Type Name that folks can use to style EVERY instance of that type in
> their app without having to make up a new className and try to to miss
> setting that className on some MXML/HTML tag.  And similarly the code in a
> class should never set className on itself, because className should be
> reserved to be used by consumers of that component to further distinguish
> sets of instances of that component from other instances.
>
> And that's why, when we build 

Re: TypeNames vs ClassName

[Alex Harui]

Here's my view of this problem space.  This is my opinion, not marching
orders.  Everything is up for discussion.  This is what the current code
is trying to do, though.  Also, important note:  The order of names in the
HTMLElement.className does not matter.  CSS style precedence is determined
by the order of declarations in the CSS file.  OK, lots of reading ahead:

HTML and JavaScript do not really have a first-class notion of a Class
like we do in ActionScript.  IOW, no such thing as true subclassing,
especially in a way that supports Reflection APIs like
flash.utils.getQualifiedClassName.  So, there is a fixed set of types in
the browser, such as Button, Input, Div (which, by the way, are
implemented as instances of HTMLButtonElement, HTMLInputElement,
HTMLDivElement and not just Button, Input, Div).  And thus, a fixed set of
Type Selectors in CSS.  You can't really make up new Type selectors, AFAIK.

A CSS Class selector is the way that you can distinguish one set of, say,
HTMLDivElements, from another set of HTMLDivElements.  Since you can't
make subclasses and new type selectors, you set the HTML class or
JavaScript HTMLElement.className/classList on individual HTML elements and
declare them to be of class "BigButton" or whatever.  It is their form of
subclassing.

In Flex/Flash/SWF/ActionScript, folks are used to being able to make a
subclass of Button called BigButton.  And add a Type Selector for it in a
CSS file as "BigButton {}" and not ".BigButton {}".  And the Flex/Royale
compilers know that if you don't have a BigButton in the final output, it
doesn't output the CSS for BigButton, making your app smaller.  If you use
class selectors and ".BigButton" the Flex/Royale compilers do not search
the code to see if some code sets className to "BigButton" and it really
probably never can since you might have code that does:

var kinds:Array ["Big", "Little", "Puny"];
Foo.className = kinds[i] + "Button";

So, IMO, in Royale we want to leverage ActionScript types and pretend to
extend the Type Selectors subsystem in CSS.  I think we can't actually
truly do it since the "*" selector will be masked by our fake Type
Selectors, but it should be good enough, and it allows the compiler to
prune CSS that isn't used.

So, I think we want a convention where each class sets the "typename"
property to itself if it wants to support a fake Type Selector.  I
considered having the compiler auto-generate it but that isn't really PAYG
for small lightweight subclasses that won't ever have a fake Type Selector.

Now in Flex, and Royale's SimpleCSSValuesImpl for SWF, Type Selectors from
ancestor classes apply to subclasses.  We did that because it was a pain
to have to copy all of Label's Type Selector into a MultilineLabel Type
Selector and that duplication made the CSS file bigger.  So we want to
mimic that on the JS side as well.

So to make all of that happen, any new "type" of component should set
typeName to itself somewhere.  So Button and DataGrid should just have
typeNames="Button" or typeNames="DataGrid".  But subclasses of these types
can append themselves, so MultilineLabel does: typenames+="
MultilineLabel".  That gets appended to Label's typeNames so the
MultilineLabel's final typenames is "Label MultilineLabel".

Recently, I proposed that the best place to allow appending of typeNames
is in the constructor.  It makes appending easier (after the call to
super()) and eliminates the need for simple subclasses to have to add a
createElement call just to override typenames.

And that's why I think typeNames should never be set from "outside" the
class and maybe we should make it protected.  It is there to represent a
new Type Name that folks can use to style EVERY instance of that type in
their app without having to make up a new className and try to to miss
setting that className on some MXML/HTML tag.  And similarly the code in a
class should never set className on itself, because className should be
reserved to be used by consumers of that component to further distinguish
sets of instances of that component from other instances.

And that's why, when we build complex views, we might make an instance of
a TextInput in ComboBoxView and assign it a className.  We want to
distinguish that TextInput from other TextInputs in the users app or in
other views.  So we assign the TextInput in ComboBox a useful className
like ComboBoxTextInput.  We could take the time to actually subclass
TextInput and make a ComboBoxTextInput extends TextInput and then make a
new type selector available in the CSS.  That would be cleaner, but it has
a couple of disadvantages:  I think a subclass is more code than a CSS
class selector, and it clutters the documentation.  I did play around with
some convention to allow us to prune class selectors by somehow
associating them with a type, but I'm not sure there's a great answer
there.  But if you look in HelloWorld.css you'll see unused class
selectors in there.

There is no API to allow 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

I just pushed changes to MDL. With couple of exceptions all typeNames
landed to constructor. Thanks to that changes some components started to
work better. I'm wondering whether I do not break anything.

Harbs,

If you are using something more than MDL Dialog in your application it
would be great to get feedback whether I didn't break for you anything. :)

Thanks, Piotr

2018-02-24 17:53 GMT+01:00 Alex Harui :

> Sorry, I wasn't clear.  The function itself can go in Basic or better yet,
> Core, since I don't think it has any dependencies and can be use anywhere.
>  I was just saying that I would prefer if none of the Basic components or
> UIBase used your new function.  You should be able to write a Royale app
> with Basic and not bring in that function. Not that it isn't useful, but
> it isn't truly "basic" given that Basic components are supposed to have
> typeNames.
>
> My 2 cents,
> -Alex
>
> On 2/24/18, 8:17 AM, "Piotr Zarzycki"  wrote:
>
> >I was going to put it somewhere in the Basic, but I can leave it in the
> >MDL. The className can be undefined in the case where you wanted to add
> >something to such "undefinded" string you will got:
> >
> >"undefined myClass". - I probably cannot escape from that...
> >
> >Maybe I'm missing some way.
> >
> >2018-02-24 17:00 GMT+01:00 Alex Harui :
> >
> >> Looks ok to me.  Seems like you don't need COMPILE::JS.  It should work
> >>on
> >> all platforms.  We can have lots of utility functions in
> >> org.apache.royale.utils.
> >>
> >> In terms of optimization (size/performance) a function like this is
> >> potentially overkill for the Basic set.  It is fine for MDL since MDL
> >>has
> >> already picked up additional overhead in order to style "everything".
> >>But
> >> I subscribe to what I learned from a wise programmer many years ago:  If
> >> you truly understand the problem space, you can often find a smaller,
> >> faster solution.  Like I said, if you know that there "must" be at least
> >> one string from typenames as the last string, the replacement is much
> >> easier.  All of the extra null checking and trimming in your version is
> >> not really needed for the specific problem of replacing from a set of
> >> string you know about that don't need trimming.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 2/24/18, 4:50 AM, "Piotr Zarzycki" 
> wrote:
> >>
> >> >Alex,
> >> >
> >> >I used your suggestion, added some additional things and I end up with
> >> >following utility [1]. Usage will looks like that: [2]. Do you think it
> >> >could be part of the framework ? It's working nicely with MDL.
> >> >
> >> >[1]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.apa
> >> >che.org%2FtsaF=02%7C01%7Caharui%40adobe.com%
> >> 7C91e633a78bea4fc4c89908d
> >> >57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636550734524475642&
> >> >sdata=O%2BZn0ajlM6A2Q0tBEBvDDtZZcNQYNOBsCn1kO0fgdPo%3D=0
> >> >[2]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.apa
> >> >che.org%2Fxbfb=02%7C01%7Caharui%40adobe.com%
> >> 7C91e633a78bea4fc4c89908d
> >> >57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636550734524475642&
> >> >sdata=j0n83ksobPZfR0YY7oMBJMU1dzx7fcW%2FNOmLd1S%2BL0o%3D=0
> >> >
> >> >Thanks, Piotr
> >> >
> >> >
> >> >
> >> >2018-02-23 21:31 GMT+01:00 Alex Harui :
> >> >
> >> >> Well, whether you like it or not, the wrapper is mapping a
> >> >>space-delimited
> >> >> list to the array so if you manipulate the array you have to
> >> >> back-calculate the string.  IMO, in HTML, the "class" property is a
> >> >>string
> >> >> and people are used to entering a space-delimited list.  That's why
> >>we
> >> >> have a className property on UIBase.  So that folks have something
> >> >>similar
> >> >> in MXML.
> >> >>
> >> >> So, unfortunately, your problem can't be as simple as manipulating
> >> >> classList via its APIs.  Also consider that the classList API might
> >> >>itself
> >> >> be doing a string search in the array.
> >> >>
> >> >> If you have the string "Piotr Alex Harbs" and want to replace Alex
> >>with
> >> >> Peter and you know that Alex can't be the last item because the last
> >> >>item
> >> >> is the typeName which is never null or "", then a simple
> >>String.replace
> >> >> call should work.
> >> >>
> >> >>   className = className.replace(oldName + " ", newName + " ");
> >> >>
> >> >> HTH,
> >> >> -Alex
> >> >>
> >> >> On 2/23/18, 12:21 PM, "Piotr Zarzycki" 
> >> >>wrote:
> >> >>
> >> >> >It's just swapping. If I have following code [1] - it is easier to
> >> >> >manipulate classList than className which is simple string. What
> >> >>utility
> >> >> >could look like ? It would be manipulating strings, which is less
> >> >> >convenient.
> >> >> >
> >> >> >[1]
> >> >> 

Re: TypeNames vs ClassName

[Alex Harui]

Sorry, I wasn't clear.  The function itself can go in Basic or better yet,
Core, since I don't think it has any dependencies and can be use anywhere.
 I was just saying that I would prefer if none of the Basic components or
UIBase used your new function.  You should be able to write a Royale app
with Basic and not bring in that function. Not that it isn't useful, but
it isn't truly "basic" given that Basic components are supposed to have
typeNames.

My 2 cents,
-Alex

On 2/24/18, 8:17 AM, "Piotr Zarzycki"  wrote:

>I was going to put it somewhere in the Basic, but I can leave it in the
>MDL. The className can be undefined in the case where you wanted to add
>something to such "undefinded" string you will got:
>
>"undefined myClass". - I probably cannot escape from that...
>
>Maybe I'm missing some way.
>
>2018-02-24 17:00 GMT+01:00 Alex Harui :
>
>> Looks ok to me.  Seems like you don't need COMPILE::JS.  It should work
>>on
>> all platforms.  We can have lots of utility functions in
>> org.apache.royale.utils.
>>
>> In terms of optimization (size/performance) a function like this is
>> potentially overkill for the Basic set.  It is fine for MDL since MDL
>>has
>> already picked up additional overhead in order to style "everything".
>>But
>> I subscribe to what I learned from a wise programmer many years ago:  If
>> you truly understand the problem space, you can often find a smaller,
>> faster solution.  Like I said, if you know that there "must" be at least
>> one string from typenames as the last string, the replacement is much
>> easier.  All of the extra null checking and trimming in your version is
>> not really needed for the specific problem of replacing from a set of
>> string you know about that don't need trimming.
>>
>> My 2 cents,
>> -Alex
>>
>> On 2/24/18, 4:50 AM, "Piotr Zarzycki"  wrote:
>>
>> >Alex,
>> >
>> >I used your suggestion, added some additional things and I end up with
>> >following utility [1]. Usage will looks like that: [2]. Do you think it
>> >could be part of the framework ? It's working nicely with MDL.
>> >
>> >[1]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.apa
>> >che.org%2FtsaF=02%7C01%7Caharui%40adobe.com%
>> 7C91e633a78bea4fc4c89908d
>> >57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636550734524475642&
>> >sdata=O%2BZn0ajlM6A2Q0tBEBvDDtZZcNQYNOBsCn1kO0fgdPo%3D=0
>> >[2]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.apa
>> >che.org%2Fxbfb=02%7C01%7Caharui%40adobe.com%
>> 7C91e633a78bea4fc4c89908d
>> >57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636550734524475642&
>> >sdata=j0n83ksobPZfR0YY7oMBJMU1dzx7fcW%2FNOmLd1S%2BL0o%3D=0
>> >
>> >Thanks, Piotr
>> >
>> >
>> >
>> >2018-02-23 21:31 GMT+01:00 Alex Harui :
>> >
>> >> Well, whether you like it or not, the wrapper is mapping a
>> >>space-delimited
>> >> list to the array so if you manipulate the array you have to
>> >> back-calculate the string.  IMO, in HTML, the "class" property is a
>> >>string
>> >> and people are used to entering a space-delimited list.  That's why
>>we
>> >> have a className property on UIBase.  So that folks have something
>> >>similar
>> >> in MXML.
>> >>
>> >> So, unfortunately, your problem can't be as simple as manipulating
>> >> classList via its APIs.  Also consider that the classList API might
>> >>itself
>> >> be doing a string search in the array.
>> >>
>> >> If you have the string "Piotr Alex Harbs" and want to replace Alex
>>with
>> >> Peter and you know that Alex can't be the last item because the last
>> >>item
>> >> is the typeName which is never null or "", then a simple
>>String.replace
>> >> call should work.
>> >>
>> >>   className = className.replace(oldName + " ", newName + " ");
>> >>
>> >> HTH,
>> >> -Alex
>> >>
>> >> On 2/23/18, 12:21 PM, "Piotr Zarzycki" 
>> >>wrote:
>> >>
>> >> >It's just swapping. If I have following code [1] - it is easier to
>> >> >manipulate classList than className which is simple string. What
>> >>utility
>> >> >could look like ? It would be manipulating strings, which is less
>> >> >convenient.
>> >> >
>> >> >[1]
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> https%3A%2F%2Fpaste.apa
>> >> >che.org%2Fat0H=02%7C01%7Caharui%40adobe.com%
>> >> 7C061f7278ca3748bfaee408d
>> >> >57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636550141162759398&
>> >> >sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D=0
>> >> >
>> >> >2018-02-23 21:11 GMT+01:00 Alex Harui :
>> >> >
>> >> >> 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

Re: TypeNames vs ClassName

[Piotr Zarzycki]

I was going to put it somewhere in the Basic, but I can leave it in the
MDL. The className can be undefined in the case where you wanted to add
something to such "undefinded" string you will got:

"undefined myClass". - I probably cannot escape from that...

Maybe I'm missing some way.

2018-02-24 17:00 GMT+01:00 Alex Harui :

> Looks ok to me.  Seems like you don't need COMPILE::JS.  It should work on
> all platforms.  We can have lots of utility functions in
> org.apache.royale.utils.
>
> In terms of optimization (size/performance) a function like this is
> potentially overkill for the Basic set.  It is fine for MDL since MDL has
> already picked up additional overhead in order to style "everything".  But
> I subscribe to what I learned from a wise programmer many years ago:  If
> you truly understand the problem space, you can often find a smaller,
> faster solution.  Like I said, if you know that there "must" be at least
> one string from typenames as the last string, the replacement is much
> easier.  All of the extra null checking and trimming in your version is
> not really needed for the specific problem of replacing from a set of
> string you know about that don't need trimming.
>
> My 2 cents,
> -Alex
>
> On 2/24/18, 4:50 AM, "Piotr Zarzycki"  wrote:
>
> >Alex,
> >
> >I used your suggestion, added some additional things and I end up with
> >following utility [1]. Usage will looks like that: [2]. Do you think it
> >could be part of the framework ? It's working nicely with MDL.
> >
> >[1]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2FtsaF=02%7C01%7Caharui%40adobe.com%
> 7C91e633a78bea4fc4c89908d
> >57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636550734524475642&
> >sdata=O%2BZn0ajlM6A2Q0tBEBvDDtZZcNQYNOBsCn1kO0fgdPo%3D=0
> >[2]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2Fxbfb=02%7C01%7Caharui%40adobe.com%
> 7C91e633a78bea4fc4c89908d
> >57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636550734524475642&
> >sdata=j0n83ksobPZfR0YY7oMBJMU1dzx7fcW%2FNOmLd1S%2BL0o%3D=0
> >
> >Thanks, Piotr
> >
> >
> >
> >2018-02-23 21:31 GMT+01:00 Alex Harui :
> >
> >> Well, whether you like it or not, the wrapper is mapping a
> >>space-delimited
> >> list to the array so if you manipulate the array you have to
> >> back-calculate the string.  IMO, in HTML, the "class" property is a
> >>string
> >> and people are used to entering a space-delimited list.  That's why we
> >> have a className property on UIBase.  So that folks have something
> >>similar
> >> in MXML.
> >>
> >> So, unfortunately, your problem can't be as simple as manipulating
> >> classList via its APIs.  Also consider that the classList API might
> >>itself
> >> be doing a string search in the array.
> >>
> >> If you have the string "Piotr Alex Harbs" and want to replace Alex with
> >> Peter and you know that Alex can't be the last item because the last
> >>item
> >> is the typeName which is never null or "", then a simple String.replace
> >> call should work.
> >>
> >>   className = className.replace(oldName + " ", newName + " ");
> >>
> >> HTH,
> >> -Alex
> >>
> >> On 2/23/18, 12:21 PM, "Piotr Zarzycki" 
> >>wrote:
> >>
> >> >It's just swapping. If I have following code [1] - it is easier to
> >> >manipulate classList than className which is simple string. What
> >>utility
> >> >could look like ? It would be manipulating strings, which is less
> >> >convenient.
> >> >
> >> >[1]
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> https%3A%2F%2Fpaste.apa
> >> >che.org%2Fat0H=02%7C01%7Caharui%40adobe.com%
> >> 7C061f7278ca3748bfaee408d
> >> >57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636550141162759398&
> >> >sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D=0
> >> >
> >> >2018-02-23 21:11 GMT+01:00 Alex Harui :
> >> >
> >> >> 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" 
> >> >>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 

Re: TypeNames vs ClassName

[Alex Harui]

Looks ok to me.  Seems like you don't need COMPILE::JS.  It should work on
all platforms.  We can have lots of utility functions in
org.apache.royale.utils.

In terms of optimization (size/performance) a function like this is
potentially overkill for the Basic set.  It is fine for MDL since MDL has
already picked up additional overhead in order to style "everything".  But
I subscribe to what I learned from a wise programmer many years ago:  If
you truly understand the problem space, you can often find a smaller,
faster solution.  Like I said, if you know that there "must" be at least
one string from typenames as the last string, the replacement is much
easier.  All of the extra null checking and trimming in your version is
not really needed for the specific problem of replacing from a set of
string you know about that don't need trimming.

My 2 cents,
-Alex

On 2/24/18, 4:50 AM, "Piotr Zarzycki"  wrote:

>Alex,
>
>I used your suggestion, added some additional things and I end up with
>following utility [1]. Usage will looks like that: [2]. Do you think it
>could be part of the framework ? It's working nicely with MDL.
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2FtsaF=02%7C01%7Caharui%40adobe.com%7C91e633a78bea4fc4c89908d
>57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636550734524475642&
>sdata=O%2BZn0ajlM6A2Q0tBEBvDDtZZcNQYNOBsCn1kO0fgdPo%3D=0
>[2] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2Fxbfb=02%7C01%7Caharui%40adobe.com%7C91e633a78bea4fc4c89908d
>57b853bdf%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636550734524475642&
>sdata=j0n83ksobPZfR0YY7oMBJMU1dzx7fcW%2FNOmLd1S%2BL0o%3D=0
>
>Thanks, Piotr
>
>
>
>2018-02-23 21:31 GMT+01:00 Alex Harui :
>
>> Well, whether you like it or not, the wrapper is mapping a
>>space-delimited
>> list to the array so if you manipulate the array you have to
>> back-calculate the string.  IMO, in HTML, the "class" property is a
>>string
>> and people are used to entering a space-delimited list.  That's why we
>> have a className property on UIBase.  So that folks have something
>>similar
>> in MXML.
>>
>> So, unfortunately, your problem can't be as simple as manipulating
>> classList via its APIs.  Also consider that the classList API might
>>itself
>> be doing a string search in the array.
>>
>> If you have the string "Piotr Alex Harbs" and want to replace Alex with
>> Peter and you know that Alex can't be the last item because the last
>>item
>> is the typeName which is never null or "", then a simple String.replace
>> call should work.
>>
>>   className = className.replace(oldName + " ", newName + " ");
>>
>> HTH,
>> -Alex
>>
>> On 2/23/18, 12:21 PM, "Piotr Zarzycki" 
>>wrote:
>>
>> >It's just swapping. If I have following code [1] - it is easier to
>> >manipulate classList than className which is simple string. What
>>utility
>> >could look like ? It would be manipulating strings, which is less
>> >convenient.
>> >
>> >[1]
>> >https://na01.safelinks.protection.outlook.com/?url=
>> https%3A%2F%2Fpaste.apa
>> >che.org%2Fat0H=02%7C01%7Caharui%40adobe.com%
>> 7C061f7278ca3748bfaee408d
>> >57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636550141162759398&
>> >sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D=0
>> >
>> >2018-02-23 21:11 GMT+01:00 Alex Harui :
>> >
>> >> 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" 
>> >>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=02%7C01%7Caharui%40adobe.com%
>> >> 7C8e313e7d7f9d4608759f08d
>> >> >57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636550127203173382&
>> >> >sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%3D=0
>> >> >
>> >> >Thanks,
>> >> >Piotr
>> >> >
>> >> >2018-02-23 20:53 GMT+01:00 Alex Harui :
>> >> >
>> >> >> I think I have 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Alex,

I used your suggestion, added some additional things and I end up with
following utility [1]. Usage will looks like that: [2]. Do you think it
could be part of the framework ? It's working nicely with MDL.

[1] https://paste.apache.org/tsaF
[2] https://paste.apache.org/xbfb

Thanks, Piotr



2018-02-23 21:31 GMT+01:00 Alex Harui :

> Well, whether you like it or not, the wrapper is mapping a space-delimited
> list to the array so if you manipulate the array you have to
> back-calculate the string.  IMO, in HTML, the "class" property is a string
> and people are used to entering a space-delimited list.  That's why we
> have a className property on UIBase.  So that folks have something similar
> in MXML.
>
> So, unfortunately, your problem can't be as simple as manipulating
> classList via its APIs.  Also consider that the classList API might itself
> be doing a string search in the array.
>
> If you have the string "Piotr Alex Harbs" and want to replace Alex with
> Peter and you know that Alex can't be the last item because the last item
> is the typeName which is never null or "", then a simple String.replace
> call should work.
>
>   className = className.replace(oldName + " ", newName + " ");
>
> HTH,
> -Alex
>
> On 2/23/18, 12:21 PM, "Piotr Zarzycki"  wrote:
>
> >It's just swapping. If I have following code [1] - it is easier to
> >manipulate classList than className which is simple string. What utility
> >could look like ? It would be manipulating strings, which is less
> >convenient.
> >
> >[1]
> >https://na01.safelinks.protection.outlook.com/?url=
> https%3A%2F%2Fpaste.apa
> >che.org%2Fat0H=02%7C01%7Caharui%40adobe.com%
> 7C061f7278ca3748bfaee408d
> >57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636550141162759398&
> >sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D=0
> >
> >2018-02-23 21:11 GMT+01:00 Alex Harui :
> >
> >> 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" 
> >>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=02%7C01%7Caharui%40adobe.com%
> >> 7C8e313e7d7f9d4608759f08d
> >> >57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636550127203173382&
> >> >sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%3D=0
> >> >
> >> >Thanks,
> >> >Piotr
> >> >
> >> >2018-02-23 20:53 GMT+01:00 Alex Harui :
> >> >
> >> >> 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"  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 

Re: TypeNames vs ClassName

[Alex Harui]

Well, whether you like it or not, the wrapper is mapping a space-delimited
list to the array so if you manipulate the array you have to
back-calculate the string.  IMO, in HTML, the "class" property is a string
and people are used to entering a space-delimited list.  That's why we
have a className property on UIBase.  So that folks have something similar
in MXML.

So, unfortunately, your problem can't be as simple as manipulating
classList via its APIs.  Also consider that the classList API might itself
be doing a string search in the array.

If you have the string "Piotr Alex Harbs" and want to replace Alex with
Peter and you know that Alex can't be the last item because the last item
is the typeName which is never null or "", then a simple String.replace
call should work.

  className = className.replace(oldName + " ", newName + " ");

HTH,
-Alex

On 2/23/18, 12:21 PM, "Piotr Zarzycki"  wrote:

>It's just swapping. If I have following code [1] - it is easier to
>manipulate classList than className which is simple string. What utility
>could look like ? It would be manipulating strings, which is less
>convenient.
>
>[1] 
>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.apa
>che.org%2Fat0H=02%7C01%7Caharui%40adobe.com%7C061f7278ca3748bfaee408d
>57afb14a9%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636550141162759398&
>sdata=76W6lkZuIxUbO5mDtenl4g88zmRPsHaA1evyvvk7O08%3D=0
>
>2018-02-23 21:11 GMT+01:00 Alex Harui :
>
>> 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" 
>>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=02%7C01%7Caharui%40adobe.com%
>> 7C8e313e7d7f9d4608759f08d
>> >57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636550127203173382&
>> >sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%3D=0
>> >
>> >Thanks,
>> >Piotr
>> >
>> >2018-02-23 20:53 GMT+01:00 Alex Harui :
>> >
>> >> 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"  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 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

It's just swapping. If I have following code [1] - it is easier to
manipulate classList than className which is simple string. What utility
could look like ? It would be manipulating strings, which is less
convenient.

[1] https://paste.apache.org/at0H

2018-02-23 21:11 GMT+01:00 Alex Harui :

> 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"  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=02%7C01%7Caharui%40adobe.com%
> 7C8e313e7d7f9d4608759f08d
> >57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636550127203173382&
> >sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%3D=0
> >
> >Thanks,
> >Piotr
> >
> >2018-02-23 20:53 GMT+01:00 Alex Harui :
> >
> >> 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"  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" 
> >>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
> 

Re: TypeNames vs ClassName

[Alex Harui]

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"  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=02%7C01%7Caharui%40adobe.com%7C8e313e7d7f9d4608759f08d
>57af7d477%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636550127203173382&
>sdata=NkxHZQlHtOeJzWC%2BIyxxst89DlX0CCUa9VeGpztTL2s%3D=0
>
>Thanks,
>Piotr
>
>2018-02-23 20:53 GMT+01:00 Alex Harui :
>
>> 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"  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" 
>>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 :
>> >>
>> >>> Alex,
>> >>>
>> >>> I have started to work on MDL and move all typeNames from
>>createElement
>> >>>to
>> >>> constructor. Unfortunately something is not right here.

Re: TypeNames vs ClassName

[Piotr Zarzycki]

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://paste.apache.org/1dy2

Thanks,
Piotr

2018-02-23 20:53 GMT+01:00 Alex Harui :

> 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"  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"  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 :
> >>
> >>> 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=02%7C01%7Caharui%40adobe.com%
> 7Ca44c142f0ddc455c70bf
> >>>0
> 

Re: TypeNames vs ClassName

[Alex Harui]

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"  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"  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 :
>>
>>> 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=02%7C01%7Caharui%40adobe.com%7Ca44c142f0ddc455c70bf
>>>0
>>>8d57ad361e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636549970664822
>>>4
>>>53=1sSgdfBy%2BAv%2FsFIYwVFFHvVlhtJ3w3TW%2FiDEyPVYGmo%3D=0
>>>
>>> Thanks,
>>> Piotr
>>>
>>>
>>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :
>>>
 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  wrote:

> I have been guilty of this and have been using 

Re: TypeNames vs ClassName

[Carlos Rovira]

Ok, maybe I had problems in the past due to what you say. Hope this changes
remove that problems too

thanks

2018-02-23 19:29 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> I think we've separated out basic.css and stopped misusing "className" in
> the Basic components so typeNames should work as expected in subclasses
> like MDL and possibly even Vivid.
>
> Piotr might as well finish up MDL so we can see if there might be issues
> that affect Vivid.
>
> My 2 cents,
> -Alex
>
> On 2/23/18, 10:21 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >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 :
> >
> >> 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 
> wrote:
> >>
> >> >
> >> >
> >> > On 2/23/18, 8:50 AM, "Piotr Zarzycki" 
> >>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 
> >> 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" 
> >> > wrote:
> >> > >>
> >> > >> >Reading what you are saying here regarding classList and
> 

Re: TypeNames vs ClassName

[Alex Harui]

Hi Carlos,

I think we've separated out basic.css and stopped misusing "className" in
the Basic components so typeNames should work as expected in subclasses
like MDL and possibly even Vivid.

Piotr might as well finish up MDL so we can see if there might be issues
that affect Vivid.

My 2 cents,
-Alex

On 2/23/18, 10:21 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>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 :
>
>> 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  wrote:
>>
>> >
>> >
>> > On 2/23/18, 8:50 AM, "Piotr Zarzycki" 
>>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 
>> 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" 
>> > 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 
>> > >>wrote:
>> > >> >
>> > >> >>
>> > >> >>
>> > >> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki"
>>
>> > >> wrote:

Re: TypeNames vs ClassName

[Carlos Rovira]

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 :

> 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  wrote:
>
> >
> >
> > On 2/23/18, 8:50 AM, "Piotr Zarzycki"  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 
> 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" 
> > 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 
> > >>wrote:
> > >> >
> > >> >>
> > >> >>
> > >> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki" 
> > >> 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 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

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  wrote:

>
>
> On 2/23/18, 8:50 AM, "Piotr Zarzycki"  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  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" 
> 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 
> >>wrote:
> >> >
> >> >>
> >> >>
> >> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki" 
> >> 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 

Re: TypeNames vs ClassName

[Alex Harui]

On 2/23/18, 8:50 AM, "Piotr Zarzycki"  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  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"  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 
>>wrote:
>> >
>> >>
>> >>
>> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki" 
>> 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
>> >> 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

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?


On Fri, Feb 23, 2018, 17:26 Alex Harui  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"  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  wrote:
> >
> >>
> >>
> >> On 2/23/18, 7:32 AM, "Piotr Zarzycki" 
> 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=02%7C01%7Caharui%40adobe.com
> >> %7C55b6f3b3cb1b40e46bf108d
> >>
> >>>57ad2b6df%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63654996780581082
> >>>9&
> >> >sdata=i9EZFYDPNqo4lakPPe1lB0NDfajXmqhMnDX7bxiBecc%3D=0
> >> >
> >> >Thanks,
> >> >Piotr
> >> >
> >> >
> >> >2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :
> >> >
> >> >> 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 
> 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
> >> >>> 

Re: TypeNames vs ClassName

[Alex Harui]

I'm not sure what you put in the theme for MDL.  But it shouldn't matter
whether it is in a theme or in MDL's defaults.css since nobody in
MDLTabsExample is trying to override it.  MDL only needs its own theme if
someone will want to use the structural aspects of the MDL components (the
layouts and views described by style properties that have ClassReference)
but give it a new look.

That might be a reasonable task to try some day.  We've seen that
virtually all popular themes like MDL and Bootstrap and even Vivid have
created the same structure for a Checkbox in order to fully style it, so
we could get rid of Flat.swc and MDL.swc and have a single
"HighlyStyleable.swc" that has a defaults.css that describes that
structure and move all styling into themes.css files.

My 2 cents,
-Alex

On 2/23/18, 8:09 AM, "Piotr Zarzycki"  wrote:

>I have added separate theme for MDL - didn't touch basic.css at all. I did
>add it as an
>-theme=path -
>this doesn't change anything in Basic module.
>
>On Fri, Feb 23, 2018, 17:05 Piotr Zarzycki 
>wrote:
>
>> I think I see where the issue may be, but not sure if it is an issue. I
>> have created separate project where I have only MDL Card component. I'm
>> setting property shardow = "2" [1]. This property is being called, but I
>> don't have line with typeNames - it's deleted.
>>
>> What is happen:
>>
>> 1) Constructor is setup class typeNames="mdl-card" - OK
>> 2) Property shadow is being called - it's adding to
>>classList.add(mdl-shadow--2-dp")
>> css class.
>> 3) addedToParent being called. It's removed everything what is inside
>> classList and replace it with "mdl-card"
>> - Should it work like that ?
>>
>> That is why I'm observing such a mess up after moving all typeNames to
>> constructor.
>>
>> [1] 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpaste.ap
>>ache.org%2Fat0H=02%7C01%7Caharui%40adobe.com%7Cb84805db33a645fee6980
>>8d57ad7eb17%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365499901373597
>>73=JbujMT12ZHgIWBHWRA84hLUUT4gzQ%2FKnPQF1%2B%2B31d%2FY%3D=
>>0
>>
>> Thanks, Piotr
>>
>> 2018-02-23 16:37 GMT+01:00 Piotr Zarzycki :
>>
>>> 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 :
>>>
 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.
apache.org%2Fat0H=02%7C01%7Caharui%40adobe.com%7Cb84805db33a645fee
69808d57ad7eb17%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365499901
37359773=JbujMT12ZHgIWBHWRA84hLUUT4gzQ%2FKnPQF1%2B%2B31d%2FY%3D
eserved=0

 Thanks,
 Piotr


 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :

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

Re: TypeNames vs ClassName

[Piotr Zarzycki]

I have added separate theme for MDL - didn't touch basic.css at all. I did
add it as an
-theme=path -
this doesn't change anything in Basic module.

On Fri, Feb 23, 2018, 17:05 Piotr Zarzycki 
wrote:

> I think I see where the issue may be, but not sure if it is an issue. I
> have created separate project where I have only MDL Card component. I'm
> setting property shardow = "2" [1]. This property is being called, but I
> don't have line with typeNames - it's deleted.
>
> What is happen:
>
> 1) Constructor is setup class typeNames="mdl-card" - OK
> 2) Property shadow is being called - it's adding to 
> classList.add(mdl-shadow--2-dp")
> css class.
> 3) addedToParent being called. It's removed everything what is inside
> classList and replace it with "mdl-card"
> - Should it work like that ?
>
> That is why I'm observing such a mess up after moving all typeNames to
> constructor.
>
> [1] https://paste.apache.org/at0H
>
> Thanks, Piotr
>
> 2018-02-23 16:37 GMT+01:00 Piotr Zarzycki :
>
>> 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 :
>>
>>> 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://paste.apache.org/at0H
>>>
>>> Thanks,
>>> Piotr
>>>
>>>
>>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :
>>>
 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  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"  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 
> wrote:
> >>
> >> I¹ll help.
> >>
> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui  >
> >>>wrote:
> >>>
> >>> Quick note before I shut down for the night.

Re: TypeNames vs ClassName

[Piotr Zarzycki]

I think I see where the issue may be, but not sure if it is an issue. I
have created separate project where I have only MDL Card component. I'm
setting property shardow = "2" [1]. This property is being called, but I
don't have line with typeNames - it's deleted.

What is happen:

1) Constructor is setup class typeNames="mdl-card" - OK
2) Property shadow is being called - it's adding to
classList.add(mdl-shadow--2-dp")
css class.
3) addedToParent being called. It's removed everything what is inside
classList and replace it with "mdl-card"
- Should it work like that ?

That is why I'm observing such a mess up after moving all typeNames to
constructor.

[1] https://paste.apache.org/at0H

Thanks, Piotr

2018-02-23 16:37 GMT+01:00 Piotr Zarzycki :

> 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 :
>
>> 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://paste.apache.org/at0H
>>
>> Thanks,
>> Piotr
>>
>>
>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :
>>
>>> 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  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"  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 
 wrote:
 >>
 >> I¹ll help.
 >>
 >>> On Feb 23, 2018, at 10:50 AM, Alex Harui 
 >>>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 

Re: TypeNames vs ClassName

[Alex Harui]

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"  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 :
>
>> 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.ap
>>ache.org%2Fat0H=02%7C01%7Caharui%40adobe.com%7Ca44c142f0ddc455c70bf0
>>8d57ad361e6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365499706648224
>>53=1sSgdfBy%2BAv%2FsFIYwVFFHvVlhtJ3w3TW%2FiDEyPVYGmo%3D=0
>>
>> Thanks,
>> Piotr
>>
>>
>> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :
>>
>>> 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  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 { 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

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 :

> 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://paste.apache.org/at0H
>
> Thanks,
> Piotr
>
>
> 2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :
>
>> 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  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"  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 
>>> wrote:
>>> >>
>>> >> I¹ll help.
>>> >>
>>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui 
>>> >>>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://www.patreon.com/piotrzarzycki
> *
>



-- 

Piotr Zarzycki

Patreon: *https://www.patreon.com/piotrzarzycki
*

Re: TypeNames vs ClassName

[Piotr Zarzycki]

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://paste.apache.org/at0H

Thanks,
Piotr


2018-02-23 15:55 GMT+01:00 Piotr Zarzycki :

> 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  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"  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 
>> wrote:
>> >>
>> >> I¹ll help.
>> >>
>> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui 
>> >>>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://www.patreon.com/piotrzarzycki
*

Re: TypeNames vs ClassName

[Piotr Zarzycki]

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  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"  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  wrote:
> >>
> >> I¹ll help.
> >>
> >>> On Feb 23, 2018, at 10:50 AM, Alex Harui 
> >>>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
> >>>
> >>
> >
>
>

Re: TypeNames vs ClassName

[Peter Ent]

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"  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  wrote:
>> 
>> I¹ll help.
>> 
>>> On Feb 23, 2018, at 10:50 AM, Alex Harui 
>>>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
>>> 
>> 
>

Re: TypeNames vs ClassName

[Gabe Harbs]

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  wrote:
> 
> I’ll help.
> 
>> On Feb 23, 2018, at 10:50 AM, Alex Harui  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
>> 
> 

Re: TypeNames vs ClassName

[Gabe Harbs]

I’ll help.

> On Feb 23, 2018, at 10:50 AM, Alex Harui  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
> 

Re: TypeNames vs ClassName

[Piotr Zarzycki]

Alex,

I will look into the MDL.

Thanks, Piotr

2018-02-23 9:50 GMT+01:00 Alex Harui :

> 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://www.patreon.com/piotrzarzycki
*