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

Thanks,
-Alex

On 3/13/18, 9:50 AM, "Alex Harui" <aha...@adobe.com.INVALID> wrote:

>Hi Carlos,
>
>I do not think you are considering all of the scenarios in your proposed
>code.  I'm sad that I have to delineate them again, but I will try.
>
>1) In Basic there are two sets of strings:  The fixed set from typeNames
>that should "never" change.  And the className set from the user that can
>not only add, but also remove a set of HTML classes.
>
>2) In MDL and I guess Jewel, there is a third set.  They are tied to
>properties like you said.  "fab" and "primary", and things like that.
>
>3) For PAYG reasons, it would be great if Basic did not have to
>contemplate the third set.
>
>4) For PAYG reasons, it would be nice if Basic did not have to assume
>conversion to array and call split().  The current code in the develop
>branch lets the browser do the split() in native code.
>
>Then, as a performance consideration, Harbs claims that changing classList
>is expensive.
>
>So, your proposed solution MUST allow the user to delete/remove any
>strings they added without removing strings added from typeNames or from
>the "fab"/"primary" properties.  And allow add/remove of the user's
>strings before or after changing properties like "fab" and "primary".
>
>Show us how that will work.  I'm pretty sure it is possible.  Then we will
>debate the performance aspects.
>
>Thanks,
>-Alex
>
>On 3/13/18, 6:49 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
><carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>
>>So, you if is == you expect that setting className in royale you remove
>>all
>>inclusive typeNames?
>>Harbs, className is not equal to class in HTML
>>
>>2018-03-13 14:08 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>>
>>> className in Royale == class in HTML.
>>>
>>> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira <carlosrov...@apache.org>
>>> wrote:
>>> >
>>> > I think we're getting to the point in this discussion.
>>> >
>>> > For me as a user, I expect to use className property to "add", and
>>>not
>>> > override all I have
>>> > for that reason in MDL and now in Royale we decided to create
>>>properties
>>> > (that use to be boolean) like "primary" or in MDL "fab" to add or
>>>remove
>>> > those properties (since are library properties that are managed
>>> > specifically).
>>> > I don't want to set primary and then className removes that! I think
>>>that
>>> > function is not right and will be the cause of many problems.
>>> >
>>> > If the user wants to remove all class names, he can do with a method
>>>that
>>> > callls element.classList.remove, but the behavior by default
>>>shouldn't be
>>> > to use className to get rid of all what we have.
>>> >
>>> > If you work with html directly , is normal to write class="class1
>>>class2
>>> > ..." and create from scratch
>>> >
>>> > in Royale you write mxml and as3 and use className to add additional
>>> > classes that are not in the api but not to remove the ones the
>>>component
>>> > set plus the ones the user "switched" on/off due to properties
>>> >
>>> >
>>> >
>>> > 2018-03-13 13:42 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>>> >
>>> >> No. className is supposed to *replace* the entire classList minus
>>>the
>>> >> internally managed ones (i.e. typeNames). Your code drastically
>>>changes
>>> the
>>> >> current behavior.
>>> >>
>>> >> You cannot use add for that and replacing the classList will destroy
>>> your
>>> >> custom class names.
>>> >>
>>> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira
>>><carlosrov...@apache.org>
>>> >> wrote:
>>> >>>
>>> >>> Solving the multiple string value problem:
>>> >>>
>>> >>> This: <j:TextButton text="PRIMARY" className="myCustomStyle some
>>>other"
>>> >>> primary="true"/>
>>> >>>
>>> >>> *<button type="button" class="jewel button textbutton myCustomStyle
>>> some
>>> >>> other primary" style="margin: 10px 0px 0px; display:
>>> >>> block;">PRIMARY</button>*
>>> >>>
>>> >>> with this change
>>> >>>
>>> >>> COMPILE::JS
>>> >>> protected function setClassName(value:String):void
>>> >>> {
>>> >>> var classes:Array = value.split(" ");
>>> >>> element.classList.add.apply(element.classList, classes);
>>> >>> }
>>> >>>
>>> >>> I think this was all the problems we have right?
>>> >>>
>>> >>>
>>> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira <carlosrov...@apache.org>:
>>> >>>
>>> >>>> Hi Piotr,
>>> >>>>
>>> >>>> that's one of the advantages of a collection, order doesn't
>>>matter! :)
>>> >>>>
>>> >>>> <j:TextButton text="PRIMARY" className="myCustomStyle"
>>> primary="true"/>
>>> >>>>
>>> >>>> output:
>>> >>>>
>>> >>>> *<button type="button" class="jewel button textbutton
>>>myCustomStyle
>>> >>>> primary" style="margin: 10px 0px 0px; display:
>>> block;">PRIMARY</button>*
>>> >>>>
>>> >>>> this is one of the reason to change, since you'll end trying to
>>>figure
>>> >>>> what comes in first or not.
>>> >>>>
>>> >>>> Do you need more evidence?
>>> >>>>
>>> >>>> Thanks
>>> >>>>
>>> >>>>
>>> >>>> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki
>>><piotrzarzyck...@gmail.com
>>> >:
>>> >>>>
>>> >>>>> In my example orders matters. Setup first className than your
>>> property.
>>> >>>>>
>>> >>>>>
>>> >>>>> On Tue, Mar 13, 2018, 12:39 Harbs <harbs.li...@gmail.com> wrote:
>>> >>>>>
>>> >>>>>> Hi Carlos,
>>> >>>>>>
>>> >>>>>> I definitely appreciate the work you are doing. I’m swamped with
>>> work
>>> >>>>>> right now, so I don’t have the time to spend helping you. (Sorry
>>> about
>>> >>>>>> that.) :-(
>>> >>>>>>
>>> >>>>>> I think the discussions here are about pretty minor points. You
>>>can
>>> >>>>>> certainly implement jewel how you think makes sense, but if you
>>>want
>>> >> to
>>> >>>>>> make changes to basic in areas which are not broken, there needs
>>>to
>>> >> be a
>>> >>>>>> really good reason to do so.
>>> >>>>>>
>>> >>>>>> My $0.02,
>>> >>>>>> Harbs
>>> >>>>>>> On Mar 13, 2018, at 1:31 PM, Carlos Rovira <
>>> carlosrov...@apache.org>
>>> >>>>>> wrote:
>>> >>>>>>>
>>> >>>>>>> Hi Piotr,
>>> >>>>>>>
>>> >>>>>>> thanks for your words, but is difficult to work on something
>>>when
>>> you
>>> >>>>>>> believe in your vision and others no, and more over when all
>>>the
>>> >> facts
>>> >>>>>> you
>>> >>>>>>> see corroborates that vision. It's difficult to maintain live
>>>the
>>> >>>>> moto in
>>> >>>>>>> that scenario.
>>> >>>>>>>
>>> >>>>>>> but anyway for you Kindly words
>>> >>>>>>>
>>> >>>>>>> Carlos
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki <
>>> piotrzarzyck...@gmail.com
>>> >>>>>> :
>>> >>>>>>>
>>> >>>>>>>> Carlos,
>>> >>>>>>>>
>>> >>>>>>>> In my opinion you are not facing the wall from US. You are
>>>facing
>>> >> the
>>> >>>>>> wall
>>> >>>>>>>> from lack of volounteers who can help, do the job.
>>> >>>>>>>> Believe me your Jewel effort in my list of tasks is almost on
>>>the
>>> >>>>> Top. I
>>> >>>>>>>> have to fiinish planned work in TranspiledActionScript first
>>>and I
>>> >>>>> hope
>>> >>>>>> to
>>> >>>>>>>> join.
>>> >>>>>>>>
>>> >>>>>>>> When it will be - maybe in couple of weeks. In the end
>>>something
>>> >>>>> have to
>>> >>>>>>>> pay the bills and Royale is only fraction of that.
>>> >>>>>>>>
>>> >>>>>>>> I contribute in other related areas. I Wish I could contribute
>>>in
>>> >>>>> your
>>> >>>>>> way
>>> >>>>>>>> or Alex and Peter.
>>> >>>>>>>>
>>> >>>>>>>> Thanks for your work!
>>> >>>>>>>> Piotr
>>> >>>>>>>>
>>> >>>>>>>> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki <
>>> >>>>> piotrzarzyck...@gmail.com>
>>> >>>>>>>> wrote:
>>> >>>>>>>>
>>> >>>>>>>>> I personally said - Go and try, report back. I have gave you
>>>an
>>> >> real
>>> >>>>>>>> world
>>> >>>>>>>>> examples where classList failed. Try and post the results.
>>> >>>>>>>>>
>>> >>>>>>>>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira <
>>> carlosrov...@apache.org
>>> >>> :
>>> >>>>>>>>>
>>> >>>>>>>>>> Hi,
>>> >>>>>>>>>>
>>> >>>>>>>>>> it's very hard to me to invest lot of time both in tryin to
>>> >> develop
>>> >>>>>>>>>> something useful in the look and feel field for us where no
>>> other
>>> >>>>> is
>>> >>>>>>>> doing
>>> >>>>>>>>>> work, trying to explain and discuss all issues I find
>>>without
>>> get
>>> >>>>> any
>>> >>>>>>>>>> traction. It's like to face a wall all the time.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Maybe I'm wrong with my proposals but other times my
>>>perception
>>> is
>>> >>>>>> that
>>> >>>>>>>>>> things are settled in a particular way
>>> >>>>>>>>>> and we don't want to change it since is working in the
>>>current
>>> >>>>> state.
>>> >>>>>>>> But
>>> >>>>>>>>>> I
>>> >>>>>>>>>> think we always where thinking of change things as we evolve
>>> >>>>> Royale.
>>> >>>>>>>> We're
>>> >>>>>>>>>> in a 0.9.2 release, we're not in 1.0, but the way we're
>>>managing
>>> >>>>> all
>>> >>>>>>>>>> issues
>>> >>>>>>>>>> seems to
>>> >>>>>>>>>> me that we're fine with what we have now and we are freezing
>>>the
>>> >>>>> API.
>>> >>>>>>>>>>
>>> >>>>>>>>>> In all the issues raised last days only CSS compiler errors
>>>are
>>> >>>>> real
>>> >>>>>>>> bugs,
>>> >>>>>>>>>> since without that fixes royale can't output concrete CSS
>>>rules
>>> (I
>>> >>>>>> think
>>> >>>>>>>>>> those not require any discussion)
>>> >>>>>>>>>>
>>> >>>>>>>>>> The font injection is maybe another bug (don't know why a
>>>class
>>> in
>>> >>>>> a
>>> >>>>>>>> theme
>>> >>>>>>>>>> is not "visible" by the final app), but can be workarounded
>>>with
>>> >> an
>>> >>>>>> html
>>> >>>>>>>>>> that setup the font for now.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Things like classNames discussion are not critical (I know),
>>> it's
>>> >>>>>> just a
>>> >>>>>>>>>> matter to refine the API since I had problems each time I go
>>> that
>>> >>>>>> path,
>>> >>>>>>>>>> first with MDL and now with Jewel. Maybe I'm the only one
>>>since
>>> no
>>> >>>>>> other
>>> >>>>>>>>>> has tried what I'm trying to do: Creating Themes.
>>> >>>>>>>>>>
>>> >>>>>>>>>> In my opinion, give the users only a way to manage
>>>classNames
>>> vía
>>> >>>>>>>> string,
>>> >>>>>>>>>> is insufficient and cumbersome and deserves at a minimun
>>>some
>>> API
>>> >>>>>>>> methods
>>> >>>>>>>>>> since is an important point in how UI is stylized, and how
>>> >> controls
>>> >>>>>> and
>>> >>>>>>>>>> objects in html can be "extended" or diferenciated (Alex
>>> explained
>>> >>>>>> very
>>> >>>>>>>>>> well the importance of this in the typenames thread). So
>>>some
>>> API
>>> >>>>> to
>>> >>>>>>>> ease
>>> >>>>>>>>>> that is for me very Wellcome since I'm doing that work, and
>>>will
>>> >> be
>>> >>>>>> more
>>> >>>>>>>>>> users doing that work. In this point, I don't think we
>>>should
>>> >>>>> shield
>>> >>>>>> us
>>> >>>>>>>> in
>>> >>>>>>>>>> things like PAYG or if that is a bit less performant.
>>> >>>>>>>>>>
>>> >>>>>>>>>> To close and avoid having much discussion to not reach to
>>>some
>>> >>>>>> valuable
>>> >>>>>>>>>> point:  I can try to go with what we have, but makes me feel
>>>not
>>> >> so
>>> >>>>>> good
>>> >>>>>>>>>> about the continuous rejection of my proposals. As well, you
>>>are
>>> >>>>>> saying
>>> >>>>>>>>>> that we should wait to what users demand...but I'm an user
>>>of
>>> the
>>> >>>>> API,
>>> >>>>>>>> and
>>> >>>>>>>>>> my perception as a "zero user" seems to be not valuable.
>>>Since I
>>> >>>>> don't
>>> >>>>>>>> get
>>> >>>>>>>>>> traction on this, I'll try to continue with what we have and
>>> >> report
>>> >>>>>> back
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> 2018-03-13 9:24 GMT+01:00 Harbs <harbs.li...@gmail.com>:
>>> >>>>>>>>>>
>>> >>>>>>>>>>> +1.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>> On Mar 13, 2018, at 10:08 AM, Alex Harui
>>> >>>>> <aha...@adobe.com.INVALID>
>>> >>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> I am so sad and frustrated that we have spent so much time
>>>on
>>> >>>>>>>>>> managing a
>>> >>>>>>>>>>>> set of strings.  I just don't think we have the people
>>>power
>>> to
>>> >>>>>>>>>> continue
>>> >>>>>>>>>>>> to seek perfection until it is truly needed by a user.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>>
>>> >>>>>>>>>> --
>>> >>>>>>>>>> Carlos Rovira
>>> >>>>>>>>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%
>>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a9095473c2bcc0
>>>8
>>>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365654581756587
>>>3
>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
>>> >>>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>>
>>> >>>>>>>>> --
>>> >>>>>>>>>
>>> >>>>>>>>> Piotr Zarzycki
>>> >>>>>>>>>
>>> >>>>>>>>> Patreon:
>>>*https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa
>>>t
>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a909
>>>5
>>>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636565
>>>4
>>>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7%2BiDRjzQWyG9GPG1rs2Bw%3D&res
>>>e
>>>rved=0
>>> >>>>>>>>> 
>>><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.pa
>>>t
>>>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a909
>>>5
>>>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636565
>>>4
>>>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7%2BiDRjzQWyG9GPG1rs2Bw%3D&res
>>>e
>>>rved=0>*
>>> >>>>>>>>>
>>> >>>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>>
>>> >>>>>>> --
>>> >>>>>>> Carlos Rovira
>>> >>>>>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%
>>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a9095473c2bcc0
>>>8
>>>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365654581756587
>>>3
>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
>>> >>>>>>
>>> >>>>>>
>>> >>>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> --
>>> >>>> Carlos Rovira
>>> >>>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%
>>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a9095473c2bcc0
>>>8
>>>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365654581756587
>>>3
>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
>>> >>>>
>>> >>>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Carlos Rovira
>>> >>> 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%
>>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a9095473c2bcc0
>>>8
>>>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365654581756587
>>>3
>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Carlos Rovira
>>> > 
>>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me
>>>%
>>>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a9095473c2bcc0
>>>8
>>>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6365654581756587
>>>3
>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
>>>
>>>
>>
>>
>>-- 
>>Carlos Rovira
>>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%
>>2
>>Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce137bd7a9095473c2bcc08d
>>5
>>88e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636565458175658737&
>>s
>>data=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0
>

Reply via email to