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 <aha...@adobe.com.invalid>: > 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" > <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote: > > >Hi Alex, > > > >2018-04-10 21:17 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > > > >> 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 Button....we 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" > >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> 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 > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C8f1320421992439bea2708d5 > >9f2cf45e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636589937783626510&s > >data=RXcZ%2B5%2FKm1Qoi45eL%2F98yDZAiEuRRnEd841%2B7N9cRek%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira
