Re: Experiment with UIBase change to classList

Hi Alex, 2018-03-14 18:42 GMT+01:00 Alex Harui : > Sounds like we are mostly in agreement. I've clipped everything we've > agreed to out of the reply below. > > On 3/14/18, 9:41 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" >

Re: Experiment with UIBase change to classList

Sounds like we are mostly in agreement. I've clipped everything we've agreed to out of the reply below. On 3/14/18, 9:41 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira" wrote: > > >> C) In MDL and Jewel,

Re: Experiment with UIBase change to classList

Hi Carlos, I think you still are not understanding the concerns being raised. I think the two most important right now are: 1) I do not wish to force any of our users (application developers) to use classList instead of className. ClassName is much easier to use in MXML and there are probably

Re: Experiment with UIBase change to classList

Hi Piotr, no. that's what Alex ask me, not what I propose...¿? I said the simple solution in my email (1 line), please re-read after one day of giving you lots of evidence you don't respond me...but in this case, you read the inverse and respond. Piotr, at this point I see clear that you like

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

Hi Alex, to recete the classList you can do className = "" and reenter typeNames and classNames I think is the only way, then you can continue doing add/remove/toggle though classList. In your example you're still thinking in className mode, you can do easily with classList.remove('Piotr'')

Re: Experiment with UIBase change to classList

Hi Alex, 2018-03-13 19:20 GMT+01:00 Alex Harui : > Hi Carlos, > > I took a quick look. > > 1) I don't see how if the user did: > > myComp.className = "Carlos"; > myComp.className = ""; > > Right this case is missing, we need to add it, but seems simple since is deal

Re: Experiment with UIBase change to classList

Hi Carlos, I took a quick look. 1) I don't see how if the user did: myComp.className = "Carlos"; myComp.className = ""; That 'Carlos' would be removed from the classList. 2) I still don't like that we are calling split and apply on classList even for simple assignment of a single className

Re: Experiment with UIBase change to classList

Hi Alex, right, I tested it in JewelExample. If you find something that does not conform to what you thinked please let me know to address it. I think it should not be very difficult to handle some isolated case with what we have thanks 2018-03-13 18:24 GMT+01:00 Alex Harui

Re: Experiment with UIBase change to classList

2018-03-13 18:03 GMT+01:00 Alex Harui : > After I sent this, I saw one of your code changes that changed typeNames > to a getter/setter. Please consider that right now "typeNames" is > aggregated in the constructor so that subclasses do not need to override >

Re: Experiment with UIBase change to classList

Hi Carlos, Just so I'm clear, you believe that UIBase.as in the jewel-ui-set branch addresses all of these issues? I've just been watching commits, so if you think that's the case then I will look at the current state of your UIBase. Thanks, -Alex On 3/13/18, 10:14 AM, "carlos.rov...@gmail.com

Re: Experiment with UIBase change to classList

Hi Alex, 2018-03-13 17:50 GMT+01:00 Alex Harui : > Hi Carlos, > > I do not think you are considering all of the scenarios in your proposed > code. I'm sad that I have to delineate them again, but I will try. > > 1) In Basic there are two sets of strings: The fixed set

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

So, you if is == you expect that setting className in royale you remove all inclusive typeNames? Harbs, className is not equal to class in HTML 2018-03-13 14:08 GMT+01:00 Harbs : > className in Royale == class in HTML. > > > On Mar 13, 2018, at 2:55 PM, Carlos Rovira

Re: Experiment with UIBase change to classList

className in Royale == class in HTML. > On Mar 13, 2018, at 2:55 PM, Carlos Rovira wrote: > > I think we're getting to the point in this discussion. > > For me as a user, I expect to use className property to "add", and not > override all I have > for that reason in

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

Hi Harbs 2018-03-13 13:34 GMT+01:00 Harbs : > > I don’t think you understood what Piotr was saying. > > The order of setting the *property* and *className* matters. He was not > talking about the order of class names in a class list. > > I think is what I did right? change

Re: Experiment with UIBase change to classList

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,

Re: Experiment with UIBase change to classList

Solving the multiple string value problem: This: *PRIMARY* with this change COMPILE::JS protected function setClassName(value:String):void { var classes:Array = value.split(" "); element.classList.add.apply(element.classList, classes); } I think this was all the problems we have right?

Re: Experiment with UIBase change to classList

Hi Piotr, that's one of the advantages of a collection, order doesn't matter! :) output: *PRIMARY* this is one of the reason to change, since you'll end trying to figure what comes in first or not. Do you need more evidence? Thanks 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki

Re: Experiment with UIBase change to classList

Hi Harbs 2018-03-13 12:54 GMT+01:00 Harbs : > > > On Mar 13, 2018, at 1:48 PM, Carlos Rovira > wrote: > > > > Cause I'm dealing with this since 2016 with MDL?, if this is not enough > > experience and time with an API, don't know what should I do

Re: Experiment with UIBase change to classList

Hi Harbs 2018-03-13 12:39 GMT+01:00 Harbs : > Hi Carlos, > > I definitely appreciate the work you are doing. I’m swamped with work > right now, so I don’t have the time to spend helping you. (Sorry about > that.) :-( > > Thanks Harbs, but don't worry, I think at this time

Re: Experiment with UIBase change to classList

> On Mar 13, 2018, at 1:48 PM, Carlos Rovira wrote: > > Cause I'm dealing with this since 2016 with MDL?, if this is not enough > experience and time with an API, don't know what should I do to reflect > that is the part of Royale where I always move and maybe have the

Re: Experiment with UIBase change to classList

In my example orders matters. Setup first className than your property. On Tue, Mar 13, 2018, 12:39 Harbs wrote: > Hi Carlos, > > I definitely appreciate the work you are doing. I’m swamped with work > right now, so I don’t have the time to spend helping you. (Sorry

Re: Experiment with UIBase change to classList

FYI, here’s one article which discusses collections: https://dev.opera.com/articles/efficient-javascript/ > On Mar 13, 2018, at 1:36 PM, Harbs wrote: > > I don’t know why you keep asserting this. > > The general

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

I don’t know why you keep asserting this. The general rule with live collections in general is to avoid them when possible. Collections need to be resolved which adds overhead. The less interactions with a DOM, the better. Native JS is almost always going to more efficient than browser/DOM

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

Hi Piotr, just tested without do any other change to the code posted yesterday and is working (what surprised me) gives: *PRIMARY* what is completely right what does not work is that is what Alex said, and can be easily resolved with a if-else that handles multiple classes in a string I

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

I personally said - Go and try, report back. I have gave you an real world examples where classList failed. Try and post the results. 2018-03-13 11:49 GMT+01:00 Carlos Rovira : > Hi, > > it's very hard to me to invest lot of time both in tryin to develop > something

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

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

Re: Experiment with UIBase change to classList

Hi Alex, ok, I saw the problems of using a list as I was creating it for that reason I try to do this as easy. to solve that we can introduce a few lines more that handles strings. This will be less code that current solution and handle both possibilities is done in more parts of the framework

Re: Experiment with UIBase change to classList

Hi Carlos, classList was not used earlier because Arrays are cumbersome in MXML. In MXML, folks can add more than one class using space delimited list of strings: In AS, folks can delete classnames via: myLabel.className="SmallFont"; I don't believe your proposal takes these scenarios into

Re: Experiment with UIBase change to classList

Carlos, I don't see in your examples things which I've asked you in the previous thread. Let me ask you once again. Please test with your code following example. 1) Create custom style. .myCustomStyle { fontSize: 12px; /// some style whatever } 2. Set in your example Compile and check