Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Alex,

2018-03-14 18:42 GMT+01:00 Alex Harui :

> Sounds like we are mostly in agreement.  I've clipped everything we've
> agreed to out of the reply below.
>
> On 3/14/18, 9:41 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >
> >
> >> C) In MDL and Jewel, computeFInalClassNames is overridden to also
> >>combine
> >> any special properties like "fab" and "primary"
> >>
> >If we can I prefer not to need overrides
>
> Overrides are PAYG as the subclass that needs it implements the extra code.
>

Right, what I want to express is that this method is like some kind of
"commitProperties" or "updateDisplayList"
or in Royale "createElement". It's great that we have here all the logic a
component should do to manage the
styles in the component, but I don't want to be obligated to override this
method I only need to toggle a style
(i.e : fab or primary cases). In those cases I only want to do
"toggleStyle()" or in other case "addStyle"
or "removeStyle". if we have the proper API in UIBase


> >
> >> D) Setters for special properties like "fab" check for (parent != null)
> >> and if parented, can call element.classList.toggle
> >>
> >here to adhere to what you propose, we should have :
> >1) or a composed class that hides implementation (className or classList)
> >2) use className if you want but give APIs to add/remove/...
>
> IMO, className in UIBase (and Royale in general) should look to the app
> dev like HTML className.  A simple set of space-delimited strings.  What
> we do in UIBase under the covers is the infrastructure we need (adding
> typeNames, maybe other strings for "fab").  I believe many apps can be
> built with simple use of className, so all add/remove support should be
> external and not baked in.
>

ok, that would be great, but I don't know how to do this in a simple way.
If we don't introduce some new methods in UIBase, we need to extend it, and
we end with
a class that is not between UIBase and the rest of components. The other
way is compose
a simple functionality for basic apps and advanced functionality, but again
we need to proxy with
UIBase methods like addStyle/removeStyle/toggleStyle, that calls the method
in a Impl or another
depending on what the user has configured


> >
> >>
> >>   For PAYG, documentation, cross-platform,
> >> and MXML reasons, I would prefer that we do not make classList a
> >>property
> >> on UIBase.
> >
> >If we use a pluggable implementation, this is possible, if not, don't know
> >how to do it in the same UIBase class
>
> Besides "pluggable" which implies beads, the utility functions don't plug
> in anywhere but are PAYG.  UIBase.element is public, so utility functions
> can directly access UIBase.element.classList.  So instead of add/remove in
> UIBase, I think the add would just look like:
>
> Package org.apache.royale.utils.className
> {
>   Public function addClassName(name:String, component:IUIBase):void
>   {
> COMPILE::JS
> component.element.classList.add(name);
>   }
> }
>

For me that's ok, is like the "addStyle" I named before (I choose addStyle
over addClassName since
it seems more near to what the user does, add a css rule style, while
classnames always seems to me
that introduces some confusion with OOP languages like AS3, since seems to
refer to classes as the definition
of an object

Anyway, that would be great, and is what I wanted and think that our users
need: An API in UIBase to deal
with styles since is maybe one of the main things people will do. Or at
least is 90% of what I do when subclassing
a Basic component since the rest of the "logic" is already done and
working. So change HTML structure and add styling
is the main point of extension, hence is natural to have that methods
aggregated in UIBase

If you want I can try it in my extension this concept and upload to my
branch so you can take a look

Thanks


>
> Thoughts?
> -Alex
>
>


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

Re: Experiment with UIBase change to classList

[Alex Harui]

Sounds like we are mostly in agreement.  I've clipped everything we've
agreed to out of the reply below.

On 3/14/18, 9:41 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>
>
>> C) In MDL and Jewel, computeFInalClassNames is overridden to also
>>combine
>> any special properties like "fab" and "primary"
>>
>If we can I prefer not to need overrides

Overrides are PAYG as the subclass that needs it implements the extra code.
>
>> D) Setters for special properties like "fab" check for (parent != null)
>> and if parented, can call element.classList.toggle
>>
>here to adhere to what you propose, we should have :
>1) or a composed class that hides implementation (className or classList)
>2) use className if you want but give APIs to add/remove/...

IMO, className in UIBase (and Royale in general) should look to the app
dev like HTML className.  A simple set of space-delimited strings.  What
we do in UIBase under the covers is the infrastructure we need (adding
typeNames, maybe other strings for "fab").  I believe many apps can be
built with simple use of className, so all add/remove support should be
external and not baked in.
>
>>
>>   For PAYG, documentation, cross-platform,
>> and MXML reasons, I would prefer that we do not make classList a
>>property
>> on UIBase.
>
>If we use a pluggable implementation, this is possible, if not, don't know
>how to do it in the same UIBase class

Besides "pluggable" which implies beads, the utility functions don't plug
in anywhere but are PAYG.  UIBase.element is public, so utility functions
can directly access UIBase.element.classList.  So instead of add/remove in
UIBase, I think the add would just look like:

Package org.apache.royale.utils.className
{
  Public function addClassName(name:String, component:IUIBase):void
  {
COMPILE::JS
component.element.classList.add(name);
  }
}

Thoughts?
-Alex

Re: Experiment with UIBase change to classList

[Alex Harui]

Hi Carlos, 

I think you still are not understanding the concerns being raised.  I
think the two most important right now are:

1) I do not wish to force any of our users (application developers) to use
classList instead of className.  ClassName is much easier to use in MXML
and there are probably lots of examples on the internet that use it.  So I
think any proposal, even for Jewel, should allow for straightforward
expected use of className yet still allow classList.  classList should be
optional.  Resetting with "" is not a viable pattern, IMO.
2) The performance advantage of classList is potentially being negated by
your proposed implementation.  The article and video you linked to only
show that if you have certain kinds of changes to be made to a list of
classes, that classList is faster, but the proposed implementation is
modifying the classList multiple times instead of just once.

Based on the above, I propose the following:

A) "typenames" is a var and aggregated in the constructor
B) In addedToParent(), computeFinalClassNames is called to combine
className and typeNames
C) In MDL and Jewel, computeFInalClassNames is overridden to also combine
any special properties like "fab" and "primary"
D) Setters for special properties like "fab" check for (parent != null)
and if parented, can call element.classList.toggle
E) We create utility functions like "addToClassName",
"removeFromClassName" that directly call element.classList.add and
element.classList.remove in their JS implementations.

If someone wants to test whether computeFinalClassNames should
String.split the list and use classList.add instead, that's would be great.

HTMLElement still supports both className and classList,   Nobody should
be favoring one or the other.  For PAYG, documentation, cross-platform,
and MXML reasons, I would prefer that we do not make classList a property
on UIBase.  But we can add utility functions that provide the most
efficient way of adding or removing chunks of styles to a component.
Remember that we are trying to abstract away platform APIs.

Can we all agree to that?

Thanks,
-Alex

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

>Hi Piotr,
>
>no. that's what Alex ask me, not what I propose...¿?
>I said the simple solution in my email (1 line), please re-read
>
>after one day of giving you lots of evidence you don't respond me...but in
>this case, you read the inverse and respond.
>Piotr, at this point I see clear that you like the className option over
>classList, although I give performance reports, and all can be workout to
>your like. If you don't like many .dots, we can abstract in a UIBase
>direct
>method. All can be done. But I need less negativity in something that I'm
>convinced after some days to work with that's the right way to go, at
>least
>in Jewel. In Basic, I don't mind if this goes with classNames. I read and
>respond all emails about the cons from Harbs, and I almost didn't see any
>real problem but preferences on how to proceed, what is normal, since any
>of us has its own way to see things and how to solve them, but I didn't
>see
>any real problem with classList, what seems normal to me since is an API
>that others out there are wanting to use (like the link I posted about
>Jquery). Don't know what more I can do. Maybe nothing since I see each one
>has its own vision and I can't convince you more and give you more valid
>arguments and evidences.
>
>I'm with Alex position to fix number calls to classList, I think I can
>reach half way what is proposing by my side, and then he can let me know
>what's the rest of the way if there's one.
>
>
>
>
>
>
>2018-03-14 8:23 GMT+01:00 Piotr Zarzycki :
>
>> Carlos,
>>
>> You can do, but I will use className to manipulate things instead taking
>> component.element.classList.remove <- To many dots. Previous way doesn't
>> require from me as a user cleaning anything.  I can tell you from the
>> perspective me as a user who already had an opportunity to write
>>production
>> application, that I will use className instead add/remove anything.
>>
>> Are you saying that now I have to do ?
>>
>> myComp.className = "Carlos Piotr Alex";
>> myComp.className = "";
>> myComp.className = "Carlos Alex";
>>
>> It looks like we won't convince you to just use UIBase as is today, so
>>go
>> ahead and implement as you wanted in the Jewel.
>>
>> Btw. In the old way once your component is created no one prevent you
>>use
>> component.element.classList add/remove/toggle - It will work once
>>component
>> is created - This is important.
>>
>> Thanks,
>> Piotr
>>
>>
>>
>> 2018-03-14 7:44 GMT+01:00 Carlos Rovira :
>>
>> > Hi Alex,
>> >
>> > to recete the classList you can do className = "" and reenter
>>typeNames
>> and
>> > classNames
>> > I think is the only way, then you can continue doing add/remove/toggle
>> > though 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Piotr,

no. that's what Alex ask me, not what I propose...¿?
I said the simple solution in my email (1 line), please re-read

after one day of giving you lots of evidence you don't respond me...but in
this case, you read the inverse and respond.
Piotr, at this point I see clear that you like the className option over
classList, although I give performance reports, and all can be workout to
your like. If you don't like many .dots, we can abstract in a UIBase direct
method. All can be done. But I need less negativity in something that I'm
convinced after some days to work with that's the right way to go, at least
in Jewel. In Basic, I don't mind if this goes with classNames. I read and
respond all emails about the cons from Harbs, and I almost didn't see any
real problem but preferences on how to proceed, what is normal, since any
of us has its own way to see things and how to solve them, but I didn't see
any real problem with classList, what seems normal to me since is an API
that others out there are wanting to use (like the link I posted about
Jquery). Don't know what more I can do. Maybe nothing since I see each one
has its own vision and I can't convince you more and give you more valid
arguments and evidences.

I'm with Alex position to fix number calls to classList, I think I can
reach half way what is proposing by my side, and then he can let me know
what's the rest of the way if there's one.






2018-03-14 8:23 GMT+01:00 Piotr Zarzycki :

> Carlos,
>
> You can do, but I will use className to manipulate things instead taking
> component.element.classList.remove <- To many dots. Previous way doesn't
> require from me as a user cleaning anything.  I can tell you from the
> perspective me as a user who already had an opportunity to write production
> application, that I will use className instead add/remove anything.
>
> Are you saying that now I have to do ?
>
> myComp.className = "Carlos Piotr Alex";
> myComp.className = "";
> myComp.className = "Carlos Alex";
>
> It looks like we won't convince you to just use UIBase as is today, so go
> ahead and implement as you wanted in the Jewel.
>
> Btw. In the old way once your component is created no one prevent you use
> component.element.classList add/remove/toggle - It will work once component
> is created - This is important.
>
> Thanks,
> Piotr
>
>
>
> 2018-03-14 7:44 GMT+01:00 Carlos Rovira :
>
> > Hi Alex,
> >
> > to recete the classList you can do className = "" and reenter typeNames
> and
> > classNames
> > I think is the only way, then you can continue doing add/remove/toggle
> > though classList.
> >
> > In your example you're still thinking in className mode, you can do
> easily
> > with classList.remove('Piotr'')
> >
> >
> >
> >
> >
> > 2018-03-14 0:07 GMT+01:00 Alex Harui :
> >
> > >
> > >
> > > On 3/13/18, 3:16 PM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira"
> > >  wrote:
> > >
> > > >Hi Alex,
> > > >
> > > >2018-03-13 19:20 GMT+01:00 Alex Harui :
> > > >
> > > >> Hi Carlos,
> > > >>
> > > >> I took a quick look.
> > > >>
> > > >> 1) I don't see how if the user did:
> > > >>
> > > >> myComp.className = "Carlos";
> > > >> myComp.className = "";
> > > >>
> > > >>
> > > >Right this case is missing, we need to add it, but seems simple since
> is
> > > >deal with value == ""
> > >
> > > Carlos, that was a simple example.  What about:
> > >
> > > myComp.className = "Carlos Piotr Alex";
> > > myComp.className = "Carlos Alex";
> > >
> > > The "Piotr" class would need to be removed.
> > >
> > > >
> > > >
> > > >> That 'Carlos' would be removed from the classList.
> > > >>
> > > >> 2) I still don't like that we are calling split and apply on
> classList
> > > >> even for simple assignment of a single className
> > > >>
> > > >> 3) I don't like that as we aggregate typeNames that we will reset
> > > >> className to "" and call split more than once.  Not to mention the
> > > >> overhead of the extra function calls now that typeNames is not a var
> > and
> > > >> now a getter/setter.
> > > >>
> > > >
> > > >ok
> > > >
> > > >>
> > > >>
> > > >> That said, I also took another look at the Basic UIBase code and
> don't
> > > >> like it either.  Seems like it could be optimized as well and have
> > > >> setClassName call computeFinalClassNames.
> > > >>
> > > >> Regarding performance.  I think the key issue is that every change
> to
> > > >> element.className or element.classList can cause a DOM update, so
> you
> > > >> don't want to change element.className or element.classList more
> than
> > > >>once
> > > >> during the initialization of the component.  I didn't watch the
> videos
> > > >>you
> > > >> linked to, but in the first link to a blog post, that person was
> just
> > > >> replacing a one-time setting of className to a string with a call to
> > > >> classList.add.  

Re: Experiment with UIBase change to classList

[Piotr Zarzycki]

Carlos,

You can do, but I will use className to manipulate things instead taking
component.element.classList.remove <- To many dots. Previous way doesn't
require from me as a user cleaning anything.  I can tell you from the
perspective me as a user who already had an opportunity to write production
application, that I will use className instead add/remove anything.

Are you saying that now I have to do ?

myComp.className = "Carlos Piotr Alex";
myComp.className = "";
myComp.className = "Carlos Alex";

It looks like we won't convince you to just use UIBase as is today, so go
ahead and implement as you wanted in the Jewel.

Btw. In the old way once your component is created no one prevent you use
component.element.classList add/remove/toggle - It will work once component
is created - This is important.

Thanks,
Piotr



2018-03-14 7:44 GMT+01:00 Carlos Rovira :

> Hi Alex,
>
> to recete the classList you can do className = "" and reenter typeNames and
> classNames
> I think is the only way, then you can continue doing add/remove/toggle
> though classList.
>
> In your example you're still thinking in className mode, you can do easily
> with classList.remove('Piotr'')
>
>
>
>
>
> 2018-03-14 0:07 GMT+01:00 Alex Harui :
>
> >
> >
> > On 3/13/18, 3:16 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >  wrote:
> >
> > >Hi Alex,
> > >
> > >2018-03-13 19:20 GMT+01:00 Alex Harui :
> > >
> > >> Hi Carlos,
> > >>
> > >> I took a quick look.
> > >>
> > >> 1) I don't see how if the user did:
> > >>
> > >> myComp.className = "Carlos";
> > >> myComp.className = "";
> > >>
> > >>
> > >Right this case is missing, we need to add it, but seems simple since is
> > >deal with value == ""
> >
> > Carlos, that was a simple example.  What about:
> >
> > myComp.className = "Carlos Piotr Alex";
> > myComp.className = "Carlos Alex";
> >
> > The "Piotr" class would need to be removed.
> >
> > >
> > >
> > >> That 'Carlos' would be removed from the classList.
> > >>
> > >> 2) I still don't like that we are calling split and apply on classList
> > >> even for simple assignment of a single className
> > >>
> > >> 3) I don't like that as we aggregate typeNames that we will reset
> > >> className to "" and call split more than once.  Not to mention the
> > >> overhead of the extra function calls now that typeNames is not a var
> and
> > >> now a getter/setter.
> > >>
> > >
> > >ok
> > >
> > >>
> > >>
> > >> That said, I also took another look at the Basic UIBase code and don't
> > >> like it either.  Seems like it could be optimized as well and have
> > >> setClassName call computeFinalClassNames.
> > >>
> > >> Regarding performance.  I think the key issue is that every change to
> > >> element.className or element.classList can cause a DOM update, so you
> > >> don't want to change element.className or element.classList more than
> > >>once
> > >> during the initialization of the component.  I didn't watch the videos
> > >>you
> > >> linked to, but in the first link to a blog post, that person was just
> > >> replacing a one-time setting of className to a string with a call to
> > >> classList.add.  But his code is probably pre-parsed into the parameter
> > >> list to classList.add.  We have to compute it from a String.split.
> And
> > >> the current code you have proposed is going to change classList
> several
> > >> times as we aggregate typeNames.  That doesn't seem right.
> > >>
> > >
> > >I think the video is short and explained very well. I think is good to
> > >review it
> > >
> > >But I think is ok to change my code to get a better performant one. Mine
> > >was created only to see
> > >it works, now we need to tune depending on the different entry points as
> > >you say
> > >
> > >
> > >> If you want to use classList everywhere, I think we'd have to shadow
> it
> > >> with an array so we only set the array of strings on classList as
> > >>needed,
> > >> but classList isn't set up to do a full replacement, AFAICT.
> > >>
> > >> IMO, if you want to continue to pursue use of classList, you would
> focus
> > >> on just replacing computeFinalClassNames and/or setClassName with
> > >> classList handling and see how it looks.  Leave typeNames as a var and
> > >>let
> > >> it aggregate without touching classList.  UIBase will eventually call
> > >> setClassName in addedToParent.  That is the point in the lifecycle
> where
> > >> the user might have set some classNames and the typeNames have been
> > >> aggregated and maybe "fab" or "primary" has been set as well.  Either
> > >>you
> > >> track everything in a shadow array or you do one big split then.
> > >>
> > >> Do we know if you set className then read classList, doesn't classList
> > >> represent the things set in className?  If that's the case, then in
> > >> MDL/Jewel, "fab" and "primary" should just check to see if
> addedToParent
> 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Alex,

to recete the classList you can do className = "" and reenter typeNames and
classNames
I think is the only way, then you can continue doing add/remove/toggle
though classList.

In your example you're still thinking in className mode, you can do easily
with classList.remove('Piotr'')





2018-03-14 0:07 GMT+01:00 Alex Harui :

>
>
> On 3/13/18, 3:16 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >2018-03-13 19:20 GMT+01:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> I took a quick look.
> >>
> >> 1) I don't see how if the user did:
> >>
> >> myComp.className = "Carlos";
> >> myComp.className = "";
> >>
> >>
> >Right this case is missing, we need to add it, but seems simple since is
> >deal with value == ""
>
> Carlos, that was a simple example.  What about:
>
> myComp.className = "Carlos Piotr Alex";
> myComp.className = "Carlos Alex";
>
> The "Piotr" class would need to be removed.
>
> >
> >
> >> That 'Carlos' would be removed from the classList.
> >>
> >> 2) I still don't like that we are calling split and apply on classList
> >> even for simple assignment of a single className
> >>
> >> 3) I don't like that as we aggregate typeNames that we will reset
> >> className to "" and call split more than once.  Not to mention the
> >> overhead of the extra function calls now that typeNames is not a var and
> >> now a getter/setter.
> >>
> >
> >ok
> >
> >>
> >>
> >> That said, I also took another look at the Basic UIBase code and don't
> >> like it either.  Seems like it could be optimized as well and have
> >> setClassName call computeFinalClassNames.
> >>
> >> Regarding performance.  I think the key issue is that every change to
> >> element.className or element.classList can cause a DOM update, so you
> >> don't want to change element.className or element.classList more than
> >>once
> >> during the initialization of the component.  I didn't watch the videos
> >>you
> >> linked to, but in the first link to a blog post, that person was just
> >> replacing a one-time setting of className to a string with a call to
> >> classList.add.  But his code is probably pre-parsed into the parameter
> >> list to classList.add.  We have to compute it from a String.split.  And
> >> the current code you have proposed is going to change classList several
> >> times as we aggregate typeNames.  That doesn't seem right.
> >>
> >
> >I think the video is short and explained very well. I think is good to
> >review it
> >
> >But I think is ok to change my code to get a better performant one. Mine
> >was created only to see
> >it works, now we need to tune depending on the different entry points as
> >you say
> >
> >
> >> If you want to use classList everywhere, I think we'd have to shadow it
> >> with an array so we only set the array of strings on classList as
> >>needed,
> >> but classList isn't set up to do a full replacement, AFAICT.
> >>
> >> IMO, if you want to continue to pursue use of classList, you would focus
> >> on just replacing computeFinalClassNames and/or setClassName with
> >> classList handling and see how it looks.  Leave typeNames as a var and
> >>let
> >> it aggregate without touching classList.  UIBase will eventually call
> >> setClassName in addedToParent.  That is the point in the lifecycle where
> >> the user might have set some classNames and the typeNames have been
> >> aggregated and maybe "fab" or "primary" has been set as well.  Either
> >>you
> >> track everything in a shadow array or you do one big split then.
> >>
> >> Do we know if you set className then read classList, doesn't classList
> >> represent the things set in className?  If that's the case, then in
> >> MDL/Jewel, "fab" and "primary" should just check to see if addedToParent
> >> has been called and the classNames/classList has been stuffed and if it
> >> has, just call classList.toggle.
> >>
> >> However, IMO, the simplest solution should be to leave UIBase as is.
> >>MDL
> >> and Jewel should just have to override computeFinalClassNames to include
> >> adding "fab"/"primary" to the final set of strings.  I don't understand
> >> why other work would be needed.  But the "fab"/"primary" getter setters
> >> should be able to call classList.toggle instead of
> >>computeFinalClassNames
> >> and/or setClassName.
> >>
> >> If you want to separately prove that it is faster to call String.split()
> >> and set classList instead of passing the space-delimited strings to
> >> className, that's fine too.  The difference for us vs the link you
> >>posted
> >> is that we MUST start with space-delimited strings coming from the MXML,
> >> so at least one split() call is required.
> >>
> >
> >I spend some hours trying and
> >* change typeNames to only one var again, then in addToParent I reset the
> >className, I think this solves the problem of using typeNames lots of
> >times
> >and call 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Alex,

2018-03-13 19:20 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> I took a quick look.
>
> 1) I don't see how if the user did:
>
> myComp.className = "Carlos";
> myComp.className = "";
>
>
Right this case is missing, we need to add it, but seems simple since is
deal with value == ""


> That 'Carlos' would be removed from the classList.
>
> 2) I still don't like that we are calling split and apply on classList
> even for simple assignment of a single className
>
> 3) I don't like that as we aggregate typeNames that we will reset
> className to "" and call split more than once.  Not to mention the
> overhead of the extra function calls now that typeNames is not a var and
> now a getter/setter.
>

ok

>
>
> That said, I also took another look at the Basic UIBase code and don't
> like it either.  Seems like it could be optimized as well and have
> setClassName call computeFinalClassNames.
>
> Regarding performance.  I think the key issue is that every change to
> element.className or element.classList can cause a DOM update, so you
> don't want to change element.className or element.classList more than once
> during the initialization of the component.  I didn't watch the videos you
> linked to, but in the first link to a blog post, that person was just
> replacing a one-time setting of className to a string with a call to
> classList.add.  But his code is probably pre-parsed into the parameter
> list to classList.add.  We have to compute it from a String.split.  And
> the current code you have proposed is going to change classList several
> times as we aggregate typeNames.  That doesn't seem right.
>

I think the video is short and explained very well. I think is good to
review it

But I think is ok to change my code to get a better performant one. Mine
was created only to see
it works, now we need to tune depending on the different entry points as
you say


> If you want to use classList everywhere, I think we'd have to shadow it
> with an array so we only set the array of strings on classList as needed,
> but classList isn't set up to do a full replacement, AFAICT.
>
> IMO, if you want to continue to pursue use of classList, you would focus
> on just replacing computeFinalClassNames and/or setClassName with
> classList handling and see how it looks.  Leave typeNames as a var and let
> it aggregate without touching classList.  UIBase will eventually call
> setClassName in addedToParent.  That is the point in the lifecycle where
> the user might have set some classNames and the typeNames have been
> aggregated and maybe "fab" or "primary" has been set as well.  Either you
> track everything in a shadow array or you do one big split then.
>
> Do we know if you set className then read classList, doesn't classList
> represent the things set in className?  If that's the case, then in
> MDL/Jewel, "fab" and "primary" should just check to see if addedToParent
> has been called and the classNames/classList has been stuffed and if it
> has, just call classList.toggle.
>
> However, IMO, the simplest solution should be to leave UIBase as is.  MDL
> and Jewel should just have to override computeFinalClassNames to include
> adding "fab"/"primary" to the final set of strings.  I don't understand
> why other work would be needed.  But the "fab"/"primary" getter setters
> should be able to call classList.toggle instead of computeFinalClassNames
> and/or setClassName.
>
> If you want to separately prove that it is faster to call String.split()
> and set classList instead of passing the space-delimited strings to
> className, that's fine too.  The difference for us vs the link you posted
> is that we MUST start with space-delimited strings coming from the MXML,
> so at least one split() call is required.
>

I spend some hours trying and
* change typeNames to only one var again, then in addToParent I reset the
className, I think this solves the problem of using typeNames lots of times
and call split and apply lots of times
* I tried to create again a computedFinalClassNames to handle classList.
* The only problem I see is that if don't see any way to avoid call split
and apply each time you call setClassName since a compute final is needed.
Or I'm missing something?

Maybe could be good that you write some code (pseudo code) here better to
explain what you propose
since I don't know if I'm understanding your phrases accurately

It's time for me to go to sleep, tomorrow I'll check if you posted
something to try it

thanks!


>
> Of course, I could be missing something...
> -Alex
>
> On 3/13/18, 10:30 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >right, I tested it in JewelExample. If you find something that does not
> >conform to what you thinked please let me know to address it.
> >I think it should not be very difficult to handle some isolated case with
> >what we have
> >
> >thanks
> >
> >
> >

Re: Experiment with UIBase change to classList

[Alex Harui]

Hi Carlos,

I took a quick look.

1) I don't see how if the user did:

myComp.className = "Carlos";
myComp.className = "";

That 'Carlos' would be removed from the classList.

2) I still don't like that we are calling split and apply on classList
even for simple assignment of a single className

3) I don't like that as we aggregate typeNames that we will reset
className to "" and call split more than once.  Not to mention the
overhead of the extra function calls now that typeNames is not a var and
now a getter/setter.


That said, I also took another look at the Basic UIBase code and don't
like it either.  Seems like it could be optimized as well and have
setClassName call computeFinalClassNames.

Regarding performance.  I think the key issue is that every change to
element.className or element.classList can cause a DOM update, so you
don't want to change element.className or element.classList more than once
during the initialization of the component.  I didn't watch the videos you
linked to, but in the first link to a blog post, that person was just
replacing a one-time setting of className to a string with a call to
classList.add.  But his code is probably pre-parsed into the parameter
list to classList.add.  We have to compute it from a String.split.  And
the current code you have proposed is going to change classList several
times as we aggregate typeNames.  That doesn't seem right.

If you want to use classList everywhere, I think we'd have to shadow it
with an array so we only set the array of strings on classList as needed,
but classList isn't set up to do a full replacement, AFAICT.

IMO, if you want to continue to pursue use of classList, you would focus
on just replacing computeFinalClassNames and/or setClassName with
classList handling and see how it looks.  Leave typeNames as a var and let
it aggregate without touching classList.  UIBase will eventually call
setClassName in addedToParent.  That is the point in the lifecycle where
the user might have set some classNames and the typeNames have been
aggregated and maybe "fab" or "primary" has been set as well.  Either you
track everything in a shadow array or you do one big split then.

Do we know if you set className then read classList, doesn't classList
represent the things set in className?  If that's the case, then in
MDL/Jewel, "fab" and "primary" should just check to see if addedToParent
has been called and the classNames/classList has been stuffed and if it
has, just call classList.toggle.

However, IMO, the simplest solution should be to leave UIBase as is.  MDL
and Jewel should just have to override computeFinalClassNames to include
adding "fab"/"primary" to the final set of strings.  I don't understand
why other work would be needed.  But the "fab"/"primary" getter setters
should be able to call classList.toggle instead of computeFinalClassNames
and/or setClassName.

If you want to separately prove that it is faster to call String.split()
and set classList instead of passing the space-delimited strings to
className, that's fine too.  The difference for us vs the link you posted
is that we MUST start with space-delimited strings coming from the MXML,
so at least one split() call is required.

Of course, I could be missing something...
-Alex

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

>Hi Alex,
>
>right, I tested it in JewelExample. If you find something that does not
>conform to what you thinked please let me know to address it.
>I think it should not be very difficult to handle some isolated case with
>what we have
>
>thanks
>
>
>
>2018-03-13 18:24 GMT+01:00 Alex Harui :
>
>> Hi Carlos,
>>
>> Just so I'm clear, you believe that UIBase.as in the jewel-ui-set branch
>> addresses all of these issues?  I've just been watching commits, so if
>>you
>> think that's the case then I will look at the current state of your
>>UIBase.
>>
>> Thanks,
>> -Alex
>>
>> On 3/13/18, 10:14 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi Alex,
>> >
>> >2018-03-13 17:50 GMT+01:00 Alex Harui :
>> >
>> >> Hi Carlos,
>> >>
>> >> I do not think you are considering all of the scenarios in your
>>proposed
>> >> code.  I'm sad that I have to delineate them again, but I will try.
>> >>
>> >> 1) In Basic there are two sets of strings:  The fixed set from
>>typeNames
>> >> that should "never" change.  And the className set from the user that
>> >>can
>> >> not only add, but also remove a set of HTML classes.
>> >>
>> >>
>> >I see the next email so I respond to this in the following, I solved
>>that
>> >and explain later
>> >
>> >
>> >> 2) In MDL and I guess Jewel, there is a third set.  They are tied to
>> >> properties like you said.  "fab" and "primary", and things like that.
>> >>
>> >
>> >Yes this will be the normal case 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Alex,

right, I tested it in JewelExample. If you find something that does not
conform to what you thinked please let me know to address it.
I think it should not be very difficult to handle some isolated case with
what we have

thanks



2018-03-13 18:24 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> Just so I'm clear, you believe that UIBase.as in the jewel-ui-set branch
> addresses all of these issues?  I've just been watching commits, so if you
> think that's the case then I will look at the current state of your UIBase.
>
> Thanks,
> -Alex
>
> On 3/13/18, 10:14 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >2018-03-13 17:50 GMT+01:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> I do not think you are considering all of the scenarios in your proposed
> >> code.  I'm sad that I have to delineate them again, but I will try.
> >>
> >> 1) In Basic there are two sets of strings:  The fixed set from typeNames
> >> that should "never" change.  And the className set from the user that
> >>can
> >> not only add, but also remove a set of HTML classes.
> >>
> >>
> >I see the next email so I respond to this in the following, I solved that
> >and explain later
> >
> >
> >> 2) In MDL and I guess Jewel, there is a third set.  They are tied to
> >> properties like you said.  "fab" and "primary", and things like that.
> >>
> >
> >Yes this will be the normal case in users. People using Jewel or other UI
> >set with look and feel will
> >use properties as their normal basis in the same way they do now in MDL
> >
> >
> >>
> >> 3) For PAYG reasons, it would be great if Basic did not have to
> >> contemplate the third set.
> >>
> >> 4) For PAYG reasons, it would be nice if Basic did not have to assume
> >> conversion to array and call split().  The current code in the develop
> >> branch lets the browser do the split() in native code.
> >>
> >
> >for 3 and 4 what's the best way to left UIBase untouched so I can use my
> >code in Jewel?
> >Is the actual way of duplicating the code for UIBase in my own library the
> >best way?
> >
> >
> >>
> >> Then, as a performance consideration, Harbs claims that changing
> >>classList
> >> is expensive.
> >>
> >
> >I don't will say that there's a low performance, but my guess is that is
> >nothing that we should have in consideration, but we can discuss it later.
> >
> >
> >>
> >> So, your proposed solution MUST allow the user to delete/remove any
> >> strings they added without removing strings added from typeNames or from
> >> the "fab"/"primary" properties.
> >
> >
> >That's now working
> >
> >
> >> And allow add/remove of the user's
> >> strings before or after changing properties like "fab" and "primary".
> >>
> >
> >as we are dealing with a collection this is working and only one copy of
> >the string is maintained and outputted, I think in this way
> >less errors of this kind should happen
> >
> >
> >>
> >> Show us how that will work.  I'm pretty sure it is possible.  Then we
> >>will
> >> debate the performance aspects.
> >>
> >
> >I have it right now completely working in my branch, so it's a matter to
> >try it in JewelExample
> >
> >
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >So, you if is == you expect that setting className in royale you remove
> >> >all
> >> >inclusive typeNames?
> >> >Harbs, className is not equal to class in HTML
> >> >
> >> >2018-03-13 14:08 GMT+01:00 Harbs :
> >> >
> >> >> className in Royale == class in HTML.
> >> >>
> >> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira
> >>
> >> >> wrote:
> >> >> >
> >> >> > I think we're getting to the point in this discussion.
> >> >> >
> >> >> > For me as a user, I expect to use className property to "add", and
> >>not
> >> >> > override all I have
> >> >> > for that reason in MDL and now in Royale we decided to create
> >> >>properties
> >> >> > (that use to be boolean) like "primary" or in MDL "fab" to add or
> >> >>remove
> >> >> > those properties (since are library properties that are managed
> >> >> > specifically).
> >> >> > I don't want to set primary and then className removes that! I
> >>think
> >> >>that
> >> >> > function is not right and will be the cause of many problems.
> >> >> >
> >> >> > If the user wants to remove all class names, he can do with a
> >>method
> >> >>that
> >> >> > callls element.classList.remove, but the behavior by default
> >> >>shouldn't be
> >> >> > to use className to get rid of all what we have.
> >> >> >
> >> >> > If you work with html directly , is normal to write class="class1
> >> >>class2
> >> >> > ..." and create from scratch
> >> >> >
> >> >> > in Royale you write mxml and as3 and use className to add
> >>additional
> 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

2018-03-13 18:03 GMT+01:00 Alex Harui :

> After I sent this, I saw one of your code changes that changed typeNames
> to a getter/setter.  Please consider that right now "typeNames" is
> aggregated in the constructor so that subclasses do not need to override
> createElement.  That means that Button might set typeNames="Button" and
> ImageButton might set "typeNames += " ImageButton".  That means that
> ImageButton will set typeNames twice, once with just "Button" in the
> Button constructor and again in the ImageButton constructor with "Button
> ImageButton".  I don't think we want to run the typeNames setter multiple
> times.
>

I notice this. I'm reseting the classNames when they are set, so now is
behaving the same old way.
Right now as the old code only "ImageButton" will be in ImageButton. I'm
using as you recommended in constructor.
Right now I'm having the same effects in final code we have with the old
code, but I think we have a more simplified code.

I'm very confident with this code, and must say I didn't have all with me
when I proposed it, but couldn't see in Harbs arguments nothing that proves
old way is better than new or at least nothing that proves the old way is
better. I continue thinking the old way is not wrong due to my long
experience with this issue.

Since I proved to Piotr that the cases he was worried are ok, I don't know
if he thinks is as well ok. I'd want to know what he thinks now.

My guess is this should go to Core since if not I think this will be very
strange to people coming to Royale. That will make for sure the need to
adjust the rest of classes.

But if you think is not ok, I can go with it only in Jewel and left Core
untouched. I have it in the same namespace, but maybe I should extend and
the make the rest of classes extend directly from JewelUIBase or something
like that.

thanks


>
> Thanks,
> -Alex
>
> On 3/13/18, 9:50 AM, "Alex Harui"  wrote:
>
> >Hi Carlos,
> >
> >I do not think you are considering all of the scenarios in your proposed
> >code.  I'm sad that I have to delineate them again, but I will try.
> >
> >1) In Basic there are two sets of strings:  The fixed set from typeNames
> >that should "never" change.  And the className set from the user that can
> >not only add, but also remove a set of HTML classes.
> >
> >2) In MDL and I guess Jewel, there is a third set.  They are tied to
> >properties like you said.  "fab" and "primary", and things like that.
> >
> >3) For PAYG reasons, it would be great if Basic did not have to
> >contemplate the third set.
> >
> >4) For PAYG reasons, it would be nice if Basic did not have to assume
> >conversion to array and call split().  The current code in the develop
> >branch lets the browser do the split() in native code.
> >
> >Then, as a performance consideration, Harbs claims that changing classList
> >is expensive.
> >
> >So, your proposed solution MUST allow the user to delete/remove any
> >strings they added without removing strings added from typeNames or from
> >the "fab"/"primary" properties.  And allow add/remove of the user's
> >strings before or after changing properties like "fab" and "primary".
> >
> >Show us how that will work.  I'm pretty sure it is possible.  Then we will
> >debate the performance aspects.
> >
> >Thanks,
> >-Alex
> >
> >On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> > wrote:
> >
> >>So, you if is == you expect that setting className in royale you remove
> >>all
> >>inclusive typeNames?
> >>Harbs, className is not equal to class in HTML
> >>
> >>2018-03-13 14:08 GMT+01:00 Harbs :
> >>
> >>> className in Royale == class in HTML.
> >>>
> >>> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira 
> >>> wrote:
> >>> >
> >>> > I think we're getting to the point in this discussion.
> >>> >
> >>> > For me as a user, I expect to use className property to "add", and
> >>>not
> >>> > override all I have
> >>> > for that reason in MDL and now in Royale we decided to create
> >>>properties
> >>> > (that use to be boolean) like "primary" or in MDL "fab" to add or
> >>>remove
> >>> > those properties (since are library properties that are managed
> >>> > specifically).
> >>> > I don't want to set primary and then className removes that! I think
> >>>that
> >>> > function is not right and will be the cause of many problems.
> >>> >
> >>> > If the user wants to remove all class names, he can do with a method
> >>>that
> >>> > callls element.classList.remove, but the behavior by default
> >>>shouldn't be
> >>> > to use className to get rid of all what we have.
> >>> >
> >>> > If you work with html directly , is normal to write class="class1
> >>>class2
> >>> > ..." and create from scratch
> >>> >
> >>> > in Royale you write mxml and as3 and use className to add additional
> >>> > classes that are not in the api but not to 

Re: Experiment with UIBase change to classList

[Alex Harui]

Hi Carlos,

Just so I'm clear, you believe that UIBase.as in the jewel-ui-set branch
addresses all of these issues?  I've just been watching commits, so if you
think that's the case then I will look at the current state of your UIBase.

Thanks,
-Alex

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

>Hi Alex,
>
>2018-03-13 17:50 GMT+01:00 Alex Harui :
>
>> Hi Carlos,
>>
>> I do not think you are considering all of the scenarios in your proposed
>> code.  I'm sad that I have to delineate them again, but I will try.
>>
>> 1) In Basic there are two sets of strings:  The fixed set from typeNames
>> that should "never" change.  And the className set from the user that
>>can
>> not only add, but also remove a set of HTML classes.
>>
>>
>I see the next email so I respond to this in the following, I solved that
>and explain later
>
>
>> 2) In MDL and I guess Jewel, there is a third set.  They are tied to
>> properties like you said.  "fab" and "primary", and things like that.
>>
>
>Yes this will be the normal case in users. People using Jewel or other UI
>set with look and feel will
>use properties as their normal basis in the same way they do now in MDL
>
>
>>
>> 3) For PAYG reasons, it would be great if Basic did not have to
>> contemplate the third set.
>>
>> 4) For PAYG reasons, it would be nice if Basic did not have to assume
>> conversion to array and call split().  The current code in the develop
>> branch lets the browser do the split() in native code.
>>
>
>for 3 and 4 what's the best way to left UIBase untouched so I can use my
>code in Jewel?
>Is the actual way of duplicating the code for UIBase in my own library the
>best way?
>
>
>>
>> Then, as a performance consideration, Harbs claims that changing
>>classList
>> is expensive.
>>
>
>I don't will say that there's a low performance, but my guess is that is
>nothing that we should have in consideration, but we can discuss it later.
>
>
>>
>> So, your proposed solution MUST allow the user to delete/remove any
>> strings they added without removing strings added from typeNames or from
>> the "fab"/"primary" properties.
>
>
>That's now working
>
>
>> And allow add/remove of the user's
>> strings before or after changing properties like "fab" and "primary".
>>
>
>as we are dealing with a collection this is working and only one copy of
>the string is maintained and outputted, I think in this way
>less errors of this kind should happen
>
>
>>
>> Show us how that will work.  I'm pretty sure it is possible.  Then we
>>will
>> debate the performance aspects.
>>
>
>I have it right now completely working in my branch, so it's a matter to
>try it in JewelExample
>
>
>>
>> Thanks,
>> -Alex
>>
>> On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >So, you if is == you expect that setting className in royale you remove
>> >all
>> >inclusive typeNames?
>> >Harbs, className is not equal to class in HTML
>> >
>> >2018-03-13 14:08 GMT+01:00 Harbs :
>> >
>> >> className in Royale == class in HTML.
>> >>
>> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira
>>
>> >> wrote:
>> >> >
>> >> > I think we're getting to the point in this discussion.
>> >> >
>> >> > For me as a user, I expect to use className property to "add", and
>>not
>> >> > override all I have
>> >> > for that reason in MDL and now in Royale we decided to create
>> >>properties
>> >> > (that use to be boolean) like "primary" or in MDL "fab" to add or
>> >>remove
>> >> > those properties (since are library properties that are managed
>> >> > specifically).
>> >> > I don't want to set primary and then className removes that! I
>>think
>> >>that
>> >> > function is not right and will be the cause of many problems.
>> >> >
>> >> > If the user wants to remove all class names, he can do with a
>>method
>> >>that
>> >> > callls element.classList.remove, but the behavior by default
>> >>shouldn't be
>> >> > to use className to get rid of all what we have.
>> >> >
>> >> > If you work with html directly , is normal to write class="class1
>> >>class2
>> >> > ..." and create from scratch
>> >> >
>> >> > in Royale you write mxml and as3 and use className to add
>>additional
>> >> > classes that are not in the api but not to remove the ones the
>> >>component
>> >> > set plus the ones the user "switched" on/off due to properties
>> >> >
>> >> >
>> >> >
>> >> > 2018-03-13 13:42 GMT+01:00 Harbs :
>> >> >
>> >> >> No. className is supposed to *replace* the entire classList minus
>>the
>> >> >> internally managed ones (i.e. typeNames). Your code drastically
>> >>changes
>> >> the
>> >> >> current behavior.
>> >> >>
>> >> >> You cannot use add for that and replacing the classList will
>>destroy
>> >> your
>> >> >> custom class names.
>> 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Alex,

2018-03-13 17:50 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> I do not think you are considering all of the scenarios in your proposed
> code.  I'm sad that I have to delineate them again, but I will try.
>
> 1) In Basic there are two sets of strings:  The fixed set from typeNames
> that should "never" change.  And the className set from the user that can
> not only add, but also remove a set of HTML classes.
>
>
I see the next email so I respond to this in the following, I solved that
and explain later


> 2) In MDL and I guess Jewel, there is a third set.  They are tied to
> properties like you said.  "fab" and "primary", and things like that.
>

Yes this will be the normal case in users. People using Jewel or other UI
set with look and feel will
use properties as their normal basis in the same way they do now in MDL


>
> 3) For PAYG reasons, it would be great if Basic did not have to
> contemplate the third set.
>
> 4) For PAYG reasons, it would be nice if Basic did not have to assume
> conversion to array and call split().  The current code in the develop
> branch lets the browser do the split() in native code.
>

for 3 and 4 what's the best way to left UIBase untouched so I can use my
code in Jewel?
Is the actual way of duplicating the code for UIBase in my own library the
best way?


>
> Then, as a performance consideration, Harbs claims that changing classList
> is expensive.
>

I don't will say that there's a low performance, but my guess is that is
nothing that we should have in consideration, but we can discuss it later.


>
> So, your proposed solution MUST allow the user to delete/remove any
> strings they added without removing strings added from typeNames or from
> the "fab"/"primary" properties.


That's now working


> And allow add/remove of the user's
> strings before or after changing properties like "fab" and "primary".
>

as we are dealing with a collection this is working and only one copy of
the string is maintained and outputted, I think in this way
less errors of this kind should happen


>
> Show us how that will work.  I'm pretty sure it is possible.  Then we will
> debate the performance aspects.
>

I have it right now completely working in my branch, so it's a matter to
try it in JewelExample


>
> Thanks,
> -Alex
>
> On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >So, you if is == you expect that setting className in royale you remove
> >all
> >inclusive typeNames?
> >Harbs, className is not equal to class in HTML
> >
> >2018-03-13 14:08 GMT+01:00 Harbs :
> >
> >> className in Royale == class in HTML.
> >>
> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira 
> >> wrote:
> >> >
> >> > I think we're getting to the point in this discussion.
> >> >
> >> > For me as a user, I expect to use className property to "add", and not
> >> > override all I have
> >> > for that reason in MDL and now in Royale we decided to create
> >>properties
> >> > (that use to be boolean) like "primary" or in MDL "fab" to add or
> >>remove
> >> > those properties (since are library properties that are managed
> >> > specifically).
> >> > I don't want to set primary and then className removes that! I think
> >>that
> >> > function is not right and will be the cause of many problems.
> >> >
> >> > If the user wants to remove all class names, he can do with a method
> >>that
> >> > callls element.classList.remove, but the behavior by default
> >>shouldn't be
> >> > to use className to get rid of all what we have.
> >> >
> >> > If you work with html directly , is normal to write class="class1
> >>class2
> >> > ..." and create from scratch
> >> >
> >> > in Royale you write mxml and as3 and use className to add additional
> >> > classes that are not in the api but not to remove the ones the
> >>component
> >> > set plus the ones the user "switched" on/off due to properties
> >> >
> >> >
> >> >
> >> > 2018-03-13 13:42 GMT+01:00 Harbs :
> >> >
> >> >> No. className is supposed to *replace* the entire classList minus the
> >> >> internally managed ones (i.e. typeNames). Your code drastically
> >>changes
> >> the
> >> >> current behavior.
> >> >>
> >> >> You cannot use add for that and replacing the classList will destroy
> >> your
> >> >> custom class names.
> >> >>
> >> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira  >
> >> >> wrote:
> >> >>>
> >> >>> Solving the multiple string value problem:
> >> >>>
> >> >>> This:  >> >>> primary="true"/>
> >> >>>
> >> >>> *PRIMARY*
> >> >>>
> >> >>> with this change
> >> >>>
> >> >>> COMPILE::JS
> >> >>> protected function setClassName(value:String):void
> >> >>> {
> >> >>> var classes:Array = value.split(" ");
> >> >>> element.classList.add.apply(element.classList, classes);
> >> >>> }
> >> >>>
> >> >>> I think this was all the problems we have 

Re: Experiment with UIBase change to classList

[Alex Harui]

After I sent this, I saw one of your code changes that changed typeNames
to a getter/setter.  Please consider that right now "typeNames" is
aggregated in the constructor so that subclasses do not need to override
createElement.  That means that Button might set typeNames="Button" and
ImageButton might set "typeNames += " ImageButton".  That means that
ImageButton will set typeNames twice, once with just "Button" in the
Button constructor and again in the ImageButton constructor with "Button
ImageButton".  I don't think we want to run the typeNames setter multiple
times.

Thanks,
-Alex

On 3/13/18, 9:50 AM, "Alex Harui"  wrote:

>Hi Carlos,
>
>I do not think you are considering all of the scenarios in your proposed
>code.  I'm sad that I have to delineate them again, but I will try.
>
>1) In Basic there are two sets of strings:  The fixed set from typeNames
>that should "never" change.  And the className set from the user that can
>not only add, but also remove a set of HTML classes.
>
>2) In MDL and I guess Jewel, there is a third set.  They are tied to
>properties like you said.  "fab" and "primary", and things like that.
>
>3) For PAYG reasons, it would be great if Basic did not have to
>contemplate the third set.
>
>4) For PAYG reasons, it would be nice if Basic did not have to assume
>conversion to array and call split().  The current code in the develop
>branch lets the browser do the split() in native code.
>
>Then, as a performance consideration, Harbs claims that changing classList
>is expensive.
>
>So, your proposed solution MUST allow the user to delete/remove any
>strings they added without removing strings added from typeNames or from
>the "fab"/"primary" properties.  And allow add/remove of the user's
>strings before or after changing properties like "fab" and "primary".
>
>Show us how that will work.  I'm pretty sure it is possible.  Then we will
>debate the performance aspects.
>
>Thanks,
>-Alex
>
>On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
> wrote:
>
>>So, you if is == you expect that setting className in royale you remove
>>all
>>inclusive typeNames?
>>Harbs, className is not equal to class in HTML
>>
>>2018-03-13 14:08 GMT+01:00 Harbs :
>>
>>> className in Royale == class in HTML.
>>>
>>> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira 
>>> wrote:
>>> >
>>> > I think we're getting to the point in this discussion.
>>> >
>>> > For me as a user, I expect to use className property to "add", and
>>>not
>>> > override all I have
>>> > for that reason in MDL and now in Royale we decided to create
>>>properties
>>> > (that use to be boolean) like "primary" or in MDL "fab" to add or
>>>remove
>>> > those properties (since are library properties that are managed
>>> > specifically).
>>> > I don't want to set primary and then className removes that! I think
>>>that
>>> > function is not right and will be the cause of many problems.
>>> >
>>> > If the user wants to remove all class names, he can do with a method
>>>that
>>> > callls element.classList.remove, but the behavior by default
>>>shouldn't be
>>> > to use className to get rid of all what we have.
>>> >
>>> > If you work with html directly , is normal to write class="class1
>>>class2
>>> > ..." and create from scratch
>>> >
>>> > in Royale you write mxml and as3 and use className to add additional
>>> > classes that are not in the api but not to remove the ones the
>>>component
>>> > set plus the ones the user "switched" on/off due to properties
>>> >
>>> >
>>> >
>>> > 2018-03-13 13:42 GMT+01:00 Harbs :
>>> >
>>> >> No. className is supposed to *replace* the entire classList minus
>>>the
>>> >> internally managed ones (i.e. typeNames). Your code drastically
>>>changes
>>> the
>>> >> current behavior.
>>> >>
>>> >> You cannot use add for that and replacing the classList will destroy
>>> your
>>> >> custom class names.
>>> >>
>>> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira
>>>
>>> >> wrote:
>>> >>>
>>> >>> Solving the multiple string value problem:
>>> >>>
>>> >>> This: >> >>> primary="true"/>
>>> >>>
>>> >>> *PRIMARY*
>>> >>>
>>> >>> with this change
>>> >>>
>>> >>> COMPILE::JS
>>> >>> protected function setClassName(value:String):void
>>> >>> {
>>> >>> var classes:Array = value.split(" ");
>>> >>> element.classList.add.apply(element.classList, classes);
>>> >>> }
>>> >>>
>>> >>> I think this was all the problems we have right?
>>> >>>
>>> >>>
>>> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira :
>>> >>>
>>>  Hi Piotr,
>>> 
>>>  that's one of the advantages of a collection, order doesn't
>>>matter! :)
>>> 
>>>  >> primary="true"/>
>>> 
>>>  output:
>>> 
>>>  *PRIMARY*
>>> 
>>>  this is one of the reason to change, since you'll end trying to
>>>figure
>>>  what 

Re: Experiment with UIBase change to classList

[Alex Harui]

Hi Carlos,

I do not think you are considering all of the scenarios in your proposed
code.  I'm sad that I have to delineate them again, but I will try.

1) In Basic there are two sets of strings:  The fixed set from typeNames
that should "never" change.  And the className set from the user that can
not only add, but also remove a set of HTML classes.

2) In MDL and I guess Jewel, there is a third set.  They are tied to
properties like you said.  "fab" and "primary", and things like that.

3) For PAYG reasons, it would be great if Basic did not have to
contemplate the third set.

4) For PAYG reasons, it would be nice if Basic did not have to assume
conversion to array and call split().  The current code in the develop
branch lets the browser do the split() in native code.

Then, as a performance consideration, Harbs claims that changing classList
is expensive.

So, your proposed solution MUST allow the user to delete/remove any
strings they added without removing strings added from typeNames or from
the "fab"/"primary" properties.  And allow add/remove of the user's
strings before or after changing properties like "fab" and "primary".

Show us how that will work.  I'm pretty sure it is possible.  Then we will
debate the performance aspects.

Thanks,
-Alex

On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>So, you if is == you expect that setting className in royale you remove
>all
>inclusive typeNames?
>Harbs, className is not equal to class in HTML
>
>2018-03-13 14:08 GMT+01:00 Harbs :
>
>> className in Royale == class in HTML.
>>
>> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira 
>> wrote:
>> >
>> > I think we're getting to the point in this discussion.
>> >
>> > For me as a user, I expect to use className property to "add", and not
>> > override all I have
>> > for that reason in MDL and now in Royale we decided to create
>>properties
>> > (that use to be boolean) like "primary" or in MDL "fab" to add or
>>remove
>> > those properties (since are library properties that are managed
>> > specifically).
>> > I don't want to set primary and then className removes that! I think
>>that
>> > function is not right and will be the cause of many problems.
>> >
>> > If the user wants to remove all class names, he can do with a method
>>that
>> > callls element.classList.remove, but the behavior by default
>>shouldn't be
>> > to use className to get rid of all what we have.
>> >
>> > If you work with html directly , is normal to write class="class1
>>class2
>> > ..." and create from scratch
>> >
>> > in Royale you write mxml and as3 and use className to add additional
>> > classes that are not in the api but not to remove the ones the
>>component
>> > set plus the ones the user "switched" on/off due to properties
>> >
>> >
>> >
>> > 2018-03-13 13:42 GMT+01:00 Harbs :
>> >
>> >> No. className is supposed to *replace* the entire classList minus the
>> >> internally managed ones (i.e. typeNames). Your code drastically
>>changes
>> the
>> >> current behavior.
>> >>
>> >> You cannot use add for that and replacing the classList will destroy
>> your
>> >> custom class names.
>> >>
>> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira 
>> >> wrote:
>> >>>
>> >>> Solving the multiple string value problem:
>> >>>
>> >>> This: > >>> primary="true"/>
>> >>>
>> >>> *PRIMARY*
>> >>>
>> >>> with this change
>> >>>
>> >>> COMPILE::JS
>> >>> protected function setClassName(value:String):void
>> >>> {
>> >>> var classes:Array = value.split(" ");
>> >>> element.classList.add.apply(element.classList, classes);
>> >>> }
>> >>>
>> >>> I think this was all the problems we have right?
>> >>>
>> >>>
>> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira :
>> >>>
>>  Hi Piotr,
>> 
>>  that's one of the advantages of a collection, order doesn't
>>matter! :)
>> 
>>  > primary="true"/>
>> 
>>  output:
>> 
>>  *PRIMARY*
>> 
>>  this is one of the reason to change, since you'll end trying to
>>figure
>>  what comes in first or not.
>> 
>>  Do you need more evidence?
>> 
>>  Thanks
>> 
>> 
>>  2018-03-13 12:48 GMT+01:00 Piotr Zarzycki
>>> >:
>> 
>> > In my example orders matters. Setup first className than your
>> property.
>> >
>> >
>> > On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
>> >
>> >> Hi Carlos,
>> >>
>> >> I definitely appreciate the work you are doing. I’m swamped with
>> work
>> >> right now, so I don’t have the time to spend helping you. (Sorry
>> about
>> >> that.) :-(
>> >>
>> >> I think the discussions here are about pretty minor points. You
>>can
>> >> certainly implement jewel how you think makes sense, but if you
>>want
>> >> to
>> >> make 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

So, you if is == you expect that setting className in royale you remove all
inclusive typeNames?
Harbs, className is not equal to class in HTML

2018-03-13 14:08 GMT+01:00 Harbs :

> className in Royale == class in HTML.
>
> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira 
> wrote:
> >
> > I think we're getting to the point in this discussion.
> >
> > For me as a user, I expect to use className property to "add", and not
> > override all I have
> > for that reason in MDL and now in Royale we decided to create properties
> > (that use to be boolean) like "primary" or in MDL "fab" to add or remove
> > those properties (since are library properties that are managed
> > specifically).
> > I don't want to set primary and then className removes that! I think that
> > function is not right and will be the cause of many problems.
> >
> > If the user wants to remove all class names, he can do with a method that
> > callls element.classList.remove, but the behavior by default shouldn't be
> > to use className to get rid of all what we have.
> >
> > If you work with html directly , is normal to write class="class1 class2
> > ..." and create from scratch
> >
> > in Royale you write mxml and as3 and use className to add additional
> > classes that are not in the api but not to remove the ones the component
> > set plus the ones the user "switched" on/off due to properties
> >
> >
> >
> > 2018-03-13 13:42 GMT+01:00 Harbs :
> >
> >> No. className is supposed to *replace* the entire classList minus the
> >> internally managed ones (i.e. typeNames). Your code drastically changes
> the
> >> current behavior.
> >>
> >> You cannot use add for that and replacing the classList will destroy
> your
> >> custom class names.
> >>
> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira 
> >> wrote:
> >>>
> >>> Solving the multiple string value problem:
> >>>
> >>> This:  >>> primary="true"/>
> >>>
> >>> *PRIMARY*
> >>>
> >>> with this change
> >>>
> >>> COMPILE::JS
> >>> protected function setClassName(value:String):void
> >>> {
> >>> var classes:Array = value.split(" ");
> >>> element.classList.add.apply(element.classList, classes);
> >>> }
> >>>
> >>> I think this was all the problems we have right?
> >>>
> >>>
> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira :
> >>>
>  Hi Piotr,
> 
>  that's one of the advantages of a collection, order doesn't matter! :)
> 
>   primary="true"/>
> 
>  output:
> 
>  *PRIMARY*
> 
>  this is one of the reason to change, since you'll end trying to figure
>  what comes in first or not.
> 
>  Do you need more evidence?
> 
>  Thanks
> 
> 
>  2018-03-13 12:48 GMT+01:00 Piotr Zarzycki  >:
> 
> > In my example orders matters. Setup first className than your
> property.
> >
> >
> > On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
> >
> >> Hi Carlos,
> >>
> >> I definitely appreciate the work you are doing. I’m swamped with
> work
> >> right now, so I don’t have the time to spend helping you. (Sorry
> about
> >> that.) :-(
> >>
> >> I think the discussions here are about pretty minor points. You can
> >> certainly implement jewel how you think makes sense, but if you want
> >> to
> >> make changes to basic in areas which are not broken, there needs to
> >> be a
> >> really good reason to do so.
> >>
> >> My $0.02,
> >> Harbs
> >>> On Mar 13, 2018, at 1:31 PM, Carlos Rovira <
> carlosrov...@apache.org>
> >> wrote:
> >>>
> >>> Hi Piotr,
> >>>
> >>> thanks for your words, but is difficult to work on something when
> you
> >>> believe in your vision and others no, and more over when all the
> >> facts
> >> you
> >>> see corroborates that vision. It's difficult to maintain live the
> > moto in
> >>> that scenario.
> >>>
> >>> but anyway for you Kindly words
> >>>
> >>> Carlos
> >>>
> >>>
> >>> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki <
> piotrzarzyck...@gmail.com
> >> :
> >>>
>  Carlos,
> 
>  In my opinion you are not facing the wall from US. You are facing
> >> the
> >> wall
>  from lack of volounteers who can help, do the job.
>  Believe me your Jewel effort in my list of tasks is almost on the
> > Top. I
>  have to fiinish planned work in TranspiledActionScript first and I
> > hope
> >> to
>  join.
> 
>  When it will be - maybe in couple of weeks. In the end something
> > have to
>  pay the bills and Royale is only fraction of that.
> 
>  I contribute in other related areas. I Wish I could contribute in
> > your
> >> way
>  or Alex and Peter.
> 
>  Thanks for your work!
>  Piotr

Re: Experiment with UIBase change to classList

[Harbs]

className in Royale == class in HTML.

> On Mar 13, 2018, at 2:55 PM, Carlos Rovira  wrote:
> 
> I think we're getting to the point in this discussion.
> 
> For me as a user, I expect to use className property to "add", and not
> override all I have
> for that reason in MDL and now in Royale we decided to create properties
> (that use to be boolean) like "primary" or in MDL "fab" to add or remove
> those properties (since are library properties that are managed
> specifically).
> I don't want to set primary and then className removes that! I think that
> function is not right and will be the cause of many problems.
> 
> If the user wants to remove all class names, he can do with a method that
> callls element.classList.remove, but the behavior by default shouldn't be
> to use className to get rid of all what we have.
> 
> If you work with html directly , is normal to write class="class1 class2
> ..." and create from scratch
> 
> in Royale you write mxml and as3 and use className to add additional
> classes that are not in the api but not to remove the ones the component
> set plus the ones the user "switched" on/off due to properties
> 
> 
> 
> 2018-03-13 13:42 GMT+01:00 Harbs :
> 
>> No. className is supposed to *replace* the entire classList minus the
>> internally managed ones (i.e. typeNames). Your code drastically changes the
>> current behavior.
>> 
>> You cannot use add for that and replacing the classList will destroy your
>> custom class names.
>> 
>>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Solving the multiple string value problem:
>>> 
>>> This: >> primary="true"/>
>>> 
>>> *PRIMARY*
>>> 
>>> with this change
>>> 
>>> COMPILE::JS
>>> protected function setClassName(value:String):void
>>> {
>>> var classes:Array = value.split(" ");
>>> element.classList.add.apply(element.classList, classes);
>>> }
>>> 
>>> I think this was all the problems we have right?
>>> 
>>> 
>>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira :
>>> 
 Hi Piotr,
 
 that's one of the advantages of a collection, order doesn't matter! :)
 
 
 
 output:
 
 *PRIMARY*
 
 this is one of the reason to change, since you'll end trying to figure
 what comes in first or not.
 
 Do you need more evidence?
 
 Thanks
 
 
 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki :
 
> In my example orders matters. Setup first className than your property.
> 
> 
> On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
> 
>> Hi Carlos,
>> 
>> I definitely appreciate the work you are doing. I’m swamped with work
>> right now, so I don’t have the time to spend helping you. (Sorry about
>> that.) :-(
>> 
>> I think the discussions here are about pretty minor points. You can
>> certainly implement jewel how you think makes sense, but if you want
>> to
>> make changes to basic in areas which are not broken, there needs to
>> be a
>> really good reason to do so.
>> 
>> My $0.02,
>> Harbs
>>> On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
>> wrote:
>>> 
>>> Hi Piotr,
>>> 
>>> thanks for your words, but is difficult to work on something when you
>>> believe in your vision and others no, and more over when all the
>> facts
>> you
>>> see corroborates that vision. It's difficult to maintain live the
> moto in
>>> that scenario.
>>> 
>>> but anyway for you Kindly words
>>> 
>>> Carlos
>>> 
>>> 
>>> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki > :
>>> 
 Carlos,
 
 In my opinion you are not facing the wall from US. You are facing
>> the
>> wall
 from lack of volounteers who can help, do the job.
 Believe me your Jewel effort in my list of tasks is almost on the
> Top. I
 have to fiinish planned work in TranspiledActionScript first and I
> hope
>> to
 join.
 
 When it will be - maybe in couple of weeks. In the end something
> have to
 pay the bills and Royale is only fraction of that.
 
 I contribute in other related areas. I Wish I could contribute in
> your
>> way
 or Alex and Peter.
 
 Thanks for your work!
 Piotr
 
 On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki <
> piotrzarzyck...@gmail.com>
 wrote:
 
> I personally said - Go and try, report back. I have gave you an
>> real
 world
> examples where classList failed. Try and post the results.
> 
> 2018-03-13 11:49 GMT+01:00 Carlos Rovira >> :
> 
>> Hi,
>> 
>> it's very hard to me to invest lot of time both in tryin 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

I think we're getting to the point in this discussion.

For me as a user, I expect to use className property to "add", and not
override all I have
for that reason in MDL and now in Royale we decided to create properties
(that use to be boolean) like "primary" or in MDL "fab" to add or remove
those properties (since are library properties that are managed
specifically).
I don't want to set primary and then className removes that! I think that
function is not right and will be the cause of many problems.

If the user wants to remove all class names, he can do with a method that
callls element.classList.remove, but the behavior by default shouldn't be
to use className to get rid of all what we have.

If you work with html directly , is normal to write class="class1 class2
..." and create from scratch

in Royale you write mxml and as3 and use className to add additional
classes that are not in the api but not to remove the ones the component
set plus the ones the user "switched" on/off due to properties



2018-03-13 13:42 GMT+01:00 Harbs :

> No. className is supposed to *replace* the entire classList minus the
> internally managed ones (i.e. typeNames). Your code drastically changes the
> current behavior.
>
> You cannot use add for that and replacing the classList will destroy your
> custom class names.
>
> > On Mar 13, 2018, at 2:34 PM, Carlos Rovira 
> wrote:
> >
> > Solving the multiple string value problem:
> >
> > This:  > primary="true"/>
> >
> > *PRIMARY*
> >
> > with this change
> >
> > COMPILE::JS
> > protected function setClassName(value:String):void
> > {
> > var classes:Array = value.split(" ");
> > element.classList.add.apply(element.classList, classes);
> > }
> >
> > I think this was all the problems we have right?
> >
> >
> > 2018-03-13 13:20 GMT+01:00 Carlos Rovira :
> >
> >> Hi Piotr,
> >>
> >> that's one of the advantages of a collection, order doesn't matter! :)
> >>
> >> 
> >>
> >> output:
> >>
> >> *PRIMARY*
> >>
> >> this is one of the reason to change, since you'll end trying to figure
> >> what comes in first or not.
> >>
> >> Do you need more evidence?
> >>
> >> Thanks
> >>
> >>
> >> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki :
> >>
> >>> In my example orders matters. Setup first className than your property.
> >>>
> >>>
> >>> On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
> >>>
>  Hi Carlos,
> 
>  I definitely appreciate the work you are doing. I’m swamped with work
>  right now, so I don’t have the time to spend helping you. (Sorry about
>  that.) :-(
> 
>  I think the discussions here are about pretty minor points. You can
>  certainly implement jewel how you think makes sense, but if you want
> to
>  make changes to basic in areas which are not broken, there needs to
> be a
>  really good reason to do so.
> 
>  My $0.02,
>  Harbs
> > On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
>  wrote:
> >
> > Hi Piotr,
> >
> > thanks for your words, but is difficult to work on something when you
> > believe in your vision and others no, and more over when all the
> facts
>  you
> > see corroborates that vision. It's difficult to maintain live the
> >>> moto in
> > that scenario.
> >
> > but anyway for you Kindly words
> >
> > Carlos
> >
> >
> > 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki   :
> >
> >> Carlos,
> >>
> >> In my opinion you are not facing the wall from US. You are facing
> the
>  wall
> >> from lack of volounteers who can help, do the job.
> >> Believe me your Jewel effort in my list of tasks is almost on the
> >>> Top. I
> >> have to fiinish planned work in TranspiledActionScript first and I
> >>> hope
>  to
> >> join.
> >>
> >> When it will be - maybe in couple of weeks. In the end something
> >>> have to
> >> pay the bills and Royale is only fraction of that.
> >>
> >> I contribute in other related areas. I Wish I could contribute in
> >>> your
>  way
> >> or Alex and Peter.
> >>
> >> Thanks for your work!
> >> Piotr
> >>
> >> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki <
> >>> piotrzarzyck...@gmail.com>
> >> wrote:
> >>
> >>> I personally said - Go and try, report back. I have gave you an
> real
> >> world
> >>> examples where classList failed. Try and post the results.
> >>>
> >>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira  >:
> >>>
>  Hi,
> 
>  it's very hard to me to invest lot of time both in tryin to
> develop
>  something useful in the look and feel field for us where no other
> >>> is
> >> doing
>  work, trying to explain and discuss all issues I find without get
> >>> any
>  traction. It's 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Harbs

2018-03-13 13:34 GMT+01:00 Harbs :

>
> I don’t think you understood what Piotr was saying.
>
> The order of setting the *property* and *className* matters. He was not
> talking about the order of class names in a class list.
>
>
I think is what I did right? change order of "primary" with "className" and
show that doesn't matter.
I was the first to find that problem in 2016 and report it, as I said.


>
> > I'm referring with this to "the theme feature" effort, where we want to
> > easily change appearance in a Royale UI set.
> > Right now we need to implement for each control 2 methods like the
> > followings (code from MDL)
> >
> > COMPILE::JS
> > private function addOrRemove(classNameVal:String,add:Boolean):void
> > {
> > add ? _classList.add(classNameVal) : _classList.remove(classNameVal);
> > }
> > COMPILE::JS
> > override protected function computeFinalClassNames():String
> > {
> > return _classList.compute() + super.computeFinalClassNames();
> > }
> >
> > and use
> >
> > COMPILE::JS
> > {
> > addOrRemove("mdl-js-ripple-effect",value);
> > setClassName(computeFinalClassNames());
> > }
> >
> > In my Jewel class I only do this (no additional methods or overrides)
> >
> > COMPILE::JS
> > {
> > element.classList.toggle("primary", value);
> > }
> >
> > and that's all :)
>
> Again, part of the strength of Royale is that we control the properties.
> Setting the DOM properties directly causes us to lose that.
>
>
Harbs, sincerily, don't understand what you are trying to say. If I want to
set a class, as a user (or even developer) I want to do that in the more
straight forward way I can



> You can probably optimize the code even more than it was already optimized:
>
>
> COMPILE::JS
> private function addOrRemove(classNameVal:String,add:Boolean):void
> {
> add ? _classList.add(classNameVal) : _classList.remove(classNameVal);
> setClassName(computeFinalClassNames());
> }
> COMPILE::JS
> override protected function computeFinalClassNames():String
> {
> return _classList.compute() + super.computeFinalClassNames();
> }
>
> and use
>
> COMPILE::JS
> {
> addOrRemove("mdl-js-ripple-effect",value);
> }
>
> Which is pretty close to your:
> COMPILE::JS
> {
> element.classList.toggle("primary", value);
> }
>

That's ok, but you still have the two functions around


>
> If you use this a lot, you can probably factor out the boilerplate code
> from your classes.
>
>
Right, for me that's a framework task



> Harbs




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

Re: Experiment with UIBase change to classList

[Harbs]

No. className is supposed to *replace* the entire classList minus the 
internally managed ones (i.e. typeNames). Your code drastically changes the 
current behavior.

You cannot use add for that and replacing the classList will destroy your 
custom class names.

> On Mar 13, 2018, at 2:34 PM, Carlos Rovira  wrote:
> 
> Solving the multiple string value problem:
> 
> This:  primary="true"/>
> 
> *PRIMARY*
> 
> with this change
> 
> COMPILE::JS
> protected function setClassName(value:String):void
> {
> var classes:Array = value.split(" ");
> element.classList.add.apply(element.classList, classes);
> }
> 
> I think this was all the problems we have right?
> 
> 
> 2018-03-13 13:20 GMT+01:00 Carlos Rovira :
> 
>> Hi Piotr,
>> 
>> that's one of the advantages of a collection, order doesn't matter! :)
>> 
>> 
>> 
>> output:
>> 
>> *PRIMARY*
>> 
>> this is one of the reason to change, since you'll end trying to figure
>> what comes in first or not.
>> 
>> Do you need more evidence?
>> 
>> Thanks
>> 
>> 
>> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki :
>> 
>>> In my example orders matters. Setup first className than your property.
>>> 
>>> 
>>> On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
>>> 
 Hi Carlos,
 
 I definitely appreciate the work you are doing. I’m swamped with work
 right now, so I don’t have the time to spend helping you. (Sorry about
 that.) :-(
 
 I think the discussions here are about pretty minor points. You can
 certainly implement jewel how you think makes sense, but if you want to
 make changes to basic in areas which are not broken, there needs to be a
 really good reason to do so.
 
 My $0.02,
 Harbs
> On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
 wrote:
> 
> Hi Piotr,
> 
> thanks for your words, but is difficult to work on something when you
> believe in your vision and others no, and more over when all the facts
 you
> see corroborates that vision. It's difficult to maintain live the
>>> moto in
> that scenario.
> 
> but anyway for you Kindly words
> 
> Carlos
> 
> 
> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki  
>> Carlos,
>> 
>> In my opinion you are not facing the wall from US. You are facing the
 wall
>> from lack of volounteers who can help, do the job.
>> Believe me your Jewel effort in my list of tasks is almost on the
>>> Top. I
>> have to fiinish planned work in TranspiledActionScript first and I
>>> hope
 to
>> join.
>> 
>> When it will be - maybe in couple of weeks. In the end something
>>> have to
>> pay the bills and Royale is only fraction of that.
>> 
>> I contribute in other related areas. I Wish I could contribute in
>>> your
 way
>> or Alex and Peter.
>> 
>> Thanks for your work!
>> Piotr
>> 
>> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki <
>>> piotrzarzyck...@gmail.com>
>> wrote:
>> 
>>> I personally said - Go and try, report back. I have gave you an real
>> world
>>> examples where classList failed. Try and post the results.
>>> 
>>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
>>> 
 Hi,
 
 it's very hard to me to invest lot of time both in tryin to develop
 something useful in the look and feel field for us where no other
>>> is
>> doing
 work, trying to explain and discuss all issues I find without get
>>> any
 traction. It's like to face a wall all the time.
 
 Maybe I'm wrong with my proposals but other times my perception is
 that
 things are settled in a particular way
 and we don't want to change it since is working in the current
>>> state.
>> But
 I
 think we always where thinking of change things as we evolve
>>> Royale.
>> We're
 in a 0.9.2 release, we're not in 1.0, but the way we're managing
>>> all
 issues
 seems to
 me that we're fine with what we have now and we are freezing the
>>> API.
 
 In all the issues raised last days only CSS compiler errors are
>>> real
>> bugs,
 since without that fixes royale can't output concrete CSS rules (I
 think
 those not require any discussion)
 
 The font injection is maybe another bug (don't know why a class in
>>> a
>> theme
 is not "visible" by the final app), but can be workarounded with an
 html
 that setup the font for now.
 
 Things like classNames discussion are not critical (I know), it's
 just a
 matter to refine the API since I had problems each time I go that
 path,
 first with MDL and now with Jewel. Maybe I'm the only one since no
 other

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Solving the multiple string value problem:

This: 

*PRIMARY*

with this change

COMPILE::JS
protected function setClassName(value:String):void
{
var classes:Array = value.split(" ");
element.classList.add.apply(element.classList, classes);
}

I think this was all the problems we have right?


2018-03-13 13:20 GMT+01:00 Carlos Rovira :

> Hi Piotr,
>
> that's one of the advantages of a collection, order doesn't matter! :)
>
> 
>
> output:
>
> *PRIMARY*
>
> this is one of the reason to change, since you'll end trying to figure
> what comes in first or not.
>
> Do you need more evidence?
>
> Thanks
>
>
> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki :
>
>> In my example orders matters. Setup first className than your property.
>>
>>
>> On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
>>
>> > Hi Carlos,
>> >
>> > I definitely appreciate the work you are doing. I’m swamped with work
>> > right now, so I don’t have the time to spend helping you. (Sorry about
>> > that.) :-(
>> >
>> > I think the discussions here are about pretty minor points. You can
>> > certainly implement jewel how you think makes sense, but if you want to
>> > make changes to basic in areas which are not broken, there needs to be a
>> > really good reason to do so.
>> >
>> > My $0.02,
>> > Harbs
>> > > On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
>> > wrote:
>> > >
>> > > Hi Piotr,
>> > >
>> > > thanks for your words, but is difficult to work on something when you
>> > > believe in your vision and others no, and more over when all the facts
>> > you
>> > > see corroborates that vision. It's difficult to maintain live the
>> moto in
>> > > that scenario.
>> > >
>> > > but anyway for you Kindly words
>> > >
>> > > Carlos
>> > >
>> > >
>> > > 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki > >:
>> > >
>> > >> Carlos,
>> > >>
>> > >> In my opinion you are not facing the wall from US. You are facing the
>> > wall
>> > >> from lack of volounteers who can help, do the job.
>> > >> Believe me your Jewel effort in my list of tasks is almost on the
>> Top. I
>> > >> have to fiinish planned work in TranspiledActionScript first and I
>> hope
>> > to
>> > >> join.
>> > >>
>> > >> When it will be - maybe in couple of weeks. In the end something
>> have to
>> > >> pay the bills and Royale is only fraction of that.
>> > >>
>> > >> I contribute in other related areas. I Wish I could contribute in
>> your
>> > way
>> > >> or Alex and Peter.
>> > >>
>> > >> Thanks for your work!
>> > >> Piotr
>> > >>
>> > >> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki <
>> piotrzarzyck...@gmail.com>
>> > >> wrote:
>> > >>
>> > >>> I personally said - Go and try, report back. I have gave you an real
>> > >> world
>> > >>> examples where classList failed. Try and post the results.
>> > >>>
>> > >>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
>> > >>>
>> >  Hi,
>> > 
>> >  it's very hard to me to invest lot of time both in tryin to develop
>> >  something useful in the look and feel field for us where no other
>> is
>> > >> doing
>> >  work, trying to explain and discuss all issues I find without get
>> any
>> >  traction. It's like to face a wall all the time.
>> > 
>> >  Maybe I'm wrong with my proposals but other times my perception is
>> > that
>> >  things are settled in a particular way
>> >  and we don't want to change it since is working in the current
>> state.
>> > >> But
>> >  I
>> >  think we always where thinking of change things as we evolve
>> Royale.
>> > >> We're
>> >  in a 0.9.2 release, we're not in 1.0, but the way we're managing
>> all
>> >  issues
>> >  seems to
>> >  me that we're fine with what we have now and we are freezing the
>> API.
>> > 
>> >  In all the issues raised last days only CSS compiler errors are
>> real
>> > >> bugs,
>> >  since without that fixes royale can't output concrete CSS rules (I
>> > think
>> >  those not require any discussion)
>> > 
>> >  The font injection is maybe another bug (don't know why a class in
>> a
>> > >> theme
>> >  is not "visible" by the final app), but can be workarounded with an
>> > html
>> >  that setup the font for now.
>> > 
>> >  Things like classNames discussion are not critical (I know), it's
>> > just a
>> >  matter to refine the API since I had problems each time I go that
>> > path,
>> >  first with MDL and now with Jewel. Maybe I'm the only one since no
>> > other
>> >  has tried what I'm trying to do: Creating Themes.
>> > 
>> >  In my opinion, give the users only a way to manage classNames vía
>> > >> string,
>> >  is insufficient and cumbersome and deserves at a minimun some API
>> > >> methods
>> >  since is an important point in how UI is stylized, and how controls
>> > and
>> >  objects in html can be "extended" or diferenciated 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Piotr,

that's one of the advantages of a collection, order doesn't matter! :)



output:

*PRIMARY*

this is one of the reason to change, since you'll end trying to figure what
comes in first or not.

Do you need more evidence?

Thanks


2018-03-13 12:48 GMT+01:00 Piotr Zarzycki :

> In my example orders matters. Setup first className than your property.
>
>
> On Tue, Mar 13, 2018, 12:39 Harbs  wrote:
>
> > Hi Carlos,
> >
> > I definitely appreciate the work you are doing. I’m swamped with work
> > right now, so I don’t have the time to spend helping you. (Sorry about
> > that.) :-(
> >
> > I think the discussions here are about pretty minor points. You can
> > certainly implement jewel how you think makes sense, but if you want to
> > make changes to basic in areas which are not broken, there needs to be a
> > really good reason to do so.
> >
> > My $0.02,
> > Harbs
> > > On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
> > wrote:
> > >
> > > Hi Piotr,
> > >
> > > thanks for your words, but is difficult to work on something when you
> > > believe in your vision and others no, and more over when all the facts
> > you
> > > see corroborates that vision. It's difficult to maintain live the moto
> in
> > > that scenario.
> > >
> > > but anyway for you Kindly words
> > >
> > > Carlos
> > >
> > >
> > > 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki :
> > >
> > >> Carlos,
> > >>
> > >> In my opinion you are not facing the wall from US. You are facing the
> > wall
> > >> from lack of volounteers who can help, do the job.
> > >> Believe me your Jewel effort in my list of tasks is almost on the
> Top. I
> > >> have to fiinish planned work in TranspiledActionScript first and I
> hope
> > to
> > >> join.
> > >>
> > >> When it will be - maybe in couple of weeks. In the end something have
> to
> > >> pay the bills and Royale is only fraction of that.
> > >>
> > >> I contribute in other related areas. I Wish I could contribute in your
> > way
> > >> or Alex and Peter.
> > >>
> > >> Thanks for your work!
> > >> Piotr
> > >>
> > >> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki  >
> > >> wrote:
> > >>
> > >>> I personally said - Go and try, report back. I have gave you an real
> > >> world
> > >>> examples where classList failed. Try and post the results.
> > >>>
> > >>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
> > >>>
> >  Hi,
> > 
> >  it's very hard to me to invest lot of time both in tryin to develop
> >  something useful in the look and feel field for us where no other is
> > >> doing
> >  work, trying to explain and discuss all issues I find without get
> any
> >  traction. It's like to face a wall all the time.
> > 
> >  Maybe I'm wrong with my proposals but other times my perception is
> > that
> >  things are settled in a particular way
> >  and we don't want to change it since is working in the current
> state.
> > >> But
> >  I
> >  think we always where thinking of change things as we evolve Royale.
> > >> We're
> >  in a 0.9.2 release, we're not in 1.0, but the way we're managing all
> >  issues
> >  seems to
> >  me that we're fine with what we have now and we are freezing the
> API.
> > 
> >  In all the issues raised last days only CSS compiler errors are real
> > >> bugs,
> >  since without that fixes royale can't output concrete CSS rules (I
> > think
> >  those not require any discussion)
> > 
> >  The font injection is maybe another bug (don't know why a class in a
> > >> theme
> >  is not "visible" by the final app), but can be workarounded with an
> > html
> >  that setup the font for now.
> > 
> >  Things like classNames discussion are not critical (I know), it's
> > just a
> >  matter to refine the API since I had problems each time I go that
> > path,
> >  first with MDL and now with Jewel. Maybe I'm the only one since no
> > other
> >  has tried what I'm trying to do: Creating Themes.
> > 
> >  In my opinion, give the users only a way to manage classNames vía
> > >> string,
> >  is insufficient and cumbersome and deserves at a minimun some API
> > >> methods
> >  since is an important point in how UI is stylized, and how controls
> > and
> >  objects in html can be "extended" or diferenciated (Alex explained
> > very
> >  well the importance of this in the typenames thread). So some API to
> > >> ease
> >  that is for me very Wellcome since I'm doing that work, and will be
> > more
> >  users doing that work. In this point, I don't think we should shield
> > us
> > >> in
> >  things like PAYG or if that is a bit less performant.
> > 
> >  To close and avoid having much discussion to not reach to some
> > valuable
> >  point:  I can try to go with what we have, but makes me feel not so
> > 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Harbs

2018-03-13 12:54 GMT+01:00 Harbs :

>
> > On Mar 13, 2018, at 1:48 PM, Carlos Rovira 
> wrote:
> >
> > Cause I'm dealing with this since 2016 with MDL?, if this is not enough
> > experience and time with an API, don't know what should I do to reflect
> > that is the part of Royale where I always move and maybe have the most
> > experience. I had to solve the problems that recently was solved by Alex
> > with themes in MDL when I reported it almost 2 years ago and finaly
> where a
> > bug, but at that time wasn't.
>
> What specifically are you referring to here? What problem are you trying
> to solve by changing the way class lists are handled?
>

in FlexJS list 26/11/2016 there 's a "[FlexJS] className manipulation", I
opened various problems to work with classNames when working in the MDL lib.
In that thread Josh Tynjala pointed to the classList solution, but at that
time we were targeting IE9 and was not an option.
In that thread and many others at that time I was having the same problems
we're having here about persistent classes, others that are "switchable"
and the last ones that are added by devs or users.
I'll end trying lots of things to solve the problem and finaly get to the
solution we have in MDL until some days ago Alex made changes and report
about the problem and Piotr made the changes in MDL. For me what I did at
that time always was a "hack" since I had to make very strange things to
support how MDL works (that's very near at how Jewel works, and maybe to
any other UI Set that wants to be *customizable* visuals). Now that
classList is no more a problem since we're targeting IE11, don't see the
problem to address this and solve it finaly to make it work as a framework
should



>
> >
> >> The general rule with live collections in general is to avoid them when
> >> possible. Collections need to be resolved which adds overhead. The less
> >> interactions with a DOM, the better. Native JS is almost always going to
> >> more efficient than browser/DOM APIs.
> >>
> >>
> > That's true, and I adhere to that mantra most of the times, but in this
> > case I think it's better, since:
> >
> > -Users will have a more easy way to do things (and that's one of the
> things
> > flex did really good)
>
> Can you give me an example where this makes a difference to users? (What
> “this” are you referring to?)
>

I'm referring with this to "the theme feature" effort, where we want to
easily change appearance in a Royale UI set.
Right now we need to implement for each control 2 methods like the
followings (code from MDL)

COMPILE::JS
private function addOrRemove(classNameVal:String,add:Boolean):void
{
add ? _classList.add(classNameVal) : _classList.remove(classNameVal);
}
COMPILE::JS
override protected function computeFinalClassNames():String
{
return _classList.compute() + super.computeFinalClassNames();
}

and use

COMPILE::JS
{
addOrRemove("mdl-js-ripple-effect",value);
setClassName(computeFinalClassNames());
}

In my Jewel class I only do this (no additional methods or overrides)

COMPILE::JS
{
element.classList.toggle("primary", value);
}

and that's all :)


> > -If there's an impact in performance, my guess is that will be minimal
> (but
> > can ensure since I don't have the data)
>
> I understood that your point was performance, so I’m confused.
>

No, what I say is that the API is browser based so it should be performant
enough. And we're not talking in this case about a huge process to handle,
we're talking about manage collections of 1 to maybe 2 to 6 elements and
running in concrete parts. What makes the process very affordable.


>
> Maybe a list of the issues you are struggling with might help me
> understand better what you are trying to accomplish. (and allow me to help)
>

Hope the things mentioned before will count as the list. I think I posted a
lot in FlexJS and now in Royale.
Maybe If you don't see it is because you're not using it as I do, but think
in users that will more in the UX front.

Thanks


>
> Thanks,
> Harbs




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

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Harbs

2018-03-13 12:39 GMT+01:00 Harbs :

> Hi Carlos,
>
> I definitely appreciate the work you are doing. I’m swamped with work
> right now, so I don’t have the time to spend helping you. (Sorry about
> that.) :-(
>
> Thanks Harbs, but don't worry, I think at this time is difficult to help
in this task until basic things are settled so we can go fast implementing
the rest of components. Maybe solving issues in compiler with CSS, or the
inject problem, but what I'm trying to do is to get ok with 1 or 2
components and then more people could enter to help.


> I think the discussions here are about pretty minor points. You can
> certainly implement jewel how you think makes sense, but if you want to
> make changes to basic in areas which are not broken, there needs to be a
> really good reason to do so.
>

Right, for this reason I'm trying to get consensus with what I'm trying to
do. Don't want to change something in core until all people here agree is
right. If finaly I think what I propose is the right choice, maybe I need
to fork in jewel those parts, but for me that seems not the right way to go
since for new comers that will be super strange, that some code in core
behaves in a way and a new UI set need to change it...seems weird, since
the core will be compromised or be not as valid, or not as core as it
should be...



>
> My $0.02,
> Harbs
> > On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
> wrote:
> >
> > Hi Piotr,
> >
> > thanks for your words, but is difficult to work on something when you
> > believe in your vision and others no, and more over when all the facts
> you
> > see corroborates that vision. It's difficult to maintain live the moto in
> > that scenario.
> >
> > but anyway for you Kindly words
> >
> > Carlos
> >
> >
> > 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki :
> >
> >> Carlos,
> >>
> >> In my opinion you are not facing the wall from US. You are facing the
> wall
> >> from lack of volounteers who can help, do the job.
> >> Believe me your Jewel effort in my list of tasks is almost on the Top. I
> >> have to fiinish planned work in TranspiledActionScript first and I hope
> to
> >> join.
> >>
> >> When it will be - maybe in couple of weeks. In the end something have to
> >> pay the bills and Royale is only fraction of that.
> >>
> >> I contribute in other related areas. I Wish I could contribute in your
> way
> >> or Alex and Peter.
> >>
> >> Thanks for your work!
> >> Piotr
> >>
> >> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki 
> >> wrote:
> >>
> >>> I personally said - Go and try, report back. I have gave you an real
> >> world
> >>> examples where classList failed. Try and post the results.
> >>>
> >>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
> >>>
>  Hi,
> 
>  it's very hard to me to invest lot of time both in tryin to develop
>  something useful in the look and feel field for us where no other is
> >> doing
>  work, trying to explain and discuss all issues I find without get any
>  traction. It's like to face a wall all the time.
> 
>  Maybe I'm wrong with my proposals but other times my perception is
> that
>  things are settled in a particular way
>  and we don't want to change it since is working in the current state.
> >> But
>  I
>  think we always where thinking of change things as we evolve Royale.
> >> We're
>  in a 0.9.2 release, we're not in 1.0, but the way we're managing all
>  issues
>  seems to
>  me that we're fine with what we have now and we are freezing the API.
> 
>  In all the issues raised last days only CSS compiler errors are real
> >> bugs,
>  since without that fixes royale can't output concrete CSS rules (I
> think
>  those not require any discussion)
> 
>  The font injection is maybe another bug (don't know why a class in a
> >> theme
>  is not "visible" by the final app), but can be workarounded with an
> html
>  that setup the font for now.
> 
>  Things like classNames discussion are not critical (I know), it's
> just a
>  matter to refine the API since I had problems each time I go that
> path,
>  first with MDL and now with Jewel. Maybe I'm the only one since no
> other
>  has tried what I'm trying to do: Creating Themes.
> 
>  In my opinion, give the users only a way to manage classNames vía
> >> string,
>  is insufficient and cumbersome and deserves at a minimun some API
> >> methods
>  since is an important point in how UI is stylized, and how controls
> and
>  objects in html can be "extended" or diferenciated (Alex explained
> very
>  well the importance of this in the typenames thread). So some API to
> >> ease
>  that is for me very Wellcome since I'm doing that work, and will be
> more
>  users doing that work. In this point, I don't think we should shield
> us
> >> in
> 

Re: Experiment with UIBase change to classList

[Harbs]

> On Mar 13, 2018, at 1:48 PM, Carlos Rovira  wrote:
> 
> Cause I'm dealing with this since 2016 with MDL?, if this is not enough
> experience and time with an API, don't know what should I do to reflect
> that is the part of Royale where I always move and maybe have the most
> experience. I had to solve the problems that recently was solved by Alex
> with themes in MDL when I reported it almost 2 years ago and finaly where a
> bug, but at that time wasn't.

What specifically are you referring to here? What problem are you trying to 
solve by changing the way class lists are handled?

> 
>> The general rule with live collections in general is to avoid them when
>> possible. Collections need to be resolved which adds overhead. The less
>> interactions with a DOM, the better. Native JS is almost always going to
>> more efficient than browser/DOM APIs.
>> 
>> 
> That's true, and I adhere to that mantra most of the times, but in this
> case I think it's better, since:
> 
> -Users will have a more easy way to do things (and that's one of the things
> flex did really good)

Can you give me an example where this makes a difference to users? (What “this” 
are you referring to?)

> -If there's an impact in performance, my guess is that will be minimal (but
> can ensure since I don't have the data)

I understood that your point was performance, so I’m confused.

Maybe a list of the issues you are struggling with might help me understand 
better what you are trying to accomplish. (and allow me to help)

Thanks,
Harbs

Re: Experiment with UIBase change to classList

[Piotr Zarzycki]

In my example orders matters. Setup first className than your property.


On Tue, Mar 13, 2018, 12:39 Harbs  wrote:

> Hi Carlos,
>
> I definitely appreciate the work you are doing. I’m swamped with work
> right now, so I don’t have the time to spend helping you. (Sorry about
> that.) :-(
>
> I think the discussions here are about pretty minor points. You can
> certainly implement jewel how you think makes sense, but if you want to
> make changes to basic in areas which are not broken, there needs to be a
> really good reason to do so.
>
> My $0.02,
> Harbs
> > On Mar 13, 2018, at 1:31 PM, Carlos Rovira 
> wrote:
> >
> > Hi Piotr,
> >
> > thanks for your words, but is difficult to work on something when you
> > believe in your vision and others no, and more over when all the facts
> you
> > see corroborates that vision. It's difficult to maintain live the moto in
> > that scenario.
> >
> > but anyway for you Kindly words
> >
> > Carlos
> >
> >
> > 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki :
> >
> >> Carlos,
> >>
> >> In my opinion you are not facing the wall from US. You are facing the
> wall
> >> from lack of volounteers who can help, do the job.
> >> Believe me your Jewel effort in my list of tasks is almost on the Top. I
> >> have to fiinish planned work in TranspiledActionScript first and I hope
> to
> >> join.
> >>
> >> When it will be - maybe in couple of weeks. In the end something have to
> >> pay the bills and Royale is only fraction of that.
> >>
> >> I contribute in other related areas. I Wish I could contribute in your
> way
> >> or Alex and Peter.
> >>
> >> Thanks for your work!
> >> Piotr
> >>
> >> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki 
> >> wrote:
> >>
> >>> I personally said - Go and try, report back. I have gave you an real
> >> world
> >>> examples where classList failed. Try and post the results.
> >>>
> >>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
> >>>
>  Hi,
> 
>  it's very hard to me to invest lot of time both in tryin to develop
>  something useful in the look and feel field for us where no other is
> >> doing
>  work, trying to explain and discuss all issues I find without get any
>  traction. It's like to face a wall all the time.
> 
>  Maybe I'm wrong with my proposals but other times my perception is
> that
>  things are settled in a particular way
>  and we don't want to change it since is working in the current state.
> >> But
>  I
>  think we always where thinking of change things as we evolve Royale.
> >> We're
>  in a 0.9.2 release, we're not in 1.0, but the way we're managing all
>  issues
>  seems to
>  me that we're fine with what we have now and we are freezing the API.
> 
>  In all the issues raised last days only CSS compiler errors are real
> >> bugs,
>  since without that fixes royale can't output concrete CSS rules (I
> think
>  those not require any discussion)
> 
>  The font injection is maybe another bug (don't know why a class in a
> >> theme
>  is not "visible" by the final app), but can be workarounded with an
> html
>  that setup the font for now.
> 
>  Things like classNames discussion are not critical (I know), it's
> just a
>  matter to refine the API since I had problems each time I go that
> path,
>  first with MDL and now with Jewel. Maybe I'm the only one since no
> other
>  has tried what I'm trying to do: Creating Themes.
> 
>  In my opinion, give the users only a way to manage classNames vía
> >> string,
>  is insufficient and cumbersome and deserves at a minimun some API
> >> methods
>  since is an important point in how UI is stylized, and how controls
> and
>  objects in html can be "extended" or diferenciated (Alex explained
> very
>  well the importance of this in the typenames thread). So some API to
> >> ease
>  that is for me very Wellcome since I'm doing that work, and will be
> more
>  users doing that work. In this point, I don't think we should shield
> us
> >> in
>  things like PAYG or if that is a bit less performant.
> 
>  To close and avoid having much discussion to not reach to some
> valuable
>  point:  I can try to go with what we have, but makes me feel not so
> good
>  about the continuous rejection of my proposals. As well, you are
> saying
>  that we should wait to what users demand...but I'm an user of the API,
> >> and
>  my perception as a "zero user" seems to be not valuable. Since I don't
> >> get
>  traction on this, I'll try to continue with what we have and report
> back
> 
> 
> 
> 
>  2018-03-13 9:24 GMT+01:00 Harbs :
> 
> > +1.
> >
> >> On Mar 13, 2018, at 10:08 AM, Alex Harui 
> > wrote:
> >>
> >> I am so sad 

Re: Experiment with UIBase change to classList

[Harbs]

FYI, here’s one article which discusses collections:
https://dev.opera.com/articles/efficient-javascript/ 


> On Mar 13, 2018, at 1:36 PM, Harbs  wrote:
> 
> I don’t know why you keep asserting this.
> 
> The general rule with live collections in general is to avoid them when 
> possible. Collections need to be resolved which adds overhead. The less 
> interactions with a DOM, the better. Native JS is almost always going to more 
> efficient than browser/DOM APIs.
> 
> My $0.02,
> Harbs
> 
>> On Mar 13, 2018, at 1:28 PM, Carlos Rovira > > wrote:
>> 
>> I have no doubt that this is far better that what we have right now since
>> code is managed by a browser API (that should fast) and code in our
>> libraries will be be lighter.
> 

Re: Experiment with UIBase change to classList

[Harbs]

Hi Carlos,

I definitely appreciate the work you are doing. I’m swamped with work right 
now, so I don’t have the time to spend helping you. (Sorry about that.) :-(

I think the discussions here are about pretty minor points. You can certainly 
implement jewel how you think makes sense, but if you want to make changes to 
basic in areas which are not broken, there needs to be a really good reason to 
do so.

My $0.02,
Harbs
> On Mar 13, 2018, at 1:31 PM, Carlos Rovira  wrote:
> 
> Hi Piotr,
> 
> thanks for your words, but is difficult to work on something when you
> believe in your vision and others no, and more over when all the facts you
> see corroborates that vision. It's difficult to maintain live the moto in
> that scenario.
> 
> but anyway for you Kindly words
> 
> Carlos
> 
> 
> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki :
> 
>> Carlos,
>> 
>> In my opinion you are not facing the wall from US. You are facing the wall
>> from lack of volounteers who can help, do the job.
>> Believe me your Jewel effort in my list of tasks is almost on the Top. I
>> have to fiinish planned work in TranspiledActionScript first and I hope to
>> join.
>> 
>> When it will be - maybe in couple of weeks. In the end something have to
>> pay the bills and Royale is only fraction of that.
>> 
>> I contribute in other related areas. I Wish I could contribute in your way
>> or Alex and Peter.
>> 
>> Thanks for your work!
>> Piotr
>> 
>> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki 
>> wrote:
>> 
>>> I personally said - Go and try, report back. I have gave you an real
>> world
>>> examples where classList failed. Try and post the results.
>>> 
>>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
>>> 
 Hi,
 
 it's very hard to me to invest lot of time both in tryin to develop
 something useful in the look and feel field for us where no other is
>> doing
 work, trying to explain and discuss all issues I find without get any
 traction. It's like to face a wall all the time.
 
 Maybe I'm wrong with my proposals but other times my perception is that
 things are settled in a particular way
 and we don't want to change it since is working in the current state.
>> But
 I
 think we always where thinking of change things as we evolve Royale.
>> We're
 in a 0.9.2 release, we're not in 1.0, but the way we're managing all
 issues
 seems to
 me that we're fine with what we have now and we are freezing the API.
 
 In all the issues raised last days only CSS compiler errors are real
>> bugs,
 since without that fixes royale can't output concrete CSS rules (I think
 those not require any discussion)
 
 The font injection is maybe another bug (don't know why a class in a
>> theme
 is not "visible" by the final app), but can be workarounded with an html
 that setup the font for now.
 
 Things like classNames discussion are not critical (I know), it's just a
 matter to refine the API since I had problems each time I go that path,
 first with MDL and now with Jewel. Maybe I'm the only one since no other
 has tried what I'm trying to do: Creating Themes.
 
 In my opinion, give the users only a way to manage classNames vía
>> string,
 is insufficient and cumbersome and deserves at a minimun some API
>> methods
 since is an important point in how UI is stylized, and how controls and
 objects in html can be "extended" or diferenciated (Alex explained very
 well the importance of this in the typenames thread). So some API to
>> ease
 that is for me very Wellcome since I'm doing that work, and will be more
 users doing that work. In this point, I don't think we should shield us
>> in
 things like PAYG or if that is a bit less performant.
 
 To close and avoid having much discussion to not reach to some valuable
 point:  I can try to go with what we have, but makes me feel not so good
 about the continuous rejection of my proposals. As well, you are saying
 that we should wait to what users demand...but I'm an user of the API,
>> and
 my perception as a "zero user" seems to be not valuable. Since I don't
>> get
 traction on this, I'll try to continue with what we have and report back
 
 
 
 
 2018-03-13 9:24 GMT+01:00 Harbs :
 
> +1.
> 
>> On Mar 13, 2018, at 10:08 AM, Alex Harui 
> wrote:
>> 
>> I am so sad and frustrated that we have spent so much time on
 managing a
>> set of strings.  I just don't think we have the people power to
 continue
>> to seek perfection until it is truly needed by a user.
> 
> 
 
 
 --
 Carlos Rovira
 http://about.me/carlosrovira
 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Piotr Zarzycki
>>> 
>>> Patreon: 

Re: Experiment with UIBase change to classList

[Harbs]

I don’t know why you keep asserting this.

The general rule with live collections in general is to avoid them when 
possible. Collections need to be resolved which adds overhead. The less 
interactions with a DOM, the better. Native JS is almost always going to more 
efficient than browser/DOM APIs.

My $0.02,
Harbs

> On Mar 13, 2018, at 1:28 PM, Carlos Rovira  wrote:
> 
> I have no doubt that this is far better that what we have right now since
> code is managed by a browser API (that should fast) and code in our
> libraries will be be lighter.

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Piotr,

thanks for your words, but is difficult to work on something when you
believe in your vision and others no, and more over when all the facts you
see corroborates that vision. It's difficult to maintain live the moto in
that scenario.

but anyway for you Kindly words

Carlos


2018-03-13 12:21 GMT+01:00 Piotr Zarzycki :

> Carlos,
>
> In my opinion you are not facing the wall from US. You are facing the wall
> from lack of volounteers who can help, do the job.
> Believe me your Jewel effort in my list of tasks is almost on the Top. I
> have to fiinish planned work in TranspiledActionScript first and I hope to
> join.
>
> When it will be - maybe in couple of weeks. In the end something have to
> pay the bills and Royale is only fraction of that.
>
> I contribute in other related areas. I Wish I could contribute in your way
> or Alex and Peter.
>
> Thanks for your work!
> Piotr
>
> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki 
> wrote:
>
> > I personally said - Go and try, report back. I have gave you an real
> world
> > examples where classList failed. Try and post the results.
> >
> > 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
> >
> >> Hi,
> >>
> >> it's very hard to me to invest lot of time both in tryin to develop
> >> something useful in the look and feel field for us where no other is
> doing
> >> work, trying to explain and discuss all issues I find without get any
> >> traction. It's like to face a wall all the time.
> >>
> >> Maybe I'm wrong with my proposals but other times my perception is that
> >> things are settled in a particular way
> >> and we don't want to change it since is working in the current state.
> But
> >> I
> >> think we always where thinking of change things as we evolve Royale.
> We're
> >> in a 0.9.2 release, we're not in 1.0, but the way we're managing all
> >> issues
> >> seems to
> >> me that we're fine with what we have now and we are freezing the API.
> >>
> >> In all the issues raised last days only CSS compiler errors are real
> bugs,
> >> since without that fixes royale can't output concrete CSS rules (I think
> >> those not require any discussion)
> >>
> >> The font injection is maybe another bug (don't know why a class in a
> theme
> >> is not "visible" by the final app), but can be workarounded with an html
> >> that setup the font for now.
> >>
> >> Things like classNames discussion are not critical (I know), it's just a
> >> matter to refine the API since I had problems each time I go that path,
> >> first with MDL and now with Jewel. Maybe I'm the only one since no other
> >> has tried what I'm trying to do: Creating Themes.
> >>
> >> In my opinion, give the users only a way to manage classNames vía
> string,
> >> is insufficient and cumbersome and deserves at a minimun some API
> methods
> >> since is an important point in how UI is stylized, and how controls and
> >> objects in html can be "extended" or diferenciated (Alex explained very
> >> well the importance of this in the typenames thread). So some API to
> ease
> >> that is for me very Wellcome since I'm doing that work, and will be more
> >> users doing that work. In this point, I don't think we should shield us
> in
> >> things like PAYG or if that is a bit less performant.
> >>
> >> To close and avoid having much discussion to not reach to some valuable
> >> point:  I can try to go with what we have, but makes me feel not so good
> >> about the continuous rejection of my proposals. As well, you are saying
> >> that we should wait to what users demand...but I'm an user of the API,
> and
> >> my perception as a "zero user" seems to be not valuable. Since I don't
> get
> >> traction on this, I'll try to continue with what we have and report back
> >>
> >>
> >>
> >>
> >> 2018-03-13 9:24 GMT+01:00 Harbs :
> >>
> >> > +1.
> >> >
> >> > > On Mar 13, 2018, at 10:08 AM, Alex Harui 
> >> > wrote:
> >> > >
> >> > > I am so sad and frustrated that we have spent so much time on
> >> managing a
> >> > > set of strings.  I just don't think we have the people power to
> >> continue
> >> > > to seek perfection until it is truly needed by a user.
> >> >
> >> >
> >>
> >>
> >> --
> >> Carlos Rovira
> >> http://about.me/carlosrovira
> >>
> >
> >
> >
> > --
> >
> > Piotr Zarzycki
> >
> > Patreon: *https://www.patreon.com/piotrzarzycki
> > *
> >
>



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

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Piotr,
just tested without do any other change to the code posted yesterday and is
working (what surprised me)



gives:


*PRIMARY*

what is completely right

what does not work is



that is what Alex said, and can be easily resolved with a if-else that
handles multiple classes in a string

I have no doubt that this is far better that what we have right now since
code is managed by a browser API (that should fast) and code in our
libraries will be be lighter.



2018-03-13 12:00 GMT+01:00 Piotr Zarzycki :

> I personally said - Go and try, report back. I have gave you an real world
> examples where classList failed. Try and post the results.
>
> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
>
> > Hi,
> >
> > it's very hard to me to invest lot of time both in tryin to develop
> > something useful in the look and feel field for us where no other is
> doing
> > work, trying to explain and discuss all issues I find without get any
> > traction. It's like to face a wall all the time.
> >
> > Maybe I'm wrong with my proposals but other times my perception is that
> > things are settled in a particular way
> > and we don't want to change it since is working in the current state.
> But I
> > think we always where thinking of change things as we evolve Royale.
> We're
> > in a 0.9.2 release, we're not in 1.0, but the way we're managing all
> issues
> > seems to
> > me that we're fine with what we have now and we are freezing the API.
> >
> > In all the issues raised last days only CSS compiler errors are real
> bugs,
> > since without that fixes royale can't output concrete CSS rules (I think
> > those not require any discussion)
> >
> > The font injection is maybe another bug (don't know why a class in a
> theme
> > is not "visible" by the final app), but can be workarounded with an html
> > that setup the font for now.
> >
> > Things like classNames discussion are not critical (I know), it's just a
> > matter to refine the API since I had problems each time I go that path,
> > first with MDL and now with Jewel. Maybe I'm the only one since no other
> > has tried what I'm trying to do: Creating Themes.
> >
> > In my opinion, give the users only a way to manage classNames vía string,
> > is insufficient and cumbersome and deserves at a minimun some API methods
> > since is an important point in how UI is stylized, and how controls and
> > objects in html can be "extended" or diferenciated (Alex explained very
> > well the importance of this in the typenames thread). So some API to ease
> > that is for me very Wellcome since I'm doing that work, and will be more
> > users doing that work. In this point, I don't think we should shield us
> in
> > things like PAYG or if that is a bit less performant.
> >
> > To close and avoid having much discussion to not reach to some valuable
> > point:  I can try to go with what we have, but makes me feel not so good
> > about the continuous rejection of my proposals. As well, you are saying
> > that we should wait to what users demand...but I'm an user of the API,
> and
> > my perception as a "zero user" seems to be not valuable. Since I don't
> get
> > traction on this, I'll try to continue with what we have and report back
> >
> >
> >
> >
> > 2018-03-13 9:24 GMT+01:00 Harbs :
> >
> > > +1.
> > >
> > > > On Mar 13, 2018, at 10:08 AM, Alex Harui 
> > > wrote:
> > > >
> > > > I am so sad and frustrated that we have spent so much time on
> managing
> > a
> > > > set of strings.  I just don't think we have the people power to
> > continue
> > > > to seek perfection until it is truly needed by a user.
> > >
> > >
> >
> >
> > --
> > Carlos Rovira
> > http://about.me/carlosrovira
> >
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>



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

Re: Experiment with UIBase change to classList

[Piotr Zarzycki]

Carlos,

In my opinion you are not facing the wall from US. You are facing the wall
from lack of volounteers who can help, do the job.
Believe me your Jewel effort in my list of tasks is almost on the Top. I
have to fiinish planned work in TranspiledActionScript first and I hope to
join.

When it will be - maybe in couple of weeks. In the end something have to
pay the bills and Royale is only fraction of that.

I contribute in other related areas. I Wish I could contribute in your way
or Alex and Peter.

Thanks for your work!
Piotr

On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki 
wrote:

> I personally said - Go and try, report back. I have gave you an real world
> examples where classList failed. Try and post the results.
>
> 2018-03-13 11:49 GMT+01:00 Carlos Rovira :
>
>> Hi,
>>
>> it's very hard to me to invest lot of time both in tryin to develop
>> something useful in the look and feel field for us where no other is doing
>> work, trying to explain and discuss all issues I find without get any
>> traction. It's like to face a wall all the time.
>>
>> Maybe I'm wrong with my proposals but other times my perception is that
>> things are settled in a particular way
>> and we don't want to change it since is working in the current state. But
>> I
>> think we always where thinking of change things as we evolve Royale. We're
>> in a 0.9.2 release, we're not in 1.0, but the way we're managing all
>> issues
>> seems to
>> me that we're fine with what we have now and we are freezing the API.
>>
>> In all the issues raised last days only CSS compiler errors are real bugs,
>> since without that fixes royale can't output concrete CSS rules (I think
>> those not require any discussion)
>>
>> The font injection is maybe another bug (don't know why a class in a theme
>> is not "visible" by the final app), but can be workarounded with an html
>> that setup the font for now.
>>
>> Things like classNames discussion are not critical (I know), it's just a
>> matter to refine the API since I had problems each time I go that path,
>> first with MDL and now with Jewel. Maybe I'm the only one since no other
>> has tried what I'm trying to do: Creating Themes.
>>
>> In my opinion, give the users only a way to manage classNames vía string,
>> is insufficient and cumbersome and deserves at a minimun some API methods
>> since is an important point in how UI is stylized, and how controls and
>> objects in html can be "extended" or diferenciated (Alex explained very
>> well the importance of this in the typenames thread). So some API to ease
>> that is for me very Wellcome since I'm doing that work, and will be more
>> users doing that work. In this point, I don't think we should shield us in
>> things like PAYG or if that is a bit less performant.
>>
>> To close and avoid having much discussion to not reach to some valuable
>> point:  I can try to go with what we have, but makes me feel not so good
>> about the continuous rejection of my proposals. As well, you are saying
>> that we should wait to what users demand...but I'm an user of the API, and
>> my perception as a "zero user" seems to be not valuable. Since I don't get
>> traction on this, I'll try to continue with what we have and report back
>>
>>
>>
>>
>> 2018-03-13 9:24 GMT+01:00 Harbs :
>>
>> > +1.
>> >
>> > > On Mar 13, 2018, at 10:08 AM, Alex Harui 
>> > wrote:
>> > >
>> > > I am so sad and frustrated that we have spent so much time on
>> managing a
>> > > set of strings.  I just don't think we have the people power to
>> continue
>> > > to seek perfection until it is truly needed by a user.
>> >
>> >
>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira
>>
>
>
>
> --
>
> Piotr Zarzycki
>
> Patreon: *https://www.patreon.com/piotrzarzycki
> *
>

Re: Experiment with UIBase change to classList

[Piotr Zarzycki]

I personally said - Go and try, report back. I have gave you an real world
examples where classList failed. Try and post the results.

2018-03-13 11:49 GMT+01:00 Carlos Rovira :

> Hi,
>
> it's very hard to me to invest lot of time both in tryin to develop
> something useful in the look and feel field for us where no other is doing
> work, trying to explain and discuss all issues I find without get any
> traction. It's like to face a wall all the time.
>
> Maybe I'm wrong with my proposals but other times my perception is that
> things are settled in a particular way
> and we don't want to change it since is working in the current state. But I
> think we always where thinking of change things as we evolve Royale. We're
> in a 0.9.2 release, we're not in 1.0, but the way we're managing all issues
> seems to
> me that we're fine with what we have now and we are freezing the API.
>
> In all the issues raised last days only CSS compiler errors are real bugs,
> since without that fixes royale can't output concrete CSS rules (I think
> those not require any discussion)
>
> The font injection is maybe another bug (don't know why a class in a theme
> is not "visible" by the final app), but can be workarounded with an html
> that setup the font for now.
>
> Things like classNames discussion are not critical (I know), it's just a
> matter to refine the API since I had problems each time I go that path,
> first with MDL and now with Jewel. Maybe I'm the only one since no other
> has tried what I'm trying to do: Creating Themes.
>
> In my opinion, give the users only a way to manage classNames vía string,
> is insufficient and cumbersome and deserves at a minimun some API methods
> since is an important point in how UI is stylized, and how controls and
> objects in html can be "extended" or diferenciated (Alex explained very
> well the importance of this in the typenames thread). So some API to ease
> that is for me very Wellcome since I'm doing that work, and will be more
> users doing that work. In this point, I don't think we should shield us in
> things like PAYG or if that is a bit less performant.
>
> To close and avoid having much discussion to not reach to some valuable
> point:  I can try to go with what we have, but makes me feel not so good
> about the continuous rejection of my proposals. As well, you are saying
> that we should wait to what users demand...but I'm an user of the API, and
> my perception as a "zero user" seems to be not valuable. Since I don't get
> traction on this, I'll try to continue with what we have and report back
>
>
>
>
> 2018-03-13 9:24 GMT+01:00 Harbs :
>
> > +1.
> >
> > > On Mar 13, 2018, at 10:08 AM, Alex Harui 
> > wrote:
> > >
> > > I am so sad and frustrated that we have spent so much time on managing
> a
> > > set of strings.  I just don't think we have the people power to
> continue
> > > to seek perfection until it is truly needed by a user.
> >
> >
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi,

it's very hard to me to invest lot of time both in tryin to develop
something useful in the look and feel field for us where no other is doing
work, trying to explain and discuss all issues I find without get any
traction. It's like to face a wall all the time.

Maybe I'm wrong with my proposals but other times my perception is that
things are settled in a particular way
and we don't want to change it since is working in the current state. But I
think we always where thinking of change things as we evolve Royale. We're
in a 0.9.2 release, we're not in 1.0, but the way we're managing all issues
seems to
me that we're fine with what we have now and we are freezing the API.

In all the issues raised last days only CSS compiler errors are real bugs,
since without that fixes royale can't output concrete CSS rules (I think
those not require any discussion)

The font injection is maybe another bug (don't know why a class in a theme
is not "visible" by the final app), but can be workarounded with an html
that setup the font for now.

Things like classNames discussion are not critical (I know), it's just a
matter to refine the API since I had problems each time I go that path,
first with MDL and now with Jewel. Maybe I'm the only one since no other
has tried what I'm trying to do: Creating Themes.

In my opinion, give the users only a way to manage classNames vía string,
is insufficient and cumbersome and deserves at a minimun some API methods
since is an important point in how UI is stylized, and how controls and
objects in html can be "extended" or diferenciated (Alex explained very
well the importance of this in the typenames thread). So some API to ease
that is for me very Wellcome since I'm doing that work, and will be more
users doing that work. In this point, I don't think we should shield us in
things like PAYG or if that is a bit less performant.

To close and avoid having much discussion to not reach to some valuable
point:  I can try to go with what we have, but makes me feel not so good
about the continuous rejection of my proposals. As well, you are saying
that we should wait to what users demand...but I'm an user of the API, and
my perception as a "zero user" seems to be not valuable. Since I don't get
traction on this, I'll try to continue with what we have and report back




2018-03-13 9:24 GMT+01:00 Harbs :

> +1.
>
> > On Mar 13, 2018, at 10:08 AM, Alex Harui 
> wrote:
> >
> > I am so sad and frustrated that we have spent so much time on managing a
> > set of strings.  I just don't think we have the people power to continue
> > to seek perfection until it is truly needed by a user.
>
>


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

Re: Experiment with UIBase change to classList

[Piotr Zarzycki]

Carlos,

The thing is that we are loosing our time here. We were discussing
solutions for that in the separate thread - it took as more than 60 emails.
It's starting again. You have something which is working, it's require to
add your custom logic in the component. Building a component end up with
custom logic - in most cases.

Please test your solutions and let us know where you end up. This
discussion is never ending story.

On the users mailing list Alina is having problems with Maven build. She is
trying to port Large application to Royale. It is our huge opportunity to
boost Royale to the next level.

Why not moving forward with current solution - once you get set of your
components ready - Improve things.

I bet you will end up with much more crucial problems than why we are using
custom List to manage className instead of build one. - I'm all for build
one Carlos! But the thing is I have spent three days on doing something
with the build one and end up with Harb's solution.

Thanks, Piotr


2018-03-13 8:38 GMT+01:00 Carlos Rovira :

> Hi Alex,
>
> ok, I saw the problems of using a list as I was creating it for that reason
> I try to do this as easy.
>
> to solve that  we can introduce a few lines more that handles strings. This
> will be less code that current solution and handle both possibilities is
> done in more parts of the framework so I think is still PAYG
> (we change two vars for one var that handle an incoming string or a list
> item, less API han more clear vs a "if-else" processing)
>
> If this is not ok, maybe we could explore a pluggable way for this? I mean,
> we all find this is problematic and we're fighting with this long time
> since I found it in MDL. Actual solutions continues to be a problem since
> or make us (library developers) to introduce su much redundant code (MDL
> and Jewel has 2 functions per class to handle this what for me is not
> something fine, since this is a framework thing ). and affects to how html
> output is created (that is important to me).
>
> So why not do this as a pluggable solutions the same way we have
> CSSValuenImpl or others out there and I can put a bead at app level that
> handles this in a particular way?
> (SimpleClassNameManagement and ClassListClassNameManagement or the way we
> want to name it)
>
> What seems to be clear is that :
>
> 1.- this part is conflictive
> 2.- in the actual way it makes sub libraries to add lots of functions per
> component to manage the actual scenario with classes
> 3.- we're divided on how to solve this, but we don't need to take one
> solution over another since for that reason we are creating a very modular
> framework, but in this part is not modular
>
> Thoughts?
>
> Carlos
>
>
> 2018-03-13 5:48 GMT+01:00 Alex Harui :
>
> > Hi Carlos,
> >
> > classList was not used earlier because Arrays are cumbersome in MXML.
> >
> > In MXML, folks can add more than one class using space delimited list of
> > strings:
> >
> > 
> >
> > In AS, folks can delete classnames via:
> >
> > myLabel.className="SmallFont";
> >
> > I don't believe your proposal takes these scenarios into account.
> >
> > Thanks,
> > -Alex
> >
> > On 3/12/18, 4:04 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >  wrote:
> >
> > >Hi,
> > >
> > >I made a branch from jewel branch to try UIBase for you to check
> > >(feature/uibase-classlist).
> > >
> > >My thinking is that classList simplifies all a lot since is a managed
> list
> > >with steroids that is made for you to use.
> > >I suppose that when FlexJS was started this API was not known or known
> but
> > >can't be used due to IE limittations.
> > >
> > >To make the experiment I copied UIBase to Jewel library *as is* and make
> > >the changes.
> > >
> > >For me the change is as simple as this:
> > >
> > >private var _className:String;
> > >
> > >/**
> > >* The classname. Often used for CSS
> > >* class selector lookups.
> > >*
> > >* @langversion 3.0
> > >* @playerversion Flash 10.2
> > >* @playerversion AIR 2.6
> > >* @productversion Royale 0.0
> > >*/
> > >public function get className():String
> > >{
> > >return _className;
> > >}
> > >
> > >/**
> > >* @private
> > >*/
> > >public function set className(value:String):void
> > >{
> > >if (_className !== value)
> > >{
> > >_className = value;
> > >
> > >COMPILE::JS
> > >{
> > >setClassName(_className);
> > >}
> > >dispatchEvent(new Event("classNameChanged"));
> > >}
> > >}
> > >
> > >COMPILE::JS
> > >protected function setClassName(value:String):void
> > >{
> > >element.classList.add(value);
> > >}
> > >
> > >this is a first iteration, maybe things can be do better, even simpler.
> > >no more tricky complex things with typenames and classnames
> > >
> > >
> > >you simply add to classlist, or if want to remove call directly
> > >"element.classList.remove", or toggle, or contains.
> > >
> > >I 

Re: Experiment with UIBase change to classList

[Carlos Rovira]

Hi Alex,

ok, I saw the problems of using a list as I was creating it for that reason
I try to do this as easy.

to solve that  we can introduce a few lines more that handles strings. This
will be less code that current solution and handle both possibilities is
done in more parts of the framework so I think is still PAYG
(we change two vars for one var that handle an incoming string or a list
item, less API han more clear vs a "if-else" processing)

If this is not ok, maybe we could explore a pluggable way for this? I mean,
we all find this is problematic and we're fighting with this long time
since I found it in MDL. Actual solutions continues to be a problem since
or make us (library developers) to introduce su much redundant code (MDL
and Jewel has 2 functions per class to handle this what for me is not
something fine, since this is a framework thing ). and affects to how html
output is created (that is important to me).

So why not do this as a pluggable solutions the same way we have
CSSValuenImpl or others out there and I can put a bead at app level that
handles this in a particular way?
(SimpleClassNameManagement and ClassListClassNameManagement or the way we
want to name it)

What seems to be clear is that :

1.- this part is conflictive
2.- in the actual way it makes sub libraries to add lots of functions per
component to manage the actual scenario with classes
3.- we're divided on how to solve this, but we don't need to take one
solution over another since for that reason we are creating a very modular
framework, but in this part is not modular

Thoughts?

Carlos


2018-03-13 5:48 GMT+01:00 Alex Harui :

> Hi Carlos,
>
> classList was not used earlier because Arrays are cumbersome in MXML.
>
> In MXML, folks can add more than one class using space delimited list of
> strings:
>
> 
>
> In AS, folks can delete classnames via:
>
> myLabel.className="SmallFont";
>
> I don't believe your proposal takes these scenarios into account.
>
> Thanks,
> -Alex
>
> On 3/12/18, 4:04 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi,
> >
> >I made a branch from jewel branch to try UIBase for you to check
> >(feature/uibase-classlist).
> >
> >My thinking is that classList simplifies all a lot since is a managed list
> >with steroids that is made for you to use.
> >I suppose that when FlexJS was started this API was not known or known but
> >can't be used due to IE limittations.
> >
> >To make the experiment I copied UIBase to Jewel library *as is* and make
> >the changes.
> >
> >For me the change is as simple as this:
> >
> >private var _className:String;
> >
> >/**
> >* The classname. Often used for CSS
> >* class selector lookups.
> >*
> >* @langversion 3.0
> >* @playerversion Flash 10.2
> >* @playerversion AIR 2.6
> >* @productversion Royale 0.0
> >*/
> >public function get className():String
> >{
> >return _className;
> >}
> >
> >/**
> >* @private
> >*/
> >public function set className(value:String):void
> >{
> >if (_className !== value)
> >{
> >_className = value;
> >
> >COMPILE::JS
> >{
> >setClassName(_className);
> >}
> >dispatchEvent(new Event("classNameChanged"));
> >}
> >}
> >
> >COMPILE::JS
> >protected function setClassName(value:String):void
> >{
> >element.classList.add(value);
> >}
> >
> >this is a first iteration, maybe things can be do better, even simpler.
> >no more tricky complex things with typenames and classnames
> >
> >
> >you simply add to classlist, or if want to remove call directly
> >"element.classList.remove", or toggle, or contains.
> >
> >I have it working my example in that branch and code simplifies greatly.
> >
> >(only buttons, since the rest of controls are still without changes)
> >
> >this even made what Alex want with "typeNames" since, If I added a class
> >"Button", when I extend, it remains without do nothing
> >
> >to add "primary" or remove, I only need one line of code:
> >
> >element.classList.toggle("primary", value);
> >
> >So, what do you think? I know this can be a huge change in Royale, but is
> >something cumbersome in the actual state, or I had to fight with it in
> >MDL,
> >now Harbs, Piotr and all people going that is having trouble and wasting
> >time.
> >
> >Maybe it could be better to just make this change and make Royale more
> >easy
> >to change styles without not much hassle.
> >
> >All I see are benefits:
> >
> >* API is in the browser build-in, so I think it will be performant
> >* removes lots of inefficient code that is cumbersome
> >* makes API more easy
> >* removes the need to have typeNames and classNames since we have
> >persistent class just out-of-the-box
> >* we get all the api without the need to add it
> >(add/remove/contains/toggle)
> >* it's supported in all browsers we target
> >* is totaly PAYG
> >
> >Please, let me know what do you think. I'll read it tomorrow since I'm
> >closing for today
> >

Re: Experiment with UIBase change to classList

[Alex Harui]

Hi Carlos,

classList was not used earlier because Arrays are cumbersome in MXML.

In MXML, folks can add more than one class using space delimited list of
strings:



In AS, folks can delete classnames via:

myLabel.className="SmallFont";

I don't believe your proposal takes these scenarios into account.

Thanks,
-Alex

On 3/12/18, 4:04 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi,
>
>I made a branch from jewel branch to try UIBase for you to check
>(feature/uibase-classlist).
>
>My thinking is that classList simplifies all a lot since is a managed list
>with steroids that is made for you to use.
>I suppose that when FlexJS was started this API was not known or known but
>can't be used due to IE limittations.
>
>To make the experiment I copied UIBase to Jewel library *as is* and make
>the changes.
>
>For me the change is as simple as this:
>
>private var _className:String;
>
>/**
>* The classname. Often used for CSS
>* class selector lookups.
>*
>* @langversion 3.0
>* @playerversion Flash 10.2
>* @playerversion AIR 2.6
>* @productversion Royale 0.0
>*/
>public function get className():String
>{
>return _className;
>}
>
>/**
>* @private
>*/
>public function set className(value:String):void
>{
>if (_className !== value)
>{
>_className = value;
>
>COMPILE::JS
>{
>setClassName(_className);
>}
>dispatchEvent(new Event("classNameChanged"));
>}
>}
>
>COMPILE::JS
>protected function setClassName(value:String):void
>{
>element.classList.add(value);
>}
>
>this is a first iteration, maybe things can be do better, even simpler.
>no more tricky complex things with typenames and classnames
>
>
>you simply add to classlist, or if want to remove call directly
>"element.classList.remove", or toggle, or contains.
>
>I have it working my example in that branch and code simplifies greatly.
>
>(only buttons, since the rest of controls are still without changes)
>
>this even made what Alex want with "typeNames" since, If I added a class
>"Button", when I extend, it remains without do nothing
>
>to add "primary" or remove, I only need one line of code:
>
>element.classList.toggle("primary", value);
>
>So, what do you think? I know this can be a huge change in Royale, but is
>something cumbersome in the actual state, or I had to fight with it in
>MDL,
>now Harbs, Piotr and all people going that is having trouble and wasting
>time.
>
>Maybe it could be better to just make this change and make Royale more
>easy
>to change styles without not much hassle.
>
>All I see are benefits:
>
>* API is in the browser build-in, so I think it will be performant
>* removes lots of inefficient code that is cumbersome
>* makes API more easy
>* removes the need to have typeNames and classNames since we have
>persistent class just out-of-the-box
>* we get all the api without the need to add it
>(add/remove/contains/toggle)
>* it's supported in all browsers we target
>* is totaly PAYG
>
>Please, let me know what do you think. I'll read it tomorrow since I'm
>closing for today
>
>Thanks
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C3c0a0cd0210e45ecbae208d5
>886dacbc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636564926990512873
>data=4sznARhAbaYEIF60rTmfSOsj9gSU1BZhYE18cUgIELU%3D=0

Re: Experiment with UIBase change to classList

[Piotr Zarzycki]

Carlos,

I don't see in your examples things which I've asked you in the previous
thread. Let me ask you once again. Please test with your code following
example.

1) Create custom style.

.myCustomStyle
{
   fontSize: 12px;
   /// some style whatever
}

2. Set in your example



Compile and check whether custom class is setup, along with typeNames and
primary in output html. Let me know. Thanks, Piotr



2018-03-13 0:04 GMT+01:00 Carlos Rovira :

> Hi,
>
> I made a branch from jewel branch to try UIBase for you to check
> (feature/uibase-classlist).
>
> My thinking is that classList simplifies all a lot since is a managed list
> with steroids that is made for you to use.
> I suppose that when FlexJS was started this API was not known or known but
> can't be used due to IE limittations.
>
> To make the experiment I copied UIBase to Jewel library *as is* and make
> the changes.
>
> For me the change is as simple as this:
>
> private var _className:String;
>
> /**
> * The classname. Often used for CSS
> * class selector lookups.
> *
> * @langversion 3.0
> * @playerversion Flash 10.2
> * @playerversion AIR 2.6
> * @productversion Royale 0.0
> */
> public function get className():String
> {
> return _className;
> }
>
> /**
> * @private
> */
> public function set className(value:String):void
> {
> if (_className !== value)
> {
> _className = value;
>
> COMPILE::JS
> {
> setClassName(_className);
> }
> dispatchEvent(new Event("classNameChanged"));
> }
> }
>
> COMPILE::JS
> protected function setClassName(value:String):void
> {
> element.classList.add(value);
> }
>
> this is a first iteration, maybe things can be do better, even simpler.
> no more tricky complex things with typenames and classnames
>
>
> you simply add to classlist, or if want to remove call directly
> "element.classList.remove", or toggle, or contains.
>
> I have it working my example in that branch and code simplifies greatly.
>
> (only buttons, since the rest of controls are still without changes)
>
> this even made what Alex want with "typeNames" since, If I added a class
> "Button", when I extend, it remains without do nothing
>
> to add "primary" or remove, I only need one line of code:
>
> element.classList.toggle("primary", value);
>
> So, what do you think? I know this can be a huge change in Royale, but is
> something cumbersome in the actual state, or I had to fight with it in MDL,
> now Harbs, Piotr and all people going that is having trouble and wasting
> time.
>
> Maybe it could be better to just make this change and make Royale more easy
> to change styles without not much hassle.
>
> All I see are benefits:
>
> * API is in the browser build-in, so I think it will be performant
> * removes lots of inefficient code that is cumbersome
> * makes API more easy
> * removes the need to have typeNames and classNames since we have
> persistent class just out-of-the-box
> * we get all the api without the need to add it
> (add/remove/contains/toggle)
> * it's supported in all browsers we target
> * is totaly PAYG
>
> Please, let me know what do you think. I'll read it tomorrow since I'm
> closing for today
>
> Thanks
>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira
>



-- 

Piotr Zarzycki

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