Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Yes, I am hopeful we can move forward from here (probably with some bug
fixes).

Thanks,
-Alex

On 4/17/18, 1:21 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>if it works for this components I think it should be ok. Anyway if I find
>some problems we can comment at that moments. Don't think so.
>
>So, I can assume that you end this work and I can try to work from that?
>
>thanks
>
>
>
>2018-04-17 10:01 GMT+02:00 Alex Harui :
>
>> I integrated the same pattern in Jewel's Button, CheckBox, RadioButton
>>and
>> Slider.  This indicates that it can be implemented in a common base
>>class
>> for these components.  The example looks ok to me.
>>
>> The code assumes positioner.  For Button, if there is no hierarchy, then
>> positioner and element should be the same so it should work.  If it
>>turns
>> out there are still going to be exceptions that don't work, then we
>>might
>> need to introduce a "styleTarget" property in the Jewel base class that
>> createElement can assign and ClassSelectorList will use instead of
>> positioner.
>>
>> HTH,
>> -Alex
>>
>> On 4/16/18, 9:46 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi Alex,
>> >
>> >for me is ok to have it in JewelUIBase,
>> >in the other hand to look at what I tried to say with "positioner" vs
>> >"element" to apply class selectors, take a look at Jewel CheckBox (that
>> >will be refactored to extend JewelUIBase instead of current Basic
>> >CheckBox,
>> >like the rest of components). In create element the element in an input
>> >and
>> >the positioner is a label so setClassName is overriden to apply styles
>>to
>> >positioner
>> >
>> >COMPILE::JS
>> >override protected function setClassName(value:String):void
>> >{
>> >addStyles(positioner, value);
>> >}
>> >
>> >in contrast Button will be using element instead since there's no
>>wrapper.
>> >Button is its own wrapper
>> >
>> >thanks
>> >
>> >
>> >2018-04-16 18:27 GMT+02:00 Alex Harui :
>> >
>> >> Hi Carlos,
>> >>
>> >> Again, let's be specific and not over-state the scenarios.  I do not
>> >> believe that absolutely all JS development is focused on class
>> >>selectors,
>> >> otherwise there would be more articles about that practice.  And,
>>while
>> >>I
>> >> don't doubt that the "setting properties that affect visuals" might
>>need
>> >> to access elements instead of just the positioner, I would expect the
>> >> component to be an abstraction to the developer so when they choose
>>"a
>> >>set
>> >> of groups of styles" it would always apply to the positioner.  They
>> >>should
>> >> not have to know the internal "sub-DOM" of the component.
>> >>
>> >> After thinking about it more, I agree with Piotr that
>>ClassListSelector
>> >> should not be baked into UIBase.  Your recommendation that it should
>>be
>> >> implies that you are still thinking in the Flex mindset.  In Royale,
>> >>PAYG
>> >> is an important principle, and your arguments below basically
>>describe
>> >> "just-in-case" which is not PAYG.  It might be that a JewelUIBase
>>would
>> >> integrate ClassListSelector.  I will try to code that up today so we
>>can
>> >> see how that feels.
>> >>
>> >> Royale does want to make things easy, but, IMO, PAYG is more
>>important
>> >> than easy.  Flex put easy as more important than PAYG, and while that
>> >> might have helped Flex gain popularity more quickly, in the end, Flex
>> >> began having size and performance problems.  I do not want to repeat
>> >>that
>> >> mistake with Royale.  It doesn't matter how easy it is to get
>>started if
>> >> you can't finish.  There has to be the right balance.
>> >>
>> >> My 2 cents,
>> >> -Alex
>> >>
>> >> On 4/16/18, 4:33 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >>Rovira"
>> >>  wrote:
>> >>
>> >> >Hi,
>> >> >
>> >> >ClassListSelector could be ok, but think that depending on the
>> >>components
>> >> >in both MDL and JEWEL the class selector names added/removed/toggled
>> >>could
>> >> >go to positioner or to element. There's various examples of this in
>> >>each
>> >> >library. We should not lost that capability since is key.
>> >> >
>> >> >In order to bake in UIBase, my opinion is that devs will use this a
>> >>lot in
>> >> >their apps, so for me I'm ok to have it.
>> >> >If it was an API partially used, I'd think about it, but actual JS
>> >> >development is so much focused in add/remove class selectors.
>> >> >
>> >> >I'll be waiting for the final touches
>> >> >
>> >> >thanks Alex for working on this, and sorry if I'm a bit focused but
>>I
>> >> >think
>> >> >this point is important since in Royale we try to make easy things
>>and
>> >> >encapsulate best practices and code, and this seems to me something
>> >>that

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,
if it works for this components I think it should be ok. Anyway if I find
some problems we can comment at that moments. Don't think so.

So, I can assume that you end this work and I can try to work from that?

thanks



2018-04-17 10:01 GMT+02:00 Alex Harui :

> I integrated the same pattern in Jewel's Button, CheckBox, RadioButton and
> Slider.  This indicates that it can be implemented in a common base class
> for these components.  The example looks ok to me.
>
> The code assumes positioner.  For Button, if there is no hierarchy, then
> positioner and element should be the same so it should work.  If it turns
> out there are still going to be exceptions that don't work, then we might
> need to introduce a "styleTarget" property in the Jewel base class that
> createElement can assign and ClassSelectorList will use instead of
> positioner.
>
> HTH,
> -Alex
>
> On 4/16/18, 9:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >for me is ok to have it in JewelUIBase,
> >in the other hand to look at what I tried to say with "positioner" vs
> >"element" to apply class selectors, take a look at Jewel CheckBox (that
> >will be refactored to extend JewelUIBase instead of current Basic
> >CheckBox,
> >like the rest of components). In create element the element in an input
> >and
> >the positioner is a label so setClassName is overriden to apply styles to
> >positioner
> >
> >COMPILE::JS
> >override protected function setClassName(value:String):void
> >{
> >addStyles(positioner, value);
> >}
> >
> >in contrast Button will be using element instead since there's no wrapper.
> >Button is its own wrapper
> >
> >thanks
> >
> >
> >2018-04-16 18:27 GMT+02:00 Alex Harui :
> >
> >> Hi Carlos,
> >>
> >> Again, let's be specific and not over-state the scenarios.  I do not
> >> believe that absolutely all JS development is focused on class
> >>selectors,
> >> otherwise there would be more articles about that practice.  And, while
> >>I
> >> don't doubt that the "setting properties that affect visuals" might need
> >> to access elements instead of just the positioner, I would expect the
> >> component to be an abstraction to the developer so when they choose "a
> >>set
> >> of groups of styles" it would always apply to the positioner.  They
> >>should
> >> not have to know the internal "sub-DOM" of the component.
> >>
> >> After thinking about it more, I agree with Piotr that ClassListSelector
> >> should not be baked into UIBase.  Your recommendation that it should be
> >> implies that you are still thinking in the Flex mindset.  In Royale,
> >>PAYG
> >> is an important principle, and your arguments below basically describe
> >> "just-in-case" which is not PAYG.  It might be that a JewelUIBase would
> >> integrate ClassListSelector.  I will try to code that up today so we can
> >> see how that feels.
> >>
> >> Royale does want to make things easy, but, IMO, PAYG is more important
> >> than easy.  Flex put easy as more important than PAYG, and while that
> >> might have helped Flex gain popularity more quickly, in the end, Flex
> >> began having size and performance problems.  I do not want to repeat
> >>that
> >> mistake with Royale.  It doesn't matter how easy it is to get started if
> >> you can't finish.  There has to be the right balance.
> >>
> >> My 2 cents,
> >> -Alex
> >>
> >> On 4/16/18, 4:33 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >Hi,
> >> >
> >> >ClassListSelector could be ok, but think that depending on the
> >>components
> >> >in both MDL and JEWEL the class selector names added/removed/toggled
> >>could
> >> >go to positioner or to element. There's various examples of this in
> >>each
> >> >library. We should not lost that capability since is key.
> >> >
> >> >In order to bake in UIBase, my opinion is that devs will use this a
> >>lot in
> >> >their apps, so for me I'm ok to have it.
> >> >If it was an API partially used, I'd think about it, but actual JS
> >> >development is so much focused in add/remove class selectors.
> >> >
> >> >I'll be waiting for the final touches
> >> >
> >> >thanks Alex for working on this, and sorry if I'm a bit focused but I
> >> >think
> >> >this point is important since in Royale we try to make easy things and
> >> >encapsulate best practices and code, and this seems to me something
> >>that
> >> >people will use in library APIs and in final Apps
> >> >
> >> >thanks
> >> >
> >> >
> >> >
> >> >2018-04-16 10:18 GMT+02:00 Piotr Zarzycki :
> >> >
> >> >> If I could decide - that class should be used as an util outside
> >>UIBase.
> >> >> UIBase should be as much technology agnostic as we can. However how
> >>to
> >> >>use
> >> >> that class outside ?
> >> >>

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

I integrated the same pattern in Jewel's Button, CheckBox, RadioButton and
Slider.  This indicates that it can be implemented in a common base class
for these components.  The example looks ok to me.

The code assumes positioner.  For Button, if there is no hierarchy, then
positioner and element should be the same so it should work.  If it turns
out there are still going to be exceptions that don't work, then we might
need to introduce a "styleTarget" property in the Jewel base class that
createElement can assign and ClassSelectorList will use instead of
positioner.

HTH,
-Alex

On 4/16/18, 9:46 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>for me is ok to have it in JewelUIBase,
>in the other hand to look at what I tried to say with "positioner" vs
>"element" to apply class selectors, take a look at Jewel CheckBox (that
>will be refactored to extend JewelUIBase instead of current Basic
>CheckBox,
>like the rest of components). In create element the element in an input
>and
>the positioner is a label so setClassName is overriden to apply styles to
>positioner
>
>COMPILE::JS
>override protected function setClassName(value:String):void
>{
>addStyles(positioner, value);
>}
>
>in contrast Button will be using element instead since there's no wrapper.
>Button is its own wrapper
>
>thanks
>
>
>2018-04-16 18:27 GMT+02:00 Alex Harui :
>
>> Hi Carlos,
>>
>> Again, let's be specific and not over-state the scenarios.  I do not
>> believe that absolutely all JS development is focused on class
>>selectors,
>> otherwise there would be more articles about that practice.  And, while
>>I
>> don't doubt that the "setting properties that affect visuals" might need
>> to access elements instead of just the positioner, I would expect the
>> component to be an abstraction to the developer so when they choose "a
>>set
>> of groups of styles" it would always apply to the positioner.  They
>>should
>> not have to know the internal "sub-DOM" of the component.
>>
>> After thinking about it more, I agree with Piotr that ClassListSelector
>> should not be baked into UIBase.  Your recommendation that it should be
>> implies that you are still thinking in the Flex mindset.  In Royale,
>>PAYG
>> is an important principle, and your arguments below basically describe
>> "just-in-case" which is not PAYG.  It might be that a JewelUIBase would
>> integrate ClassListSelector.  I will try to code that up today so we can
>> see how that feels.
>>
>> Royale does want to make things easy, but, IMO, PAYG is more important
>> than easy.  Flex put easy as more important than PAYG, and while that
>> might have helped Flex gain popularity more quickly, in the end, Flex
>> began having size and performance problems.  I do not want to repeat
>>that
>> mistake with Royale.  It doesn't matter how easy it is to get started if
>> you can't finish.  There has to be the right balance.
>>
>> My 2 cents,
>> -Alex
>>
>> On 4/16/18, 4:33 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi,
>> >
>> >ClassListSelector could be ok, but think that depending on the
>>components
>> >in both MDL and JEWEL the class selector names added/removed/toggled
>>could
>> >go to positioner or to element. There's various examples of this in
>>each
>> >library. We should not lost that capability since is key.
>> >
>> >In order to bake in UIBase, my opinion is that devs will use this a
>>lot in
>> >their apps, so for me I'm ok to have it.
>> >If it was an API partially used, I'd think about it, but actual JS
>> >development is so much focused in add/remove class selectors.
>> >
>> >I'll be waiting for the final touches
>> >
>> >thanks Alex for working on this, and sorry if I'm a bit focused but I
>> >think
>> >this point is important since in Royale we try to make easy things and
>> >encapsulate best practices and code, and this seems to me something
>>that
>> >people will use in library APIs and in final Apps
>> >
>> >thanks
>> >
>> >
>> >
>> >2018-04-16 10:18 GMT+02:00 Piotr Zarzycki :
>> >
>> >> If I could decide - that class should be used as an util outside
>>UIBase.
>> >> UIBase should be as much technology agnostic as we can. However how
>>to
>> >>use
>> >> that class outside ?
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >> 2018-04-16 10:08 GMT+02:00 Alex Harui :
>> >>
>> >> > Hi Carlos,
>> >> >
>> >> > I'm running out of ways to try to explain this one concept.
>>Here's my
>> >> > next attempt:  I think you are too focused on the underlying
>>browser
>> >> > implementation.  Conceptually, the application developer is
>>"setting
>> >> > properties to affect visuals" or "choosing sets of groups of
>>styles at
>> >> > runtime".  That is the abstraction/APIs Royale needs to present.
>>It

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

for me is ok to have it in JewelUIBase,
in the other hand to look at what I tried to say with "positioner" vs
"element" to apply class selectors, take a look at Jewel CheckBox (that
will be refactored to extend JewelUIBase instead of current Basic CheckBox,
like the rest of components). In create element the element in an input and
the positioner is a label so setClassName is overriden to apply styles to
positioner

COMPILE::JS
override protected function setClassName(value:String):void
{
addStyles(positioner, value);
}

in contrast Button will be using element instead since there's no wrapper.
Button is its own wrapper

thanks


2018-04-16 18:27 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> Again, let's be specific and not over-state the scenarios.  I do not
> believe that absolutely all JS development is focused on class selectors,
> otherwise there would be more articles about that practice.  And, while I
> don't doubt that the "setting properties that affect visuals" might need
> to access elements instead of just the positioner, I would expect the
> component to be an abstraction to the developer so when they choose "a set
> of groups of styles" it would always apply to the positioner.  They should
> not have to know the internal "sub-DOM" of the component.
>
> After thinking about it more, I agree with Piotr that ClassListSelector
> should not be baked into UIBase.  Your recommendation that it should be
> implies that you are still thinking in the Flex mindset.  In Royale, PAYG
> is an important principle, and your arguments below basically describe
> "just-in-case" which is not PAYG.  It might be that a JewelUIBase would
> integrate ClassListSelector.  I will try to code that up today so we can
> see how that feels.
>
> Royale does want to make things easy, but, IMO, PAYG is more important
> than easy.  Flex put easy as more important than PAYG, and while that
> might have helped Flex gain popularity more quickly, in the end, Flex
> began having size and performance problems.  I do not want to repeat that
> mistake with Royale.  It doesn't matter how easy it is to get started if
> you can't finish.  There has to be the right balance.
>
> My 2 cents,
> -Alex
>
> On 4/16/18, 4:33 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi,
> >
> >ClassListSelector could be ok, but think that depending on the components
> >in both MDL and JEWEL the class selector names added/removed/toggled could
> >go to positioner or to element. There's various examples of this in each
> >library. We should not lost that capability since is key.
> >
> >In order to bake in UIBase, my opinion is that devs will use this a lot in
> >their apps, so for me I'm ok to have it.
> >If it was an API partially used, I'd think about it, but actual JS
> >development is so much focused in add/remove class selectors.
> >
> >I'll be waiting for the final touches
> >
> >thanks Alex for working on this, and sorry if I'm a bit focused but I
> >think
> >this point is important since in Royale we try to make easy things and
> >encapsulate best practices and code, and this seems to me something that
> >people will use in library APIs and in final Apps
> >
> >thanks
> >
> >
> >
> >2018-04-16 10:18 GMT+02:00 Piotr Zarzycki :
> >
> >> If I could decide - that class should be used as an util outside UIBase.
> >> UIBase should be as much technology agnostic as we can. However how to
> >>use
> >> that class outside ?
> >>
> >> Thanks,
> >> Piotr
> >>
> >> 2018-04-16 10:08 GMT+02:00 Alex Harui :
> >>
> >> > Hi Carlos,
> >> >
> >> > I'm running out of ways to try to explain this one concept.  Here's my
> >> > next attempt:  I think you are too focused on the underlying browser
> >> > implementation.  Conceptually, the application developer is "setting
> >> > properties to affect visuals" or "choosing sets of groups of styles at
> >> > runtime".  That is the abstraction/APIs Royale needs to present.  It
> >>has
> >> > nothing to do with className/classList.  If we ever target some other
> >> > runtime, for example, native C code, or even in the SWF
> >>implementations,
> >> > there may not be any className/classList in the runtime and the
> >>runtime
> >> > implementation should only have to implement the APIs we present, and
> >>not
> >> > emulate the browser's className/classList.
> >> >
> >> > Thus, the APIs we present should be things like "primary",
> >>"secondary",
> >> > "emphasized" as "properties that affect visuals", and addStyles,
> >> > removeStyles, toggleStyles for "choosing sets of groups of styles".
> >>But
> >> > addStyles, removeStyles, and toggleStyles should not take an
> >>HTMLElement
> >> > as a parameter, but rather, an IUIBase.  The key question here is
> >>whether
> >> > the JS implementation can always assume that the styles get 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Hi Carlos,

Again, let's be specific and not over-state the scenarios.  I do not
believe that absolutely all JS development is focused on class selectors,
otherwise there would be more articles about that practice.  And, while I
don't doubt that the "setting properties that affect visuals" might need
to access elements instead of just the positioner, I would expect the
component to be an abstraction to the developer so when they choose "a set
of groups of styles" it would always apply to the positioner.  They should
not have to know the internal "sub-DOM" of the component.

After thinking about it more, I agree with Piotr that ClassListSelector
should not be baked into UIBase.  Your recommendation that it should be
implies that you are still thinking in the Flex mindset.  In Royale, PAYG
is an important principle, and your arguments below basically describe
"just-in-case" which is not PAYG.  It might be that a JewelUIBase would
integrate ClassListSelector.  I will try to code that up today so we can
see how that feels.

Royale does want to make things easy, but, IMO, PAYG is more important
than easy.  Flex put easy as more important than PAYG, and while that
might have helped Flex gain popularity more quickly, in the end, Flex
began having size and performance problems.  I do not want to repeat that
mistake with Royale.  It doesn't matter how easy it is to get started if
you can't finish.  There has to be the right balance.

My 2 cents,
-Alex

On 4/16/18, 4:33 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi,
>
>ClassListSelector could be ok, but think that depending on the components
>in both MDL and JEWEL the class selector names added/removed/toggled could
>go to positioner or to element. There's various examples of this in each
>library. We should not lost that capability since is key.
>
>In order to bake in UIBase, my opinion is that devs will use this a lot in
>their apps, so for me I'm ok to have it.
>If it was an API partially used, I'd think about it, but actual JS
>development is so much focused in add/remove class selectors.
>
>I'll be waiting for the final touches
>
>thanks Alex for working on this, and sorry if I'm a bit focused but I
>think
>this point is important since in Royale we try to make easy things and
>encapsulate best practices and code, and this seems to me something that
>people will use in library APIs and in final Apps
>
>thanks
>
>
>
>2018-04-16 10:18 GMT+02:00 Piotr Zarzycki :
>
>> If I could decide - that class should be used as an util outside UIBase.
>> UIBase should be as much technology agnostic as we can. However how to
>>use
>> that class outside ?
>>
>> Thanks,
>> Piotr
>>
>> 2018-04-16 10:08 GMT+02:00 Alex Harui :
>>
>> > Hi Carlos,
>> >
>> > I'm running out of ways to try to explain this one concept.  Here's my
>> > next attempt:  I think you are too focused on the underlying browser
>> > implementation.  Conceptually, the application developer is "setting
>> > properties to affect visuals" or "choosing sets of groups of styles at
>> > runtime".  That is the abstraction/APIs Royale needs to present.  It
>>has
>> > nothing to do with className/classList.  If we ever target some other
>> > runtime, for example, native C code, or even in the SWF
>>implementations,
>> > there may not be any className/classList in the runtime and the
>>runtime
>> > implementation should only have to implement the APIs we present, and
>>not
>> > emulate the browser's className/classList.
>> >
>> > Thus, the APIs we present should be things like "primary",
>>"secondary",
>> > "emphasized" as "properties that affect visuals", and addStyles,
>> > removeStyles, toggleStyles for "choosing sets of groups of styles".
>>But
>> > addStyles, removeStyles, and toggleStyles should not take an
>>HTMLElement
>> > as a parameter, but rather, an IUIBase.  The key question here is
>>whether
>> > the JS implementation can always assume that the styles get applied to
>> the
>> > positioner which may not be the same as the element.  I think the
>>answer
>> > is yes.
>> >
>> > Then we have another option, which is to say that there is "an initial
>> set
>> > of styles".  That's our MXML className property.  We are not
>>obligated to
>> > allow it to be changed at runtime since we have the other APIs nor
>>are we
>> > obligated to keep it in sync with the properties we use in the JS
>> > implementation.  Note that Royale className and HTMLElement className
>>has
>> > never been kept in sync even in Basic because we add typeNames.
>> >
>> > I think with that set of 3 categories, there isn't really a need for
>> folks
>> > to have to "totally reset the initial set of styles", which implies
>> > setting MXML className at runtime, or if there is a small amount of
>>code
>> > to do it but it is computationally expensive, that may be acceptable.
>> I
>> > think "totally resetting" 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi,

ClassListSelector could be ok, but think that depending on the components
in both MDL and JEWEL the class selector names added/removed/toggled could
go to positioner or to element. There's various examples of this in each
library. We should not lost that capability since is key.

In order to bake in UIBase, my opinion is that devs will use this a lot in
their apps, so for me I'm ok to have it.
If it was an API partially used, I'd think about it, but actual JS
development is so much focused in add/remove class selectors.

I'll be waiting for the final touches

thanks Alex for working on this, and sorry if I'm a bit focused but I think
this point is important since in Royale we try to make easy things and
encapsulate best practices and code, and this seems to me something that
people will use in library APIs and in final Apps

thanks



2018-04-16 10:18 GMT+02:00 Piotr Zarzycki :

> If I could decide - that class should be used as an util outside UIBase.
> UIBase should be as much technology agnostic as we can. However how to use
> that class outside ?
>
> Thanks,
> Piotr
>
> 2018-04-16 10:08 GMT+02:00 Alex Harui :
>
> > Hi Carlos,
> >
> > I'm running out of ways to try to explain this one concept.  Here's my
> > next attempt:  I think you are too focused on the underlying browser
> > implementation.  Conceptually, the application developer is "setting
> > properties to affect visuals" or "choosing sets of groups of styles at
> > runtime".  That is the abstraction/APIs Royale needs to present.  It has
> > nothing to do with className/classList.  If we ever target some other
> > runtime, for example, native C code, or even in the SWF implementations,
> > there may not be any className/classList in the runtime and the runtime
> > implementation should only have to implement the APIs we present, and not
> > emulate the browser's className/classList.
> >
> > Thus, the APIs we present should be things like "primary", "secondary",
> > "emphasized" as "properties that affect visuals", and addStyles,
> > removeStyles, toggleStyles for "choosing sets of groups of styles".  But
> > addStyles, removeStyles, and toggleStyles should not take an HTMLElement
> > as a parameter, but rather, an IUIBase.  The key question here is whether
> > the JS implementation can always assume that the styles get applied to
> the
> > positioner which may not be the same as the element.  I think the answer
> > is yes.
> >
> > Then we have another option, which is to say that there is "an initial
> set
> > of styles".  That's our MXML className property.  We are not obligated to
> > allow it to be changed at runtime since we have the other APIs nor are we
> > obligated to keep it in sync with the properties we use in the JS
> > implementation.  Note that Royale className and HTMLElement className has
> > never been kept in sync even in Basic because we add typeNames.
> >
> > I think with that set of 3 categories, there isn't really a need for
> folks
> > to have to "totally reset the initial set of styles", which implies
> > setting MXML className at runtime, or if there is a small amount of code
> > to do it but it is computationally expensive, that may be acceptable.  I
> > think "totally resetting" is a rare occurrence and the "choosing sets" is
> > a sufficient API.
> >
> > I spent this evening trying a different implementation, but found out
> that
> > classList isn't backed by the kind of data structure I thought it had.  I
> > was hoping that toggle disabled entries instead of removing them.  I've
> > pushed a first cut at another way of managing the list of classes by
> > trying to track the indexes in the classList set by the classname.  See
> > ClassSelectorList.as.  I haven't wired it up yet to Jewel.  I'm pondering
> > whether it could go in UIBase.
> >
> > Thoughts?
> > -Alex
> >
> >
> >
> >
> > On 4/15/18, 4:01 AM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >  wrote:
> >
> > >Hi Alex,
> > >
> > >app devs will create logic that will use our encapsulated code (i.e:
> > >setting primary to true or false). Jewel as MDL has properties that uses
> > >to
> > >deal with true/false values to make it easy for the user to change a
> > >style.
> > >Under the hood, that is changing the "element.class" or
> > >"positioner.class".
> > >I think component's royale className property should be updated and not
> > >remain dirty since that would create lots of confusion for our users. If
> > >we
> > >do that folks should never operate again with "className", maybe it
> could
> > >not be a problem, although left className in a non valid state sound
> > >strange to me. If you think it can work, we can try it and see what
> > >happen... but seems to me that maybe we're making thing very complex
> when
> > >all could be more straight lined. Anyway, I'll wait for your changes.
> > >Thanks!
> > >
> > >Carlos
> > >
> > >

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Piotr Zarzycki]

If I could decide - that class should be used as an util outside UIBase.
UIBase should be as much technology agnostic as we can. However how to use
that class outside ?

Thanks,
Piotr

2018-04-16 10:08 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I'm running out of ways to try to explain this one concept.  Here's my
> next attempt:  I think you are too focused on the underlying browser
> implementation.  Conceptually, the application developer is "setting
> properties to affect visuals" or "choosing sets of groups of styles at
> runtime".  That is the abstraction/APIs Royale needs to present.  It has
> nothing to do with className/classList.  If we ever target some other
> runtime, for example, native C code, or even in the SWF implementations,
> there may not be any className/classList in the runtime and the runtime
> implementation should only have to implement the APIs we present, and not
> emulate the browser's className/classList.
>
> Thus, the APIs we present should be things like "primary", "secondary",
> "emphasized" as "properties that affect visuals", and addStyles,
> removeStyles, toggleStyles for "choosing sets of groups of styles".  But
> addStyles, removeStyles, and toggleStyles should not take an HTMLElement
> as a parameter, but rather, an IUIBase.  The key question here is whether
> the JS implementation can always assume that the styles get applied to the
> positioner which may not be the same as the element.  I think the answer
> is yes.
>
> Then we have another option, which is to say that there is "an initial set
> of styles".  That's our MXML className property.  We are not obligated to
> allow it to be changed at runtime since we have the other APIs nor are we
> obligated to keep it in sync with the properties we use in the JS
> implementation.  Note that Royale className and HTMLElement className has
> never been kept in sync even in Basic because we add typeNames.
>
> I think with that set of 3 categories, there isn't really a need for folks
> to have to "totally reset the initial set of styles", which implies
> setting MXML className at runtime, or if there is a small amount of code
> to do it but it is computationally expensive, that may be acceptable.  I
> think "totally resetting" is a rare occurrence and the "choosing sets" is
> a sufficient API.
>
> I spent this evening trying a different implementation, but found out that
> classList isn't backed by the kind of data structure I thought it had.  I
> was hoping that toggle disabled entries instead of removing them.  I've
> pushed a first cut at another way of managing the list of classes by
> trying to track the indexes in the classList set by the classname.  See
> ClassSelectorList.as.  I haven't wired it up yet to Jewel.  I'm pondering
> whether it could go in UIBase.
>
> Thoughts?
> -Alex
>
>
>
>
> On 4/15/18, 4:01 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >app devs will create logic that will use our encapsulated code (i.e:
> >setting primary to true or false). Jewel as MDL has properties that uses
> >to
> >deal with true/false values to make it easy for the user to change a
> >style.
> >Under the hood, that is changing the "element.class" or
> >"positioner.class".
> >I think component's royale className property should be updated and not
> >remain dirty since that would create lots of confusion for our users. If
> >we
> >do that folks should never operate again with "className", maybe it could
> >not be a problem, although left className in a non valid state sound
> >strange to me. If you think it can work, we can try it and see what
> >happen... but seems to me that maybe we're making thing very complex when
> >all could be more straight lined. Anyway, I'll wait for your changes.
> >Thanks!
> >
> >Carlos
> >
> >
> >
> >2018-04-15 8:49 GMT+02:00 Alex Harui :
> >
> >> IMO, Carlos still isn't understanding my point.  My point is that the
> >>app
> >> devs will not need to be setting className.  They will be setting
> >> properties like "emphasized", "secondary" and "primary" that can do
> >> whatever it wants under the covers, and if we assume that folks will not
> >> set (or are not supposed to set) className after init time, there are
> >>much
> >> simpler ways to handle this situation.
> >>
> >> That said, I have another idea about how to allow "emphasized",
> >> "secondary" and "primary" to use classList that might be simpler that
> >>what
> >> I have committed so far.  I will try to code it up tomorrow for others
> >>to
> >> look at.
> >>
> >> Thanks,
> >> -Alex
> >>
> >> On 4/14/18, 9:24 AM, "Piotr Zarzycki" 
> wrote:
> >>
> >> >Are you saying that it will work with your implementation and not with
> >> >Alex's?
> >> >
> >> >Actually as a app developer above situation is very rare.
> >> >
> >> >Thanks,
> >> >Piotr
> >> >
> >> >On Sat, Apr 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Hi Carlos,

I'm running out of ways to try to explain this one concept.  Here's my
next attempt:  I think you are too focused on the underlying browser
implementation.  Conceptually, the application developer is "setting
properties to affect visuals" or "choosing sets of groups of styles at
runtime".  That is the abstraction/APIs Royale needs to present.  It has
nothing to do with className/classList.  If we ever target some other
runtime, for example, native C code, or even in the SWF implementations,
there may not be any className/classList in the runtime and the runtime
implementation should only have to implement the APIs we present, and not
emulate the browser's className/classList.

Thus, the APIs we present should be things like "primary", "secondary",
"emphasized" as "properties that affect visuals", and addStyles,
removeStyles, toggleStyles for "choosing sets of groups of styles".  But
addStyles, removeStyles, and toggleStyles should not take an HTMLElement
as a parameter, but rather, an IUIBase.  The key question here is whether
the JS implementation can always assume that the styles get applied to the
positioner which may not be the same as the element.  I think the answer
is yes.

Then we have another option, which is to say that there is "an initial set
of styles".  That's our MXML className property.  We are not obligated to
allow it to be changed at runtime since we have the other APIs nor are we
obligated to keep it in sync with the properties we use in the JS
implementation.  Note that Royale className and HTMLElement className has
never been kept in sync even in Basic because we add typeNames.

I think with that set of 3 categories, there isn't really a need for folks
to have to "totally reset the initial set of styles", which implies
setting MXML className at runtime, or if there is a small amount of code
to do it but it is computationally expensive, that may be acceptable.  I
think "totally resetting" is a rare occurrence and the "choosing sets" is
a sufficient API.

I spent this evening trying a different implementation, but found out that
classList isn't backed by the kind of data structure I thought it had.  I
was hoping that toggle disabled entries instead of removing them.  I've
pushed a first cut at another way of managing the list of classes by
trying to track the indexes in the classList set by the classname.  See
ClassSelectorList.as.  I haven't wired it up yet to Jewel.  I'm pondering
whether it could go in UIBase.

Thoughts?
-Alex




On 4/15/18, 4:01 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>app devs will create logic that will use our encapsulated code (i.e:
>setting primary to true or false). Jewel as MDL has properties that uses
>to
>deal with true/false values to make it easy for the user to change a
>style.
>Under the hood, that is changing the "element.class" or
>"positioner.class".
>I think component's royale className property should be updated and not
>remain dirty since that would create lots of confusion for our users. If
>we
>do that folks should never operate again with "className", maybe it could
>not be a problem, although left className in a non valid state sound
>strange to me. If you think it can work, we can try it and see what
>happen... but seems to me that maybe we're making thing very complex when
>all could be more straight lined. Anyway, I'll wait for your changes.
>Thanks!
>
>Carlos
>
>
>
>2018-04-15 8:49 GMT+02:00 Alex Harui :
>
>> IMO, Carlos still isn't understanding my point.  My point is that the
>>app
>> devs will not need to be setting className.  They will be setting
>> properties like "emphasized", "secondary" and "primary" that can do
>> whatever it wants under the covers, and if we assume that folks will not
>> set (or are not supposed to set) className after init time, there are
>>much
>> simpler ways to handle this situation.
>>
>> That said, I have another idea about how to allow "emphasized",
>> "secondary" and "primary" to use classList that might be simpler that
>>what
>> I have committed so far.  I will try to code it up tomorrow for others
>>to
>> look at.
>>
>> Thanks,
>> -Alex
>>
>> On 4/14/18, 9:24 AM, "Piotr Zarzycki"  wrote:
>>
>> >Are you saying that it will work with your implementation and not with
>> >Alex's?
>> >
>> >Actually as a app developer above situation is very rare.
>> >
>> >Thanks,
>> >Piotr
>> >
>> >On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira 
>> >wrote:
>> >
>> >> That's what Alex want. To make className only used at init time then
>>we
>> >> should use classList methods.
>> >> I think that the premises are not right, since Alex thinks devs will
>>not
>> >> make heavy use of switching class selectors at runtime (at init time
>>and
>> >> later while using the app). MDL and Jewel are constantly setting and
>> >> removing class selectors 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

app devs will create logic that will use our encapsulated code (i.e:
setting primary to true or false). Jewel as MDL has properties that uses to
deal with true/false values to make it easy for the user to change a style.
Under the hood, that is changing the "element.class" or "positioner.class".
I think component's royale className property should be updated and not
remain dirty since that would create lots of confusion for our users. If we
do that folks should never operate again with "className", maybe it could
not be a problem, although left className in a non valid state sound
strange to me. If you think it can work, we can try it and see what
happen... but seems to me that maybe we're making thing very complex when
all could be more straight lined. Anyway, I'll wait for your changes.
Thanks!

Carlos



2018-04-15 8:49 GMT+02:00 Alex Harui :

> IMO, Carlos still isn't understanding my point.  My point is that the app
> devs will not need to be setting className.  They will be setting
> properties like "emphasized", "secondary" and "primary" that can do
> whatever it wants under the covers, and if we assume that folks will not
> set (or are not supposed to set) className after init time, there are much
> simpler ways to handle this situation.
>
> That said, I have another idea about how to allow "emphasized",
> "secondary" and "primary" to use classList that might be simpler that what
> I have committed so far.  I will try to code it up tomorrow for others to
> look at.
>
> Thanks,
> -Alex
>
> On 4/14/18, 9:24 AM, "Piotr Zarzycki"  wrote:
>
> >Are you saying that it will work with your implementation and not with
> >Alex's?
> >
> >Actually as a app developer above situation is very rare.
> >
> >Thanks,
> >Piotr
> >
> >On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira 
> >wrote:
> >
> >> That's what Alex want. To make className only used at init time then we
> >> should use classList methods.
> >> I think that the premises are not right, since Alex thinks devs will not
> >> make heavy use of switching class selectors at runtime (at init time and
> >> later while using the app). MDL and Jewel are constantly setting and
> >> removing class selectors from elements and positioners, so className
> >>(set
> >> only once at init time) is not right for use, but for people using
> >>Basic.
> >> Hence, Basic should remain with className, and MDL/Jewel should go
> >> classList *always* (shadowing it so will have a royale API to work with
> >>SWF
> >> and JS and in JS compilation use classList
> >>
> >> 2018-04-14 14:24 GMT+02:00 Piotr Zarzycki :
> >>
> >> > Carlos,
> >> >
> >> > Are you saying here having your idea:
> >> >
> >> > "
> >> > 1) I think people have the APIs (className and classList) and
> >>can/will do
> >> > what they want, although we say "use className only at init time".
> >> > "
> >> >
> >> > If I do following things:
> >> >
> >> > 
> >> >
> >> > And later in the code I do:
> >> >
> >> > comp.className = "myOtherClass";
> >> >
> >> > It won't work?
> >> >
> >> > Piotr
> >> >
> >> >
> >> > On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira  >
> >> > wrote:
> >> >
> >> > > Alex
> >> > >
> >> > > 2018-04-14 8:41 GMT+02:00 Alex Harui :
> >> > >
> >> > > > Carlos,
> >> > > >
> >> > > > It seems like either you have missed some of the discussion or
> >>maybe
> >> we
> >> > > > weren't clear enough.
> >> > > >
> >> > >
> >> > > I think most of what you say was considered but let's go for parts:
> >> > >
> >> > >
> >> > > >
> >> > > > Simply put:
> >> > > > -The Basic components do not need to handle classList APIs.
> >>There is
> >> > no
> >> > > > expectation that classes will be frequently added and removed.
> >> > > >
> >> > >
> >> > > That's ok. Basic no, Jewel yes. That's huge diference, so I think as
> >> you
> >> > > UIBase should go to Core and be as is now (or make the changes you
> >> > > estimate)
> >> > >
> >> > >
> >> > > > -The goal of most component sets in Royale is to abstract away the
> >> > > > underlying platform APIs.  That's why I'm not in favor of having a
> >> > > > classList API on UIBase.
> >> > > >
> >> > >
> >> > > Right, classList is JS only so maybe an API in JewelUIBase should be
> >> > > general and use the JS code with COMPILE::JS
> >> > > then implement others.
> >> > >
> >> > > -MXML is better with space delimited string lists instead of arrays.
> >> > > >
> >> > >
> >> > > I think in you version and my version is a string, but in mine then
> >>is
> >> > > converted to feed classList
> >> > >
> >> > >
> >> > > > -It doesn't make sense to split strings into an array in JS when
> >>the
> >> > > > browser clearly can do it.
> >> > > > -This perf test shows className is faster [1]
> >> > > > -So does this one [2]
> >> > > >
> >> > > >
> >> > > > We are starting from a list of strings.  MDL is not.  And that
> >>makes
> 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

IMO, Carlos still isn't understanding my point.  My point is that the app
devs will not need to be setting className.  They will be setting
properties like "emphasized", "secondary" and "primary" that can do
whatever it wants under the covers, and if we assume that folks will not
set (or are not supposed to set) className after init time, there are much
simpler ways to handle this situation.

That said, I have another idea about how to allow "emphasized",
"secondary" and "primary" to use classList that might be simpler that what
I have committed so far.  I will try to code it up tomorrow for others to
look at.

Thanks,
-Alex

On 4/14/18, 9:24 AM, "Piotr Zarzycki"  wrote:

>Are you saying that it will work with your implementation and not with
>Alex's?
>
>Actually as a app developer above situation is very rare.
>
>Thanks,
>Piotr
>
>On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira 
>wrote:
>
>> That's what Alex want. To make className only used at init time then we
>> should use classList methods.
>> I think that the premises are not right, since Alex thinks devs will not
>> make heavy use of switching class selectors at runtime (at init time and
>> later while using the app). MDL and Jewel are constantly setting and
>> removing class selectors from elements and positioners, so className
>>(set
>> only once at init time) is not right for use, but for people using
>>Basic.
>> Hence, Basic should remain with className, and MDL/Jewel should go
>> classList *always* (shadowing it so will have a royale API to work with
>>SWF
>> and JS and in JS compilation use classList
>>
>> 2018-04-14 14:24 GMT+02:00 Piotr Zarzycki :
>>
>> > Carlos,
>> >
>> > Are you saying here having your idea:
>> >
>> > "
>> > 1) I think people have the APIs (className and classList) and
>>can/will do
>> > what they want, although we say "use className only at init time".
>> > "
>> >
>> > If I do following things:
>> >
>> > 
>> >
>> > And later in the code I do:
>> >
>> > comp.className = "myOtherClass";
>> >
>> > It won't work?
>> >
>> > Piotr
>> >
>> >
>> > On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira 
>> > wrote:
>> >
>> > > Alex
>> > >
>> > > 2018-04-14 8:41 GMT+02:00 Alex Harui :
>> > >
>> > > > Carlos,
>> > > >
>> > > > It seems like either you have missed some of the discussion or
>>maybe
>> we
>> > > > weren't clear enough.
>> > > >
>> > >
>> > > I think most of what you say was considered but let's go for parts:
>> > >
>> > >
>> > > >
>> > > > Simply put:
>> > > > -The Basic components do not need to handle classList APIs.
>>There is
>> > no
>> > > > expectation that classes will be frequently added and removed.
>> > > >
>> > >
>> > > That's ok. Basic no, Jewel yes. That's huge diference, so I think as
>> you
>> > > UIBase should go to Core and be as is now (or make the changes you
>> > > estimate)
>> > >
>> > >
>> > > > -The goal of most component sets in Royale is to abstract away the
>> > > > underlying platform APIs.  That's why I'm not in favor of having a
>> > > > classList API on UIBase.
>> > > >
>> > >
>> > > Right, classList is JS only so maybe an API in JewelUIBase should be
>> > > general and use the JS code with COMPILE::JS
>> > > then implement others.
>> > >
>> > > -MXML is better with space delimited string lists instead of arrays.
>> > > >
>> > >
>> > > I think in you version and my version is a string, but in mine then
>>is
>> > > converted to feed classList
>> > >
>> > >
>> > > > -It doesn't make sense to split strings into an array in JS when
>>the
>> > > > browser clearly can do it.
>> > > > -This perf test shows className is faster [1]
>> > > > -So does this one [2]
>> > > >
>> > > >
>> > > > We are starting from a list of strings.  MDL is not.  And that
>>makes
>> a
>> > > > difference, IMO.
>> > > >
>> > > >
>> > > ok in Jewel we could do in that way, the main difference with Basic
>>is
>> > that
>> > > the main task of this kind of set is
>> > > heavily deal with class selectors so for Jewel (not for Basic) we
>> should
>> > > focus on it what means to me be fundamental part of JewelUIBase to
>>have
>> > an
>> > > API to deal with styles in all platforms and that all components
>> > extending
>> > > it can use.
>> > >
>> > >
>> > > > I forgot to mention earlier that I was not happy that addStyles
>>and
>> > > > friends were JS-only.  It would have been better if it did not
>>take
>> an
>> > > > element since that is a JS platform implementation.  That way
>> > application
>> > > > developers could use addStyles and friends to manipulate the set
>>of
>> > class
>> > > > selectors at runtime.
>> > > >
>> > >
>> > > ok, that's a fail on my implementation that should be fixed
>> > >
>> > >
>> > > >
>> > > > More comments in-line..
>> > > >
>> > > > [1]
>> > > > 
>>https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmeasuret

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Piotr Zarzycki]

Are you saying that it will work with your implementation and not with
Alex's?

Actually as a app developer above situation is very rare.

Thanks,
Piotr

On Sat, Apr 14, 2018, 5:24 PM Carlos Rovira  wrote:

> That's what Alex want. To make className only used at init time then we
> should use classList methods.
> I think that the premises are not right, since Alex thinks devs will not
> make heavy use of switching class selectors at runtime (at init time and
> later while using the app). MDL and Jewel are constantly setting and
> removing class selectors from elements and positioners, so className (set
> only once at init time) is not right for use, but for people using Basic.
> Hence, Basic should remain with className, and MDL/Jewel should go
> classList *always* (shadowing it so will have a royale API to work with SWF
> and JS and in JS compilation use classList
>
> 2018-04-14 14:24 GMT+02:00 Piotr Zarzycki :
>
> > Carlos,
> >
> > Are you saying here having your idea:
> >
> > "
> > 1) I think people have the APIs (className and classList) and can/will do
> > what they want, although we say "use className only at init time".
> > "
> >
> > If I do following things:
> >
> > 
> >
> > And later in the code I do:
> >
> > comp.className = "myOtherClass";
> >
> > It won't work?
> >
> > Piotr
> >
> >
> > On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira 
> > wrote:
> >
> > > Alex
> > >
> > > 2018-04-14 8:41 GMT+02:00 Alex Harui :
> > >
> > > > Carlos,
> > > >
> > > > It seems like either you have missed some of the discussion or maybe
> we
> > > > weren't clear enough.
> > > >
> > >
> > > I think most of what you say was considered but let's go for parts:
> > >
> > >
> > > >
> > > > Simply put:
> > > > -The Basic components do not need to handle classList APIs.  There is
> > no
> > > > expectation that classes will be frequently added and removed.
> > > >
> > >
> > > That's ok. Basic no, Jewel yes. That's huge diference, so I think as
> you
> > > UIBase should go to Core and be as is now (or make the changes you
> > > estimate)
> > >
> > >
> > > > -The goal of most component sets in Royale is to abstract away the
> > > > underlying platform APIs.  That's why I'm not in favor of having a
> > > > classList API on UIBase.
> > > >
> > >
> > > Right, classList is JS only so maybe an API in JewelUIBase should be
> > > general and use the JS code with COMPILE::JS
> > > then implement others.
> > >
> > > -MXML is better with space delimited string lists instead of arrays.
> > > >
> > >
> > > I think in you version and my version is a string, but in mine then is
> > > converted to feed classList
> > >
> > >
> > > > -It doesn't make sense to split strings into an array in JS when the
> > > > browser clearly can do it.
> > > > -This perf test shows className is faster [1]
> > > > -So does this one [2]
> > > >
> > > >
> > > > We are starting from a list of strings.  MDL is not.  And that makes
> a
> > > > difference, IMO.
> > > >
> > > >
> > > ok in Jewel we could do in that way, the main difference with Basic is
> > that
> > > the main task of this kind of set is
> > > heavily deal with class selectors so for Jewel (not for Basic) we
> should
> > > focus on it what means to me be fundamental part of JewelUIBase to have
> > an
> > > API to deal with styles in all platforms and that all components
> > extending
> > > it can use.
> > >
> > >
> > > > I forgot to mention earlier that I was not happy that addStyles and
> > > > friends were JS-only.  It would have been better if it did not take
> an
> > > > element since that is a JS platform implementation.  That way
> > application
> > > > developers could use addStyles and friends to manipulate the set of
> > class
> > > > selectors at runtime.
> > > >
> > >
> > > ok, that's a fail on my implementation that should be fixed
> > >
> > >
> > > >
> > > > More comments in-line..
> > > >
> > > > [1]
> > > > https://measurethat.net/Benchmarks/Show/54/0/
> > > > classname-vs-setattribute-vs-c
> > > > lasslist
> > > > [2] https://jsperf.com/classname-vs-classlist-showdown/5
> > > >
> > > > On 4/13/18, 7:18 PM, "carlos.rov...@gmail.com on behalf of Carlos
> > > Rovira"
> > > > 
> wrote:
> > > >
> > > > >Hi,
> > > > >
> > > > >I think the discussion now should center in numbers.
> > > > >
> > > > >I added "performance.now()" to typedefs (how could we live without
> > this
> > > > >until now? :))
> > > >
> > > > Snip...
> > > > >
> > > > >
> > > > >I think numbers are near identical right?
> > > > >
> > > > >
> > > > >So given very close numbers should make us choose the more simplest
> > code
> > > > >
> > > > >
> > > > >right?
> > > > >
> > > > No.  Small samples are often not useful.  These kinds of arguments
> are
> > > the
> > > > ones that led to UIComponent being 13,000 lines in Flex.
> > > >
> > >
> > > I think here we are 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

That's what Alex want. To make className only used at init time then we
should use classList methods.
I think that the premises are not right, since Alex thinks devs will not
make heavy use of switching class selectors at runtime (at init time and
later while using the app). MDL and Jewel are constantly setting and
removing class selectors from elements and positioners, so className (set
only once at init time) is not right for use, but for people using Basic.
Hence, Basic should remain with className, and MDL/Jewel should go
classList *always* (shadowing it so will have a royale API to work with SWF
and JS and in JS compilation use classList

2018-04-14 14:24 GMT+02:00 Piotr Zarzycki :

> Carlos,
>
> Are you saying here having your idea:
>
> "
> 1) I think people have the APIs (className and classList) and can/will do
> what they want, although we say "use className only at init time".
> "
>
> If I do following things:
>
> 
>
> And later in the code I do:
>
> comp.className = "myOtherClass";
>
> It won't work?
>
> Piotr
>
>
> On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira 
> wrote:
>
> > Alex
> >
> > 2018-04-14 8:41 GMT+02:00 Alex Harui :
> >
> > > Carlos,
> > >
> > > It seems like either you have missed some of the discussion or maybe we
> > > weren't clear enough.
> > >
> >
> > I think most of what you say was considered but let's go for parts:
> >
> >
> > >
> > > Simply put:
> > > -The Basic components do not need to handle classList APIs.  There is
> no
> > > expectation that classes will be frequently added and removed.
> > >
> >
> > That's ok. Basic no, Jewel yes. That's huge diference, so I think as you
> > UIBase should go to Core and be as is now (or make the changes you
> > estimate)
> >
> >
> > > -The goal of most component sets in Royale is to abstract away the
> > > underlying platform APIs.  That's why I'm not in favor of having a
> > > classList API on UIBase.
> > >
> >
> > Right, classList is JS only so maybe an API in JewelUIBase should be
> > general and use the JS code with COMPILE::JS
> > then implement others.
> >
> > -MXML is better with space delimited string lists instead of arrays.
> > >
> >
> > I think in you version and my version is a string, but in mine then is
> > converted to feed classList
> >
> >
> > > -It doesn't make sense to split strings into an array in JS when the
> > > browser clearly can do it.
> > > -This perf test shows className is faster [1]
> > > -So does this one [2]
> > >
> > >
> > > We are starting from a list of strings.  MDL is not.  And that makes a
> > > difference, IMO.
> > >
> > >
> > ok in Jewel we could do in that way, the main difference with Basic is
> that
> > the main task of this kind of set is
> > heavily deal with class selectors so for Jewel (not for Basic) we should
> > focus on it what means to me be fundamental part of JewelUIBase to have
> an
> > API to deal with styles in all platforms and that all components
> extending
> > it can use.
> >
> >
> > > I forgot to mention earlier that I was not happy that addStyles and
> > > friends were JS-only.  It would have been better if it did not take an
> > > element since that is a JS platform implementation.  That way
> application
> > > developers could use addStyles and friends to manipulate the set of
> class
> > > selectors at runtime.
> > >
> >
> > ok, that's a fail on my implementation that should be fixed
> >
> >
> > >
> > > More comments in-line..
> > >
> > > [1]
> > > https://measurethat.net/Benchmarks/Show/54/0/
> > > classname-vs-setattribute-vs-c
> > > lasslist
> > > [2] https://jsperf.com/classname-vs-classlist-showdown/5
> > >
> > > On 4/13/18, 7:18 PM, "carlos.rov...@gmail.com on behalf of Carlos
> > Rovira"
> > >  wrote:
> > >
> > > >Hi,
> > > >
> > > >I think the discussion now should center in numbers.
> > > >
> > > >I added "performance.now()" to typedefs (how could we live without
> this
> > > >until now? :))
> > >
> > > Snip...
> > > >
> > > >
> > > >I think numbers are near identical right?
> > > >
> > > >
> > > >So given very close numbers should make us choose the more simplest
> code
> > > >
> > > >
> > > >right?
> > > >
> > > No.  Small samples are often not useful.  These kinds of arguments are
> > the
> > > ones that led to UIComponent being 13,000 lines in Flex.
> > >
> >
> > I think here we are talking about performance, not about to increase
> number
> > of lines of code
> >
> >
> > >
> > >
> > > >
> > > >
> > > >2018-04-14 2:58 GMT+02:00 Carlos Rovira :
> > > >
> > > >> Hi Alex,
> > > >>
> > > >> just studied you changes and want to ask you a few things:
> > > >>
> > > >> 1) Why className and classLists methods must remain unsynced? I
> think
> > > >>this
> > > >> is not necessary and seems to me a bit unnatural since when I add
> > styles
> > > >> though classList in a element this makes the internal 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Piotr Zarzycki]

Carlos,

Are you saying here having your idea:

"
1) I think people have the APIs (className and classList) and can/will do
what they want, although we say "use className only at init time".
"

If I do following things:



And later in the code I do:

comp.className = "myOtherClass";

It won't work?

Piotr


On Sat, Apr 14, 2018, 11:48 AM Carlos Rovira 
wrote:

> Alex
>
> 2018-04-14 8:41 GMT+02:00 Alex Harui :
>
> > Carlos,
> >
> > It seems like either you have missed some of the discussion or maybe we
> > weren't clear enough.
> >
>
> I think most of what you say was considered but let's go for parts:
>
>
> >
> > Simply put:
> > -The Basic components do not need to handle classList APIs.  There is no
> > expectation that classes will be frequently added and removed.
> >
>
> That's ok. Basic no, Jewel yes. That's huge diference, so I think as you
> UIBase should go to Core and be as is now (or make the changes you
> estimate)
>
>
> > -The goal of most component sets in Royale is to abstract away the
> > underlying platform APIs.  That's why I'm not in favor of having a
> > classList API on UIBase.
> >
>
> Right, classList is JS only so maybe an API in JewelUIBase should be
> general and use the JS code with COMPILE::JS
> then implement others.
>
> -MXML is better with space delimited string lists instead of arrays.
> >
>
> I think in you version and my version is a string, but in mine then is
> converted to feed classList
>
>
> > -It doesn't make sense to split strings into an array in JS when the
> > browser clearly can do it.
> > -This perf test shows className is faster [1]
> > -So does this one [2]
> >
> >
> > We are starting from a list of strings.  MDL is not.  And that makes a
> > difference, IMO.
> >
> >
> ok in Jewel we could do in that way, the main difference with Basic is that
> the main task of this kind of set is
> heavily deal with class selectors so for Jewel (not for Basic) we should
> focus on it what means to me be fundamental part of JewelUIBase to have an
> API to deal with styles in all platforms and that all components extending
> it can use.
>
>
> > I forgot to mention earlier that I was not happy that addStyles and
> > friends were JS-only.  It would have been better if it did not take an
> > element since that is a JS platform implementation.  That way application
> > developers could use addStyles and friends to manipulate the set of class
> > selectors at runtime.
> >
>
> ok, that's a fail on my implementation that should be fixed
>
>
> >
> > More comments in-line..
> >
> > [1]
> > https://measurethat.net/Benchmarks/Show/54/0/
> > classname-vs-setattribute-vs-c
> > lasslist
> > [2] https://jsperf.com/classname-vs-classlist-showdown/5
> >
> > On 4/13/18, 7:18 PM, "carlos.rov...@gmail.com on behalf of Carlos
> Rovira"
> >  wrote:
> >
> > >Hi,
> > >
> > >I think the discussion now should center in numbers.
> > >
> > >I added "performance.now()" to typedefs (how could we live without this
> > >until now? :))
> >
> > Snip...
> > >
> > >
> > >I think numbers are near identical right?
> > >
> > >
> > >So given very close numbers should make us choose the more simplest code
> > >
> > >
> > >right?
> > >
> > No.  Small samples are often not useful.  These kinds of arguments are
> the
> > ones that led to UIComponent being 13,000 lines in Flex.
> >
>
> I think here we are talking about performance, not about to increase number
> of lines of code
>
>
> >
> >
> > >
> > >
> > >2018-04-14 2:58 GMT+02:00 Carlos Rovira :
> > >
> > >> Hi Alex,
> > >>
> > >> just studied you changes and want to ask you a few things:
> > >>
> > >> 1) Why className and classLists methods must remain unsynced? I think
> > >>this
> > >> is not necessary and seems to me a bit unnatural since when I add
> styles
> > >> though classList in a element this makes the internal list changed,
> and
> > >>if
> > >> I then do "trace(element.className)" it will report the updated
> > >>list...so I
> > >> think both are synced by default
> >
> > I proposed a way to have components that want to use classList pay for
> it.
> >  If you want to further penalize those components in order to maintain
> > synchronization of classList and className go ahead as long as it doesn't
> > impact org.apache.flex.core.UIBase.  Yes, the browser keeps className and
> > classList in sync, but you are missing that the emphasized, primary and
> > secondary selectors are not in the className list maintained by UIBase
> and
> > there is additional cost to doing so.
> >
> >
> That's because when I refactored the code when you ask me to do so I tried
> to make it
> className dependent. I think the solution is in JewelUIBase wire all
> through classList.
> we'll have a tiny performance hit, that's right, but I think a uiset with
> the purpose of Jewel
> (theming - styling - goof looking) is the price that have to pay. 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Alex

2018-04-14 8:41 GMT+02:00 Alex Harui :

> Carlos,
>
> It seems like either you have missed some of the discussion or maybe we
> weren't clear enough.
>

I think most of what you say was considered but let's go for parts:


>
> Simply put:
> -The Basic components do not need to handle classList APIs.  There is no
> expectation that classes will be frequently added and removed.
>

That's ok. Basic no, Jewel yes. That's huge diference, so I think as you
UIBase should go to Core and be as is now (or make the changes you estimate)


> -The goal of most component sets in Royale is to abstract away the
> underlying platform APIs.  That's why I'm not in favor of having a
> classList API on UIBase.
>

Right, classList is JS only so maybe an API in JewelUIBase should be
general and use the JS code with COMPILE::JS
then implement others.

-MXML is better with space delimited string lists instead of arrays.
>

I think in you version and my version is a string, but in mine then is
converted to feed classList


> -It doesn't make sense to split strings into an array in JS when the
> browser clearly can do it.
> -This perf test shows className is faster [1]
> -So does this one [2]
>
>
> We are starting from a list of strings.  MDL is not.  And that makes a
> difference, IMO.
>
>
ok in Jewel we could do in that way, the main difference with Basic is that
the main task of this kind of set is
heavily deal with class selectors so for Jewel (not for Basic) we should
focus on it what means to me be fundamental part of JewelUIBase to have an
API to deal with styles in all platforms and that all components extending
it can use.


> I forgot to mention earlier that I was not happy that addStyles and
> friends were JS-only.  It would have been better if it did not take an
> element since that is a JS platform implementation.  That way application
> developers could use addStyles and friends to manipulate the set of class
> selectors at runtime.
>

ok, that's a fail on my implementation that should be fixed


>
> More comments in-line..
>
> [1]
> https://measurethat.net/Benchmarks/Show/54/0/
> classname-vs-setattribute-vs-c
> lasslist
> [2] https://jsperf.com/classname-vs-classlist-showdown/5
>
> On 4/13/18, 7:18 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi,
> >
> >I think the discussion now should center in numbers.
> >
> >I added "performance.now()" to typedefs (how could we live without this
> >until now? :))
>
> Snip...
> >
> >
> >I think numbers are near identical right?
> >
> >
> >So given very close numbers should make us choose the more simplest code
> >
> >
> >right?
> >
> No.  Small samples are often not useful.  These kinds of arguments are the
> ones that led to UIComponent being 13,000 lines in Flex.
>

I think here we are talking about performance, not about to increase number
of lines of code


>
>
> >
> >
> >2018-04-14 2:58 GMT+02:00 Carlos Rovira :
> >
> >> Hi Alex,
> >>
> >> just studied you changes and want to ask you a few things:
> >>
> >> 1) Why className and classLists methods must remain unsynced? I think
> >>this
> >> is not necessary and seems to me a bit unnatural since when I add styles
> >> though classList in a element this makes the internal list changed, and
> >>if
> >> I then do "trace(element.className)" it will report the updated
> >>list...so I
> >> think both are synced by default
>
> I proposed a way to have components that want to use classList pay for it.
>  If you want to further penalize those components in order to maintain
> synchronization of classList and className go ahead as long as it doesn't
> impact org.apache.flex.core.UIBase.  Yes, the browser keeps className and
> classList in sync, but you are missing that the emphasized, primary and
> secondary selectors are not in the className list maintained by UIBase and
> there is additional cost to doing so.
>
>
That's because when I refactored the code when you ask me to do so I tried
to make it
className dependent. I think the solution is in JewelUIBase wire all
through classList.
we'll have a tiny performance hit, that's right, but I think a uiset with
the purpose of Jewel
(theming - styling - goof looking) is the price that have to pay. a little
less performance than Basic



>
> >>
> >> 2) Now Button has two new methods that must make various operations with
> >> arrays (join, push, splice...), this means in almost all jewel
> >>components
> >> override at least computeFinalClassNames and insert new custom methods
> >>for
> >> add/toggle/remove and each one will make various operations: in the
> >>case of
> >> toggle will do a push or splice and then the normal classList toggle
> >> operation.
> >>
> It is probably possible to package up the code I added to Jewel Button and
> make it re-usable without inserting a base class for all of Jewel.  Or is
> absolutely every Jewel component 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Carlos,

It seems like either you have missed some of the discussion or maybe we
weren't clear enough.

Simply put:
-The Basic components do not need to handle classList APIs.  There is no
expectation that classes will be frequently added and removed.
-The goal of most component sets in Royale is to abstract away the
underlying platform APIs.  That's why I'm not in favor of having a
classList API on UIBase.
-MXML is better with space delimited string lists instead of arrays.
-It doesn't make sense to split strings into an array in JS when the
browser clearly can do it.
-This perf test shows className is faster [1]
-So does this one [2]


We are starting from a list of strings.  MDL is not.  And that makes a
difference, IMO.

I forgot to mention earlier that I was not happy that addStyles and
friends were JS-only.  It would have been better if it did not take an
element since that is a JS platform implementation.  That way application
developers could use addStyles and friends to manipulate the set of class
selectors at runtime.

More comments in-line..

[1] 
https://measurethat.net/Benchmarks/Show/54/0/classname-vs-setattribute-vs-c
lasslist
[2] https://jsperf.com/classname-vs-classlist-showdown/5

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

>Hi,
>
>I think the discussion now should center in numbers.
>
>I added "performance.now()" to typedefs (how could we live without this
>until now? :))

Snip...
>
>
>I think numbers are near identical right?
>
>
>So given very close numbers should make us choose the more simplest code
>
>
>right?
>
No.  Small samples are often not useful.  These kinds of arguments are the
ones that led to UIComponent being 13,000 lines in Flex.


>
>
>2018-04-14 2:58 GMT+02:00 Carlos Rovira :
>
>> Hi Alex,
>>
>> just studied you changes and want to ask you a few things:
>>
>> 1) Why className and classLists methods must remain unsynced? I think
>>this
>> is not necessary and seems to me a bit unnatural since when I add styles
>> though classList in a element this makes the internal list changed, and
>>if
>> I then do "trace(element.className)" it will report the updated
>>list...so I
>> think both are synced by default

I proposed a way to have components that want to use classList pay for it.
 If you want to further penalize those components in order to maintain
synchronization of classList and className go ahead as long as it doesn't
impact org.apache.flex.core.UIBase.  Yes, the browser keeps className and
classList in sync, but you are missing that the emphasized, primary and
secondary selectors are not in the className list maintained by UIBase and
there is additional cost to doing so.


>>
>> 2) Now Button has two new methods that must make various operations with
>> arrays (join, push, splice...), this means in almost all jewel
>>components
>> override at least computeFinalClassNames and insert new custom methods
>>for
>> add/toggle/remove and each one will make various operations: in the
>>case of
>> toggle will do a push or splice and then the normal classList toggle
>> operation.
>>
It is probably possible to package up the code I added to Jewel Button and
make it re-usable without inserting a base class for all of Jewel.  Or is
absolutely every Jewel component going to need that code?  If so, then
maybe a common base class for all of Jewel makes sense.

Also, the code I added to Jewel Button is can be greatly simplified if you
assume folks will not directly set className after adding to parent.


>> 3) we are introducing a new array property per component to store what
>> classList already do

No, the array does not have to have as many elements as the classList.
>>
>> So for me we are introducing lots of complexity, with more code splitter
>> in every class, each one with more operations of array operations that
>> finaly makes the same call I did. And generating complexity since
>>className
>> should be used by users only at init time and then use the rest of
>> classList apis...

That's PAYG.  The classes that need it get the additional complexity.  And
again, if we want to restrict setting classname after init in Jewel,
that's totally fine with me and will simplify the code.
>>
>> The only difference for me is that you want to avoid the classList
>>initial
>> add method that in most of the cases will add from 1 or 2 classes and
>>up to
>> 3-4-5. I think normal components would have 3 on average...
>>
>> This related to lots of sites saying "use classList instead of
>>className"
>> and frameworks like MDL that are based only on classList , and all
>>jsperfs
>> (that although are not reflecting our concrete use case and use of
>> classList, I think are completely valid on essence) makes me think about
>> how we have such different visions.
>>
>> So I must to say that as much as I want to see the advantages the
>> approaches do not convince me...
>>

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi,

I think the discussion now should center in numbers.

I added "performance.now()" to typedefs (how could we live without this
until now? :))

I added this code to Jewel Button:

public var start;

public var end;

override public function addedToParent():void

{

COMPILE::JS

{

start = performance.now();

}

super.addedToParent();


COMPILE::JS

{

end = performance.now();

var time = end - start;

trace('Button Execution time: ' + time);

}

}


Here's execution on current develop:

Button Execution time: 0.2000949949026

Language.js:237 Button Execution time: 0

2Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0.2000949949026

4Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0.0997564591467

Language.js:237 Button Execution time: 0.2000949949026

Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0

Language.js:237 Button Execution time: 0

2Language.js:237 Button Execution time: 0.1000474974513


Here's the execution on "feature/uibase-classname"


Button Execution time: 0.199803956598

3Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0.2000949949026

2Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0.199803956598

Language.js:237 Button Execution time: 0.2000949949026

Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0

2Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0

Language.js:237 Button Execution time: 0.1000474974513

Language.js:237 Button Execution time: 0


I think numbers are near identical right?


So given very close numbers should make us choose the more simplest code


right?


Carlos





2018-04-14 2:58 GMT+02:00 Carlos Rovira :

> Hi Alex,
>
> just studied you changes and want to ask you a few things:
>
> 1) Why className and classLists methods must remain unsynced? I think this
> is not necessary and seems to me a bit unnatural since when I add styles
> though classList in a element this makes the internal list changed, and if
> I then do "trace(element.className)" it will report the updated list...so I
> think both are synced by default
>
> 2) Now Button has two new methods that must make various operations with
> arrays (join, push, splice...), this means in almost all jewel components
> override at least computeFinalClassNames and insert new custom methods for
> add/toggle/remove and each one will make various operations: in the case of
> toggle will do a push or splice and then the normal classList toggle
> operation.
>
> 3) we are introducing a new array property per component to store what
> classList already do
>
> So for me we are introducing lots of complexity, with more code splitter
> in every class, each one with more operations of array operations that
> finaly makes the same call I did. And generating complexity since className
> should be used by users only at init time and then use the rest of
> classList apis...
>
> The only difference for me is that you want to avoid the classList initial
> add method that in most of the cases will add from 1 or 2 classes and up to
> 3-4-5. I think normal components would have 3 on average...
>
> This related to lots of sites saying "use classList instead of className"
> and frameworks like MDL that are based only on classList , and all jsperfs
> (that although are not reflecting our concrete use case and use of
> classList, I think are completely valid on essence) makes me think about
> how we have such different visions.
>
> So I must to say that as much as I want to see the advantages the
> approaches do not convince me...
>
> for me is more simple that all of that.
>
> 1) I think people have the APIs (className and classList) and can/will do
> what they want, although we say "use className only at init time".
>
> 2) I think we should have the most easy way to modify since browsers are
> takin care of internal apis performance (or at least I'm confident with
> that, like I was confident on flash player performance)
>
> 3) I don't like to introduce lots of code when maybe the basic usage of
> classList can be even more efficient. I give various jsperf studies out
> there but both Harbs and you didn't show me anyone that shows className as
> a better option.
>
> 4) If we are introducing such complexity, wouldn't be better to remove
> completely classList and end that code with the new array property and
> array operations? I think it will be more performant and will remove
> complexity.
>
> 5) If I use that solution for jewel, I should 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

just studied you changes and want to ask you a few things:

1) Why className and classLists methods must remain unsynced? I think this
is not necessary and seems to me a bit unnatural since when I add styles
though classList in a element this makes the internal list changed, and if
I then do "trace(element.className)" it will report the updated list...so I
think both are synced by default

2) Now Button has two new methods that must make various operations with
arrays (join, push, splice...), this means in almost all jewel components
override at least computeFinalClassNames and insert new custom methods for
add/toggle/remove and each one will make various operations: in the case of
toggle will do a push or splice and then the normal classList toggle
operation.

3) we are introducing a new array property per component to store what
classList already do

So for me we are introducing lots of complexity, with more code splitter in
every class, each one with more operations of array operations that finaly
makes the same call I did. And generating complexity since className should
be used by users only at init time and then use the rest of classList
apis...

The only difference for me is that you want to avoid the classList initial
add method that in most of the cases will add from 1 or 2 classes and up to
3-4-5. I think normal components would have 3 on average...

This related to lots of sites saying "use classList instead of className"
and frameworks like MDL that are based only on classList , and all jsperfs
(that although are not reflecting our concrete use case and use of
classList, I think are completely valid on essence) makes me think about
how we have such different visions.

So I must to say that as much as I want to see the advantages the
approaches do not convince me...

for me is more simple that all of that.

1) I think people have the APIs (className and classList) and can/will do
what they want, although we say "use className only at init time".

2) I think we should have the most easy way to modify since browsers are
takin care of internal apis performance (or at least I'm confident with
that, like I was confident on flash player performance)

3) I don't like to introduce lots of code when maybe the basic usage of
classList can be even more efficient. I give various jsperf studies out
there but both Harbs and you didn't show me anyone that shows className as
a better option.

4) If we are introducing such complexity, wouldn't be better to remove
completely classList and end that code with the new array property and
array operations? I think it will be more performant and will remove
complexity.

5) If I use that solution for jewel, I should introduce some intermediate
class between UIBase and a Jewel Component where I can proxy all that
methods that are now in button to avoid replicate in all jewel components.
And by doing that, as I said before, I'll prefer to remove that complexity
and go for simple classList manipulation since is the same that MDL (to
name a concrete and successful project that renders and performs
magnificent) does [1] (I put button example just as an example since
there's lots more)

Sincerily, I'm not convinced with the results exposed here, and I was
always thinking that I was not seeing something evident, but now I'm even
more convinced that we should use classList without any rejection. Even for
the use of className in MXML, is ok since I proved you can transform it
without problem getting the string, splitting and introducing in the
classList, and then opertating with is when needed without any performance
significant problem. For me is more problematic all the code we want to
introduce to avoid possible performance problems that I and many others
don't see and that main web projects actually don't see and are used all
over the web. We should not be different in something that other has
already adopted, and if people is using it, is because the browsers, the
standards and all the web wants all people using it, and for me is what
happen with classList.

in resume. I still don't want to make this discussion longer. I think we
have different opinions on this particular subject and the greatness of
royale is that it doesn't mind since if you and Harbs are betting for
className, we can remain Basic with the initial use (or the current one).
For Jewel, I can bet for the same method MDL uses with classList and as I
must to refactor half of the Jewel components to extend from UIBase
directly instead of Basic components counterparts, I can put a JewelUIBase
piece between that uses classList in the way Jewel need. In fact Jewel, and
any of the modern UI sets (Semantic, MDL, Bootstrap, ...) depends heavily
in class selector assignation, hence the use of classList as a general
rule. So I think is natural to have this marked differentiation, while in
Basic we should not expect people wants to deal with class selectors in a
heavy use.

Maybe I can wrong, but sincerely, 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

I made some changes to the feature/uibase-classname branch and pushed them.

The only code change in UIBase is to go back to setting element.className
instead of calling addStyles to split the list again.
Mainly I added documentation to UIBase and the classList helper functions
to explain how they interact.
Then I added code to Jewel Button to handle its properties that toggle
styles in the classList.

A key point is understanding the lifecycle.  Hopefully, in just about
every instance, the element.className will be set once in addedtoParent
and then properties can toggle styles on the classList and it will just
work.

We could say that you can't set className after addedToParent.  That would
simplify the code in Jewel Button that saves the propertyNames to be added
to computeFinalClassNames.

Basically, though, I think this implementation matches the scenarios.

Thoughts?
-Alex

On 4/11/18, 2:37 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>to resume,
>
>1) I agree with most of your mail. My main need is to use an API that let
>me add/remove/toggle styles easily (mine and whoever wants to deal with
>styling).
>So if you think my changes to UIBase are not ok and you want to ensure
>things are more as you have in mind, that's ok with me. But to avoid more
>investing time in discussion I prefer wait for you to make the changes in
>the UIBase classname branch. I assume that the way I use it though new
>methods like "addStyles" will not change, and so I can continue my work
>with the rest of components. So in this point I'll wait for you changes if
>is ok for you.
>

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Hi Carlos,

I think we should move UIBase back into Core.  Then maybe it will be more
clear that Basic is just a set of components and not really any more
special than any other set.

IMO, the logic around what to subclass in some other component set is
standard computer science.  How much code is being shared, re-used,
overridden, etc.  Usability (does there need to be a common base class for
folks mixing component sets (hopefully no, interfaces should be used
instead)).  Things like that.  So you are best judge of what to subclass
and our users will tell us if they don't like it.

Thanks,
-Alex 

On 4/11/18, 1:41 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>No, I'm not talking about JewelUIBase. If you do 1), then I'll use that,
>What I say is if you think Jewel Button and the rest of components, should
>extend directly UIBase (and copy paste functionality of the counterpart
>component in Basic if apply), or extend the Basic counterpart.
>I'm for making all Jewel components extends directly UIBase
>
>My question is if you share the same concept
>
>thanks
>
>
>
>2018-04-11 21:33 GMT+02:00 Alex Harui :
>
>>
>> >2) About Jewel UIBase extension: I think is better to always extend
>>UIBase
>> >than the Basic component as a rule. So I'll normalize the current Jewel
>> >components so Basic and Jewel will be siblings and extend from UIBase
>> >instead jewel extend basic and basic UIBase. Let me know if you agree
>>with
>> >me that this is a better decision.
>>
>> I'm not quite sure what you mean here.  I don't think Jewel needs its
>>own
>> UIBase.  It should be able to use the one in Basic.
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C250837f2c4404b83d85508d5
>9fecaec3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636590761338123467
>data=6CyylVKceFeVVBD0NaTiOfVkUR5CRGLMNBL2SxsemJM%3D=0

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

No, I'm not talking about JewelUIBase. If you do 1), then I'll use that,
What I say is if you think Jewel Button and the rest of components, should
extend directly UIBase (and copy paste functionality of the counterpart
component in Basic if apply), or extend the Basic counterpart.
I'm for making all Jewel components extends directly UIBase

My question is if you share the same concept

thanks



2018-04-11 21:33 GMT+02:00 Alex Harui :

>
> >2) About Jewel UIBase extension: I think is better to always extend UIBase
> >than the Basic component as a rule. So I'll normalize the current Jewel
> >components so Basic and Jewel will be siblings and extend from UIBase
> >instead jewel extend basic and basic UIBase. Let me know if you agree with
> >me that this is a better decision.
>
> I'm not quite sure what you mean here.  I don't think Jewel needs its own
> UIBase.  It should be able to use the one in Basic.
>


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

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

On 4/11/18, 2:37 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>to resume,
>
>1) I agree with most of your mail. My main need is to use an API that let
>me add/remove/toggle styles easily (mine and whoever wants to deal with
>styling).
>So if you think my changes to UIBase are not ok and you want to ensure
>things are more as you have in mind, that's ok with me. But to avoid more
>investing time in discussion I prefer wait for you to make the changes in
>the UIBase classname branch. I assume that the way I use it though new
>methods like "addStyles" will not change, and so I can continue my work
>with the rest of components. So in this point I'll wait for you changes if
>is ok for you.

OK, I will make the changes after I finish up a few other things.
>
>2) About Jewel UIBase extension: I think is better to always extend UIBase
>than the Basic component as a rule. So I'll normalize the current Jewel
>components so Basic and Jewel will be siblings and extend from UIBase
>instead jewel extend basic and basic UIBase. Let me know if you agree with
>me that this is a better decision.

I'm not quite sure what you mean here.  I don't think Jewel needs its own
UIBase.  It should be able to use the one in Basic.

>
>3) about separation of styles in CSS, in this part I not agree. I don't
>think is just stylistic code decision, or for me that's not the main
>motivation behind. I think that setting things like, "display", width or
>height or padding in the component class is a bad design choice, since
>you're making that component coupled to that decisions, while here for me
>applys the "separation of concerns" concept.
>Why basic label sets word-wrap in the class instead of in the CSS Label
>rule as with the rest of its beads? For me that's the right place to do
>so.
>For me the class setups the HTML structure (i.e, span, div,...) and wire
>the needed JS, then the CSS should set up all styles and transition
>effects, since is how things works in HTML. I think things like
>"display:none" should be managed, not setting that as is, but to adding a
>class "visible" to the component class list. Is this more/less efficient.
>I
>don't thing it makes any difference in performance, nobody here can said
>that is better through the myriad of browser implementations and its
>different performances, but most important in this case is separation of
>concerns and how we organize the code. since a CSS rule like ".visible"
>used for all components to set display to none or not, makes more reusable
>that code and more easy to deal with that, and then in JS you can make
>that
>and in SWF use a different code.

If it isn't stylistic, then you should be able to provide technical
reasoning including articles on the internet explaining why using styles
object is wrong or inefficient.  Every website I look at is using both
classes and the style object directly, even the WordPress generated
royale.a.o.  The APIs allow us to use the style object.  They allow us to
use classList and/or className.  What you want to do appears to be a
preference without any technical justification.  There is nothing in
Royale that prevents you from contributing layouts that use classes
instead of the style object.

If you want to discuss about why UIBase.visible=false sets display:none on
the style object, I guess we can have that discussion.  To me, using the
style object makes sense so you don't have to worry about other class
selectors with display styles taking precedence.

If you want to discuss about why Label sets wordWrap:none on the style
object, we can have that discussion as well.  To me, the reasoning is
similar.  You can't control the order of precedence in class selectors,
and the Basic Label should be single line and not have that messed with by
folks editing CSS.  You are welcome to create a different Label in Jewel
if you want.

Thanks,
-Alex
>
>
>2018-04-11 7:13 GMT+02:00 Alex Harui :
>
>> Hi Carlos,
>>
>> My proposal uses classList, but only where it will be optimal to use it
>> given the scenarios.  I think you misunderstood scenario 4.  The
>> application developer can certainly cause classes to be added and
>>removed
>> at runtime by manipulating properties on the component like "secondary"
>>or
>> "emphasized", but the actual applying of those styles are done by
>> framework code we write.  IMO, other than the components that have the
>> same names as HTMLElements, we want the other Basic components and other
>> Royale components to abstract the underlying browser implementations so
>>if
>> we ever target another platform or output language, we aren't as tied to
>> browser APIs.
>>
>> IMO, the reason there is both a classList and className API on
>>HTMLElement
>> is that it can be more efficient to use one or the other in certain
>> scenarios.  Instead of trying to always use classList or always use
>> className, my 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

to resume,

1) I agree with most of your mail. My main need is to use an API that let
me add/remove/toggle styles easily (mine and whoever wants to deal with
styling).
So if you think my changes to UIBase are not ok and you want to ensure
things are more as you have in mind, that's ok with me. But to avoid more
investing time in discussion I prefer wait for you to make the changes in
the UIBase classname branch. I assume that the way I use it though new
methods like "addStyles" will not change, and so I can continue my work
with the rest of components. So in this point I'll wait for you changes if
is ok for you.

2) About Jewel UIBase extension: I think is better to always extend UIBase
than the Basic component as a rule. So I'll normalize the current Jewel
components so Basic and Jewel will be siblings and extend from UIBase
instead jewel extend basic and basic UIBase. Let me know if you agree with
me that this is a better decision.

3) about separation of styles in CSS, in this part I not agree. I don't
think is just stylistic code decision, or for me that's not the main
motivation behind. I think that setting things like, "display", width or
height or padding in the component class is a bad design choice, since
you're making that component coupled to that decisions, while here for me
applys the "separation of concerns" concept.
Why basic label sets word-wrap in the class instead of in the CSS Label
rule as with the rest of its beads? For me that's the right place to do so.
For me the class setups the HTML structure (i.e, span, div,...) and wire
the needed JS, then the CSS should set up all styles and transition
effects, since is how things works in HTML. I think things like
"display:none" should be managed, not setting that as is, but to adding a
class "visible" to the component class list. Is this more/less efficient. I
don't thing it makes any difference in performance, nobody here can said
that is better through the myriad of browser implementations and its
different performances, but most important in this case is separation of
concerns and how we organize the code. since a CSS rule like ".visible"
used for all components to set display to none or not, makes more reusable
that code and more easy to deal with that, and then in JS you can make that
and in SWF use a different code.







2018-04-11 7:13 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> My proposal uses classList, but only where it will be optimal to use it
> given the scenarios.  I think you misunderstood scenario 4.  The
> application developer can certainly cause classes to be added and removed
> at runtime by manipulating properties on the component like "secondary" or
> "emphasized", but the actual applying of those styles are done by
> framework code we write.  IMO, other than the components that have the
> same names as HTMLElements, we want the other Basic components and other
> Royale components to abstract the underlying browser implementations so if
> we ever target another platform or output language, we aren't as tied to
> browser APIs.
>
> IMO, the reason there is both a classList and className API on HTMLElement
> is that it can be more efficient to use one or the other in certain
> scenarios.  Instead of trying to always use classList or always use
> className, my proposal uses both depending on which will be most
> efficient, and also presents an abstraction that is backward compatible
> with Flex and does not tie us to a browser implementation.  One key thing
> to remember is that lots of articles you find on the internet are about
> working with hand-written JS and CSS.  In Royale, we have a component
> lifecycle and can control when code runs and thus some internet advice
> does not apply.
>
> If you are asking me to code up my proposal so you can see it, I guess I
> will take the time to do so, or maybe Harbs can do it.
>
> Regarding whether Jewel Slider extends Basic Slider, now that I understand
> what you are saying, that isn't a problem for me.  But whether you extend
> Basic Slider or not, the hope is that both Slider components implement the
> same pattern:  the outer component proxies properties to/from a model or
> directly to an HTMLElement.  And if there is a View, it pulls data from
> the model.
>
> Changes to UIBase probably should result in lengthy discussion to make
> sure it is truly necessary.  UIBase changes will have impact everywhere.
> We need to consider PAYG, size, performance, usability and more.  This is
> the most important thing to me.  I do not want to see us repeat the
> mistakes of Flex where we just packed the latest idea onto UIComponent
> until it became 13,000 lines that dragged in all kinds of dependencies.
>
> But, IMO, we have to separate technical decisions from stylistic
> decisions.  IMO, your desire to not have any Royale component set a style
> directly and only add classes is a stylistic decision.  I think Harbs has
> shown that it is less 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Hi Carlos,

My proposal uses classList, but only where it will be optimal to use it
given the scenarios.  I think you misunderstood scenario 4.  The
application developer can certainly cause classes to be added and removed
at runtime by manipulating properties on the component like "secondary" or
"emphasized", but the actual applying of those styles are done by
framework code we write.  IMO, other than the components that have the
same names as HTMLElements, we want the other Basic components and other
Royale components to abstract the underlying browser implementations so if
we ever target another platform or output language, we aren't as tied to
browser APIs.

IMO, the reason there is both a classList and className API on HTMLElement
is that it can be more efficient to use one or the other in certain
scenarios.  Instead of trying to always use classList or always use
className, my proposal uses both depending on which will be most
efficient, and also presents an abstraction that is backward compatible
with Flex and does not tie us to a browser implementation.  One key thing
to remember is that lots of articles you find on the internet are about
working with hand-written JS and CSS.  In Royale, we have a component
lifecycle and can control when code runs and thus some internet advice
does not apply.

If you are asking me to code up my proposal so you can see it, I guess I
will take the time to do so, or maybe Harbs can do it.

Regarding whether Jewel Slider extends Basic Slider, now that I understand
what you are saying, that isn't a problem for me.  But whether you extend
Basic Slider or not, the hope is that both Slider components implement the
same pattern:  the outer component proxies properties to/from a model or
directly to an HTMLElement.  And if there is a View, it pulls data from
the model.

Changes to UIBase probably should result in lengthy discussion to make
sure it is truly necessary.  UIBase changes will have impact everywhere.
We need to consider PAYG, size, performance, usability and more.  This is
the most important thing to me.  I do not want to see us repeat the
mistakes of Flex where we just packed the latest idea onto UIComponent
until it became 13,000 lines that dragged in all kinds of dependencies.

But, IMO, we have to separate technical decisions from stylistic
decisions.  IMO, your desire to not have any Royale component set a style
directly and only add classes is a stylistic decision.  I think Harbs has
shown that it is less efficient.  But if that's how you want to write your
code, that's fine.  Royale is designed to provide choices.  Often there is
no one right way.

Anyway, let's see if we can get consensus on the changes to UIBase.  IMO,
that's the only thing we need to agree on.  If you still need to see it in
code, let us know.

Thanks,
-Alex  

On 4/10/18, 2:49 PM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>2018-04-10 21:17 GMT+02:00 Alex Harui :
>
>> Hi Carlos,
>>
>> I think I'm still confused.  Earlier you said that half of Jewel
>> components do not extend Basic components.  What do they extend and why?
>>
>
>When I said does not extend Basic components, I mean that doesn't extend
>it
>counterpart (i.e. Jewel Slider does not extend Basic Slider, since are
>very
>different), if not extend its counterpart at least extends UIBase
>
>
>>
>> I think I have proposed a solution to how we handle classNames that
>>should
>> work for Jewel, MDL and all other components.
>
>
>I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3 but
>not with 4.
>For example Button.primary will need to set "primary" class" but as well
>remove others
>like "secondary" or "emphasized" since only one of them should exists at a
>time.
>This is the same in MDL. Nowadays all set like MDL uses this a lot, since
>all visuals
>depends on this things.
>
>
>> I think it would be better
>> for Royale to be able to use Jewel theme without a JewelUIBase unless
>> there is a really good technical reason.
>
>
>We should get to a consensus to reach this.  I really prefer to stick with
>UIBase if possible.
>
>
>> I was hoping Jewel really would
>> be the replacement of views and HTMLElements in the existing Basic
>> components.
>>
>
>the problem with that is that it's making a change in basic is very time
>consuming since we all disagree on how to make things. and we have the
>following problems:
>
>1) Basic is now used by people and changes on it can break code. For me
>that's ok, since I think we are in 0.9 and change things should be normal,
>but then
>many of you will oppose to changes, so...
>
>2) ..this makes each change a discussion that makes us to spend several
>hours
>
>3) in the other hand we want basic to remain basic. that could be ok if we
>use views, but in the other hand we need some property methods in the
>class
>(think in
>"primary", "secondary" and 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

2018-04-10 21:17 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I think I'm still confused.  Earlier you said that half of Jewel
> components do not extend Basic components.  What do they extend and why?
>

When I said does not extend Basic components, I mean that doesn't extend it
counterpart (i.e. Jewel Slider does not extend Basic Slider, since are very
different), if not extend its counterpart at least extends UIBase


>
> I think I have proposed a solution to how we handle classNames that should
> work for Jewel, MDL and all other components.


I think you refer to the mail with the 4 scenarios. I'm ok with 1,2,3 but
not with 4.
For example Button.primary will need to set "primary" class" but as well
remove others
like "secondary" or "emphasized" since only one of them should exists at a
time.
This is the same in MDL. Nowadays all set like MDL uses this a lot, since
all visuals
depends on this things.


> I think it would be better
> for Royale to be able to use Jewel theme without a JewelUIBase unless
> there is a really good technical reason.


We should get to a consensus to reach this.  I really prefer to stick with
UIBase if possible.


> I was hoping Jewel really would
> be the replacement of views and HTMLElements in the existing Basic
> components.
>

the problem with that is that it's making a change in basic is very time
consuming since we all disagree on how to make things. and we have the
following problems:

1) Basic is now used by people and changes on it can break code. For me
that's ok, since I think we are in 0.9 and change things should be normal,
but then
many of you will oppose to changes, so...

2) ..this makes each change a discussion that makes us to spend several
hours

3) in the other hand we want basic to remain basic. that could be ok if we
use views, but in the other hand we need some property methods in the class
(think in
"primary", "secondary" and "emphasized" in Jewel Buttonwe can't create
them in basic button, since no body will allow that, so, this makes jewel
themes partially unusable.

4) the other huge point for me is that I don't understand style code in a
component. For me this is not optional and that is in many Basic code un
components and layouts.

So I see basic mostly difficult to skin and will be use as you said for
people that doesnt't want any overhead, but that's not my target in this
project, for this reason I doing Jewel.

Alex, I think classList is a must nowadays in browser space, I already said
in lots of emails. All great projects use it.
I post a link from MDL that states that one of the things they require in a
browser (between others) is that support classList.

But, if you really thing classList is not ok, and you have a better
proposal of an API that allows me to add/remove easily classes at runtime,
I think is better that you implement it in the branch we have, removing my
changes so I can really understand and test it. I think that would be
better for all of us. I posted my proposal. I think you should post yours.
If I try it and works, I'm sure yours will be very efficient, so I think we
can go with that. But we should not continue discussing without that code
to test, since I see we are doesn't understanding ok one to each other
since maybe you and I are interpreting in our way what the other want to
express.

For that reason and to avoid another long discussion, my position was to
extend UIBase with classList methods, that we already discussed for long
time in other thread
in this way Basic components will not need classList, but Jewel will need,
since is needed.

I think we should take a path or another, and to do this and avoid lost
more time in emails, is that you put the few lines of code you thing are
right in a commit in the uibase changes branch, so I can test it

Let me know what do you think about it

Thanks

Carlos




>
> Thanks,
> -Alex
>
> On 4/10/18, 9:55 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >Jewel components extends UIBase or the basic version
> >For example
> >Jewel Button extends Basic Button,
> >Jewel TextField extends Basic TextField
> >Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an input
> >range and not 2 buttons)
> >
> >the main reason is that majority of basic controls can be what Jewel needs
> >except for html needed (we needed structures most like MDL does) and need
> >to add some property methods to add  / remove CSS rules.
> >
> >That's the main reason behind, in the end is to replicate what I did in
> >MDL
> >but using royale components and our own structure since we define the
> >theme
> >css rule selectors.
> >
> >Hope it make more sense now.
> >
> >thanks
> >
> >Carlos
> >
>

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

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Hi Carlos,

I think I'm still confused.  Earlier you said that half of Jewel
components do not extend Basic components.  What do they extend and why?

I think I have proposed a solution to how we handle classNames that should
work for Jewel, MDL and all other components.  I think it would be better
for Royale to be able to use Jewel theme without a JewelUIBase unless
there is a really good technical reason.  I was hoping Jewel really would
be the replacement of views and HTMLElements in the existing Basic
components.

Thanks,
-Alex

On 4/10/18, 9:55 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>Jewel components extends UIBase or the basic version
>For example
>Jewel Button extends Basic Button,
>Jewel TextField extends Basic TextField
>Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an input
>range and not 2 buttons)
>
>the main reason is that majority of basic controls can be what Jewel needs
>except for html needed (we needed structures most like MDL does) and need
>to add some property methods to add  / remove CSS rules.
>
>That's the main reason behind, in the end is to replicate what I did in
>MDL
>but using royale components and our own structure since we define the
>theme
>css rule selectors.
>
>Hope it make more sense now.
>
>thanks
>
>Carlos
>
>
>
>
>2018-04-10 18:41 GMT+02:00 Alex Harui :
>
>> Hi Carlos,
>>
>> I'm not sure if it is better for Jewel to extend from UIBase or not.  I
>> just want to understand the technical reasons why you decided not to
>> extend UIBase.  We want to make sure UIBase works for as many people as
>> possible, but on the other hand, I wouldn't mind proving that the
>> framework doesn't require org.apache.royale.core.UIBase.  Hopefully the
>> framework uses IUIBase instead.  It should be ok for someone to come up
>> with a completely different base class as long as it conforms to IUIBase
>> and other interfaces.
>>
>> Thanks,
>> -Alex
>>
>> On 4/10/18, 8:54 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi Alex,
>> >
>> >the plan was to reuse as much as I can basic functionality. You think
>>is
>> >better to extend directly from UIBase? (In this case JewelUIBase)
>> >If you think is better, then I'll go that path and we can UIBase
>> >untouched.
>> >
>> >thanks
>> >
>> >2018-04-10 17:15 GMT+02:00 Alex Harui :
>> >
>> >> Why are Jewel components not extending UIBase?
>> >>
>> >> On 4/10/18, 3:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
>> >>Rovira"
>> >>  wrote:
>> >>
>> >> >Hi
>> >> >
>> >> >I think we can take another approach. Since I'm finding that half of
>> >>Jewel
>> >> >components are not extending basic components for one reason or
>> >>another,
>> >> >maybe a good option would be:
>> >> >
>> >> >1.- Left UIBase untouched
>> >> >
>> >> >2.- Make JewelUIBase that extends UIBase, and introduced that code
>> >> >
>> >> >3.- Refactor Jewel components to use JewelUIBase
>> >> >
>> >> >In this way Basic, and other sets will remain untouched and not
>> >>affected
>> >> >by
>> >> >this change
>> >> >
>> >> >Let me know what do you think about it.
>> >> >
>> >> >Thanks
>> >> >
>> >> >
>> >> >2018-04-10 9:11 GMT+02:00 Harbs :
>> >> >
>> >> >> The article you linked to was a very old article. I already
>> >>responded to
>> >> >> that. I would need some tests to prove that it’s still true today.
>> >>The
>> >> >> tests that I saw seemed to indicate that it wasn’t.
>> >> >>
>> >> >> Philosophically, I think you are tying the behavior of UIBase too
>> >> >>closely
>> >> >> with the thinking behind Jewel which relies very heavily on class
>> >>names
>> >> >>and
>> >> >> requires that users do not change that. I don’t think that’s going
>> >>to be
>> >> >> true for every component set.
>> >> >>
>> >> >> I completely agree with Alex’s response.
>> >> >>
>> >> >> My $0.02,
>> >> >> Harbs
>> >> >>
>> >> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira
>> >>
>> >> >> wrote:
>> >> >> >
>> >> >> > Harbs,
>> >> >> >
>> >> >> > I though I did it. I give links to peformance links that for me
>> >>proved
>> >> >> that
>> >> >> > people is going through classList.
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> >--
>> >> >Carlos Rovira
>> >> >https://na01.safelinks.protection.outlook.com/?url=
>> >> http%3A%2F%2Fabout.me%2
>> >> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
>> >> 7Cdaafba5ff16a4a20856508d5
>> >> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> >> 7C636589539427581762
>> >> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D=0
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

Jewel components extends UIBase or the basic version
For example
Jewel Button extends Basic Button,
Jewel TextField extends Basic TextField
Jewel Slider extends UIBase (since in Jewel like in MDL Slider is an input
range and not 2 buttons)

the main reason is that majority of basic controls can be what Jewel needs
except for html needed (we needed structures most like MDL does) and need
to add some property methods to add  / remove CSS rules.

That's the main reason behind, in the end is to replicate what I did in MDL
but using royale components and our own structure since we define the theme
css rule selectors.

Hope it make more sense now.

thanks

Carlos




2018-04-10 18:41 GMT+02:00 Alex Harui :

> Hi Carlos,
>
> I'm not sure if it is better for Jewel to extend from UIBase or not.  I
> just want to understand the technical reasons why you decided not to
> extend UIBase.  We want to make sure UIBase works for as many people as
> possible, but on the other hand, I wouldn't mind proving that the
> framework doesn't require org.apache.royale.core.UIBase.  Hopefully the
> framework uses IUIBase instead.  It should be ok for someone to come up
> with a completely different base class as long as it conforms to IUIBase
> and other interfaces.
>
> Thanks,
> -Alex
>
> On 4/10/18, 8:54 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi Alex,
> >
> >the plan was to reuse as much as I can basic functionality. You think is
> >better to extend directly from UIBase? (In this case JewelUIBase)
> >If you think is better, then I'll go that path and we can UIBase
> >untouched.
> >
> >thanks
> >
> >2018-04-10 17:15 GMT+02:00 Alex Harui :
> >
> >> Why are Jewel components not extending UIBase?
> >>
> >> On 4/10/18, 3:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
> >>Rovira"
> >>  wrote:
> >>
> >> >Hi
> >> >
> >> >I think we can take another approach. Since I'm finding that half of
> >>Jewel
> >> >components are not extending basic components for one reason or
> >>another,
> >> >maybe a good option would be:
> >> >
> >> >1.- Left UIBase untouched
> >> >
> >> >2.- Make JewelUIBase that extends UIBase, and introduced that code
> >> >
> >> >3.- Refactor Jewel components to use JewelUIBase
> >> >
> >> >In this way Basic, and other sets will remain untouched and not
> >>affected
> >> >by
> >> >this change
> >> >
> >> >Let me know what do you think about it.
> >> >
> >> >Thanks
> >> >
> >> >
> >> >2018-04-10 9:11 GMT+02:00 Harbs :
> >> >
> >> >> The article you linked to was a very old article. I already
> >>responded to
> >> >> that. I would need some tests to prove that it’s still true today.
> >>The
> >> >> tests that I saw seemed to indicate that it wasn’t.
> >> >>
> >> >> Philosophically, I think you are tying the behavior of UIBase too
> >> >>closely
> >> >> with the thinking behind Jewel which relies very heavily on class
> >>names
> >> >>and
> >> >> requires that users do not change that. I don’t think that’s going
> >>to be
> >> >> true for every component set.
> >> >>
> >> >> I completely agree with Alex’s response.
> >> >>
> >> >> My $0.02,
> >> >> Harbs
> >> >>
> >> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira
> >>
> >> >> wrote:
> >> >> >
> >> >> > Harbs,
> >> >> >
> >> >> > I though I did it. I give links to peformance links that for me
> >>proved
> >> >> that
> >> >> > people is going through classList.
> >> >>
> >> >>
> >> >
> >> >
> >> >--
> >> >Carlos Rovira
> >> >https://na01.safelinks.protection.outlook.com/?url=
> >> http%3A%2F%2Fabout.me%2
> >> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> >> 7Cdaafba5ff16a4a20856508d5
> >> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> >> 7C636589539427581762
> >> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D=0
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7C94ea37bd6a1546511d8208d5
> >9efb78b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636589725255561689
> >data=rjHuwyQi0bB9d%2Fg3dfZwUnKO6Pcgdv9WDkDduUxoBi8%3D=0
>
>


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

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Hi Carlos,

I'm not sure if it is better for Jewel to extend from UIBase or not.  I
just want to understand the technical reasons why you decided not to
extend UIBase.  We want to make sure UIBase works for as many people as
possible, but on the other hand, I wouldn't mind proving that the
framework doesn't require org.apache.royale.core.UIBase.  Hopefully the
framework uses IUIBase instead.  It should be ok for someone to come up
with a completely different base class as long as it conforms to IUIBase
and other interfaces.

Thanks,
-Alex

On 4/10/18, 8:54 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
 wrote:

>Hi Alex,
>
>the plan was to reuse as much as I can basic functionality. You think is
>better to extend directly from UIBase? (In this case JewelUIBase)
>If you think is better, then I'll go that path and we can UIBase
>untouched.
>
>thanks
>
>2018-04-10 17:15 GMT+02:00 Alex Harui :
>
>> Why are Jewel components not extending UIBase?
>>
>> On 4/10/18, 3:45 AM, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>>  wrote:
>>
>> >Hi
>> >
>> >I think we can take another approach. Since I'm finding that half of
>>Jewel
>> >components are not extending basic components for one reason or
>>another,
>> >maybe a good option would be:
>> >
>> >1.- Left UIBase untouched
>> >
>> >2.- Make JewelUIBase that extends UIBase, and introduced that code
>> >
>> >3.- Refactor Jewel components to use JewelUIBase
>> >
>> >In this way Basic, and other sets will remain untouched and not
>>affected
>> >by
>> >this change
>> >
>> >Let me know what do you think about it.
>> >
>> >Thanks
>> >
>> >
>> >2018-04-10 9:11 GMT+02:00 Harbs :
>> >
>> >> The article you linked to was a very old article. I already
>>responded to
>> >> that. I would need some tests to prove that it’s still true today.
>>The
>> >> tests that I saw seemed to indicate that it wasn’t.
>> >>
>> >> Philosophically, I think you are tying the behavior of UIBase too
>> >>closely
>> >> with the thinking behind Jewel which relies very heavily on class
>>names
>> >>and
>> >> requires that users do not change that. I don’t think that’s going
>>to be
>> >> true for every component set.
>> >>
>> >> I completely agree with Alex’s response.
>> >>
>> >> My $0.02,
>> >> Harbs
>> >>
>> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira
>>
>> >> wrote:
>> >> >
>> >> > Harbs,
>> >> >
>> >> > I though I did it. I give links to peformance links that for me
>>proved
>> >> that
>> >> > people is going through classList.
>> >>
>> >>
>> >
>> >
>> >--
>> >Carlos Rovira
>> >https://na01.safelinks.protection.outlook.com/?url=
>> http%3A%2F%2Fabout.me%2
>> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
>> 7Cdaafba5ff16a4a20856508d5
>> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
>> 7C636589539427581762
>> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D=0
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7C94ea37bd6a1546511d8208d5
>9efb78b1%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589725255561689
>data=rjHuwyQi0bB9d%2Fg3dfZwUnKO6Pcgdv9WDkDduUxoBi8%3D=0

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi Alex,

the plan was to reuse as much as I can basic functionality. You think is
better to extend directly from UIBase? (In this case JewelUIBase)
If you think is better, then I'll go that path and we can UIBase untouched.

thanks

2018-04-10 17:15 GMT+02:00 Alex Harui :

> Why are Jewel components not extending UIBase?
>
> On 4/10/18, 3:45 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
>  wrote:
>
> >Hi
> >
> >I think we can take another approach. Since I'm finding that half of Jewel
> >components are not extending basic components for one reason or another,
> >maybe a good option would be:
> >
> >1.- Left UIBase untouched
> >
> >2.- Make JewelUIBase that extends UIBase, and introduced that code
> >
> >3.- Refactor Jewel components to use JewelUIBase
> >
> >In this way Basic, and other sets will remain untouched and not affected
> >by
> >this change
> >
> >Let me know what do you think about it.
> >
> >Thanks
> >
> >
> >2018-04-10 9:11 GMT+02:00 Harbs :
> >
> >> The article you linked to was a very old article. I already responded to
> >> that. I would need some tests to prove that it’s still true today. The
> >> tests that I saw seemed to indicate that it wasn’t.
> >>
> >> Philosophically, I think you are tying the behavior of UIBase too
> >>closely
> >> with the thinking behind Jewel which relies very heavily on class names
> >>and
> >> requires that users do not change that. I don’t think that’s going to be
> >> true for every component set.
> >>
> >> I completely agree with Alex’s response.
> >>
> >> My $0.02,
> >> Harbs
> >>
> >> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira 
> >> wrote:
> >> >
> >> > Harbs,
> >> >
> >> > I though I did it. I give links to peformance links that for me proved
> >> that
> >> > people is going through classList.
> >>
> >>
> >
> >
> >--
> >Carlos Rovira
> >https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2
> >Fcarlosrovira=02%7C01%7Caharui%40adobe.com%
> 7Cdaafba5ff16a4a20856508d5
> >9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%
> 7C636589539427581762
> >data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D=0
>
>


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

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Alex Harui]

Why are Jewel components not extending UIBase?

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

>Hi
>
>I think we can take another approach. Since I'm finding that half of Jewel
>components are not extending basic components for one reason or another,
>maybe a good option would be:
>
>1.- Left UIBase untouched
>
>2.- Make JewelUIBase that extends UIBase, and introduced that code
>
>3.- Refactor Jewel components to use JewelUIBase
>
>In this way Basic, and other sets will remain untouched and not affected
>by
>this change
>
>Let me know what do you think about it.
>
>Thanks
>
>
>2018-04-10 9:11 GMT+02:00 Harbs :
>
>> The article you linked to was a very old article. I already responded to
>> that. I would need some tests to prove that it’s still true today. The
>> tests that I saw seemed to indicate that it wasn’t.
>>
>> Philosophically, I think you are tying the behavior of UIBase too
>>closely
>> with the thinking behind Jewel which relies very heavily on class names
>>and
>> requires that users do not change that. I don’t think that’s going to be
>> true for every component set.
>>
>> I completely agree with Alex’s response.
>>
>> My $0.02,
>> Harbs
>>
>> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira 
>> wrote:
>> >
>> > Harbs,
>> >
>> > I though I did it. I give links to peformance links that for me proved
>> that
>> > people is going through classList.
>>
>>
>
>
>-- 
>Carlos Rovira
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2
>Fcarlosrovira=02%7C01%7Caharui%40adobe.com%7Cdaafba5ff16a4a20856508d5
>9ed02fcc%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636589539427581762
>data=Y9fXcrA51Ox3ztRIM4s0Z%2BH3vSUkagbqXpU1W6slul0%3D=0

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi

I think we can take another approach. Since I'm finding that half of Jewel
components are not extending basic components for one reason or another,
maybe a good option would be:

1.- Left UIBase untouched

2.- Make JewelUIBase that extends UIBase, and introduced that code

3.- Refactor Jewel components to use JewelUIBase

In this way Basic, and other sets will remain untouched and not affected by
this change

Let me know what do you think about it.

Thanks


2018-04-10 9:11 GMT+02:00 Harbs :

> The article you linked to was a very old article. I already responded to
> that. I would need some tests to prove that it’s still true today. The
> tests that I saw seemed to indicate that it wasn’t.
>
> Philosophically, I think you are tying the behavior of UIBase too closely
> with the thinking behind Jewel which relies very heavily on class names and
> requires that users do not change that. I don’t think that’s going to be
> true for every component set.
>
> I completely agree with Alex’s response.
>
> My $0.02,
> Harbs
>
> > On Apr 10, 2018, at 12:50 AM, Carlos Rovira 
> wrote:
> >
> > Harbs,
> >
> > I though I did it. I give links to peformance links that for me proved
> that
> > people is going through classList.
>
>


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

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Harbs]

The article you linked to was a very old article. I already responded to that. 
I would need some tests to prove that it’s still true today. The tests that I 
saw seemed to indicate that it wasn’t.

Philosophically, I think you are tying the behavior of UIBase too closely with 
the thinking behind Jewel which relies very heavily on class names and requires 
that users do not change that. I don’t think that’s going to be true for every 
component set.

I completely agree with Alex’s response.

My $0.02,
Harbs

> On Apr 10, 2018, at 12:50 AM, Carlos Rovira  wrote:
> 
> Harbs,
> 
> I though I did it. I give links to peformance links that for me proved that
> people is going through classList.

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Harbs]

This is a huge functional change. I don’t know that I really agree with this.

You really haven’t answered my comments about the performance implications. I 
previously linked to jsperf tests. According to recent tests, addStyle seems to 
perform much more poorly that changing the className.

> On Apr 9, 2018, at 9:49 PM, Carlos Rovira  wrote:
> 
> Hi,
> 
> this branch has the UIBase modifications that I made in Jewel. I think is
> time to complete the change so:
> 
> @Alex: Can you take a look at the diff and see if you are ok with it? I
> think I do this with the considerations we discussed some weeks ago, but I
> think you never saw if that was finaly what you suggested.
> 
> @Piotr: I think MDL is the project that needs to see how this changes
> affect it. Since you're the one who are maintaining it, can you check it
> and make the modifications in this branch needed? As we have no more
> MDLExamples it would be a problem for me to bring that code and see it.
> 
> I see some other examples (like the other day fixing databinding flat) and
> seems to work ok since the rest are mainly royale components,
> 
> I'd like to make this for 0.9.3 if possible to make Jewel as stable as
> possible
> 
> Thanks
> 
> Carlos
> 
> 
> 2018-04-09 20:41 GMT+02:00 :
> 
>> This is an automated email from the ASF dual-hosted git repository.
>> 
>> carlosrovira pushed a commit to branch feature/uibase-classname
>> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>> 
>> commit cf06ede63e3e794198fd68e8647e9c6eceae383d
>> Author: Carlos Rovira 
>> AuthorDate: Mon Apr 9 20:41:48 2018 +0200
>> 
>>UIBase className changes to support new cssclassList class methods
>> like addStyles
>> ---
>> .../main/royale/org/apache/royale/core/UIBase.as   |   18 +-
>> .../main/royale/org/apache/royale/core/UIBase.as   | 1628
>> 
>> 2 files changed, 9 insertions(+), 1637 deletions(-)
>> 
>> diff --git 
>> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
>> b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> index b5f4dd1..f59d7f0 100644
>> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> @@ -37,6 +37,7 @@ package org.apache.royale.core
>> {
>> import org.apache.royale.html.util.addElementToWrapper;
>> import org.apache.royale.utils.CSSUtils;
>> +import org.apache.royale.utils.cssclasslist.addStyles;
>> }
>> 
>>/**
>> @@ -1085,11 +1086,13 @@ package org.apache.royale.core
>> {
>> if (_className !== value)
>> {
>> +_className = value;
>> +
>> COMPILE::JS
>> {
>> -setClassName(typeNames ? StringUtil.trim(value + ' '
>> + typeNames) : value);
>> +setClassName(computeFinalClassNames());
>> }
>> -_className = value;
>> +
>> dispatchEvent(new Event("classNameChanged"));
>> }
>> }
>> @@ -1097,13 +1100,13 @@ package org.apache.royale.core
>>COMPILE::JS
>> protected function computeFinalClassNames():String
>>{
>> -return (_className ? _className + " " : "") + (typeNames ?
>> typeNames : "");
>> +return  StringUtil.trim((_className ? _className : "") + " "
>> + (typeNames ? typeNames : ""));
>>}
>> 
>> COMPILE::JS
>> protected function setClassName(value:String):void
>> {
>> -element.className = value;
>> +addStyles(element, value);
>> }
>> 
>> /**
>> @@ -1394,11 +1397,8 @@ package org.apache.royale.core
>> 
>> COMPILE::JS
>> {
>> -   if (typeNames)
>> -{
>> -setClassName(computeFinalClassNames());
>> -}
>> -
>> +   setClassName(computeFinalClassNames());
>> +
>> if (style)
>> ValuesManager.valuesImpl.applyStyles(this, style);
>> }
>> diff --git 
>> a/frameworks/projects/Jewel/src/main/royale/org/apache/royale/core/UIBase.as
>> b/frameworks/projects/Jewel/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> deleted file mode 100644
>> index f59d7f0..000
>> --- a/frameworks/projects/Jewel/src/main/royale/org/apache/
>> royale/core/UIBase.as
>> +++ /dev/null
>> @@ -1,1628 +0,0 @@
>> -///
>> /
>> -//
>> -//  Licensed to the Apache Software Foundation (ASF) under one or more
>> -//  contributor license agreements.  See the NOTICE file distributed with
>> -//  this work for additional information regarding copyright ownership.
>> -//  The ASF 

Re: [royale-asjs] 01/01: UIBase className changes to support new cssclassList class methods like addStyles

[Carlos Rovira]

Hi,

this branch has the UIBase modifications that I made in Jewel. I think is
time to complete the change so:

@Alex: Can you take a look at the diff and see if you are ok with it? I
think I do this with the considerations we discussed some weeks ago, but I
think you never saw if that was finaly what you suggested.

@Piotr: I think MDL is the project that needs to see how this changes
affect it. Since you're the one who are maintaining it, can you check it
and make the modifications in this branch needed? As we have no more
MDLExamples it would be a problem for me to bring that code and see it.

I see some other examples (like the other day fixing databinding flat) and
seems to work ok since the rest are mainly royale components,

I'd like to make this for 0.9.3 if possible to make Jewel as stable as
possible

Thanks

Carlos


2018-04-09 20:41 GMT+02:00 :

> This is an automated email from the ASF dual-hosted git repository.
>
> carlosrovira pushed a commit to branch feature/uibase-classname
> in repository https://gitbox.apache.org/repos/asf/royale-asjs.git
>
> commit cf06ede63e3e794198fd68e8647e9c6eceae383d
> Author: Carlos Rovira 
> AuthorDate: Mon Apr 9 20:41:48 2018 +0200
>
> UIBase className changes to support new cssclassList class methods
> like addStyles
> ---
>  .../main/royale/org/apache/royale/core/UIBase.as   |   18 +-
>  .../main/royale/org/apache/royale/core/UIBase.as   | 1628
> 
>  2 files changed, 9 insertions(+), 1637 deletions(-)
>
> diff --git 
> a/frameworks/projects/Basic/src/main/royale/org/apache/royale/core/UIBase.as
> b/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> index b5f4dd1..f59d7f0 100644
> --- a/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> +++ b/frameworks/projects/Basic/src/main/royale/org/apache/
> royale/core/UIBase.as
> @@ -37,6 +37,7 @@ package org.apache.royale.core
>  {
>  import org.apache.royale.html.util.addElementToWrapper;
>  import org.apache.royale.utils.CSSUtils;
> +import org.apache.royale.utils.cssclasslist.addStyles;
>  }
>
> /**
> @@ -1085,11 +1086,13 @@ package org.apache.royale.core
>  {
>  if (_className !== value)
>  {
> +_className = value;
> +
>  COMPILE::JS
>  {
> -setClassName(typeNames ? StringUtil.trim(value + ' '
> + typeNames) : value);
> +setClassName(computeFinalClassNames());
>  }
> -_className = value;
> +
>  dispatchEvent(new Event("classNameChanged"));
>  }
>  }
> @@ -1097,13 +1100,13 @@ package org.apache.royale.core
> COMPILE::JS
>  protected function computeFinalClassNames():String
> {
> -return (_className ? _className + " " : "") + (typeNames ?
> typeNames : "");
> +return  StringUtil.trim((_className ? _className : "") + " "
> + (typeNames ? typeNames : ""));
> }
>
>  COMPILE::JS
>  protected function setClassName(value:String):void
>  {
> -element.className = value;
> +addStyles(element, value);
>  }
>
>  /**
> @@ -1394,11 +1397,8 @@ package org.apache.royale.core
>
>  COMPILE::JS
>  {
> -   if (typeNames)
> -{
> -setClassName(computeFinalClassNames());
> -}
> -
> +   setClassName(computeFinalClassNames());
> +
>  if (style)
>  ValuesManager.valuesImpl.applyStyles(this, style);
>  }
> diff --git 
> a/frameworks/projects/Jewel/src/main/royale/org/apache/royale/core/UIBase.as
> b/frameworks/projects/Jewel/src/main/royale/org/apache/
> royale/core/UIBase.as
> deleted file mode 100644
> index f59d7f0..000
> --- a/frameworks/projects/Jewel/src/main/royale/org/apache/
> royale/core/UIBase.as
> +++ /dev/null
> @@ -1,1628 +0,0 @@
> -///
> /
> -//
> -//  Licensed to the Apache Software Foundation (ASF) under one or more
> -//  contributor license agreements.  See the NOTICE file distributed with
> -//  this work for additional information regarding copyright ownership.
> -//  The ASF licenses this file to You under the Apache License, Version
> 2.0
> -//  (the "License"); you may not use this file except in compliance with
> -//  the License.  You may obtain a copy of the License at
> -//
> -//  http://www.apache.org/licenses/LICENSE-2.0
> -//
> -//  Unless required by applicable law or agreed to in writing, software
> -//  distributed under the License is distributed on an "AS IS" BASIS,
> -//  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> implied.
> -//