2018-03-13 18:03 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:

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

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

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

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

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

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

thanks


>
> Thanks,
> -Alex
>
> On 3/13/18, 9:50 AM, "Alex Harui" <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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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
> >
>
>


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

Reply via email to