Re: TypeNames vs ClassName

2018-03-12 Thread Carlos Rovira
HI Alex, ok, I think I'll be subclassing in my branch and see where I get, in this way the Piotr and Harbs can continue with things as they expect to. In the other way, maybe it could seem that I'm worried to much about how html looks, and maybe things like the layouts can wait, but I think is

Re: TypeNames vs ClassName

2018-03-12 Thread Alex Harui
Hi Carlos, I think people are more uncomfortable with the proposal to use element.classList than any issue about order. It is hard for me to truly understand without seeing code so I think you should push it to your branch. I agree with Piotr that we can't make the users (app dev) use

Re: TypeNames vs ClassName

2018-03-12 Thread Carlos Rovira
Hi Alex, since Piotr and Harbs seems not to be very comfortable with the change, I can subclass UIBase for Jewel and make that changes there. I don't want to conflict in such central point of the framework, Will it be ok for all of us? 2018-03-12 18:56 GMT+01:00 Alex Harui

Re: TypeNames vs ClassName

2018-03-12 Thread Carlos Rovira
Hi Piotr. I think is what I just pointed in the response to a Harbs emails. I think once people set typenames and classnames, if we operate all through element.classList, that solves all conflicts, since all classes are in a managed list, if people wants to add or remove they can through the list.

Re: TypeNames vs ClassName

2018-03-12 Thread Carlos Rovira
Hi Piotr, I was reding from the begging and saw when the CSSClassList came. I think Harbs solution is ok, the only problem I see is that in MDL, and Jewel, we need to have functions per class that manages add/remove of classes and override of compute function. That's what I don't like of current

Re: TypeNames vs ClassName

2018-03-12 Thread Piotr Zarzycki
2018-03-12 17:14 GMT+01:00 Alex Harui : > If HTMLElement.classList is exposed to the user (the app developer) then > they can remove any of the items that were added from the typenames. > There is no way to enforce immutability of the typenames. We can choose > to give

Re: TypeNames vs ClassName

2018-03-12 Thread Alex Harui
Well, it isn't fair if someone writes to element.className, but we control what happens when someone writes to UIBase.className. I just want it to be as simple as possible and PAYG. -Alex On 3/12/18, 9:21 AM, "Harbs" wrote: >I’m pretty sure your solution will only work

Re: TypeNames vs ClassName

2018-03-12 Thread Harbs
I’m pretty sure your solution will only work if the user doesn’t set a className of their own. Setting className overwrites the entire classList. > On Mar 12, 2018, at 5:45 PM, Carlos Rovira wrote: > > Hi > > I made some simplification that works ok in Jewel: > > 1.-

Re: TypeNames vs ClassName

2018-03-12 Thread Alex Harui
If HTMLElement.classList is exposed to the user (the app developer) then they can remove any of the items that were added from the typenames. There is no way to enforce immutability of the typenames. We can choose to give up on that and require that app developers be careful, but I'd rather not.

Re: TypeNames vs ClassName

2018-03-12 Thread Carlos Rovira
Hi I made some simplification that works ok in Jewel: 1.- remove CSSClassList and use element.classList since is native and supported in all browsers we target, this simplifies code, and removes classes from core. 2.- I still need to use some additional code that can be simplified. I'm doing:

Re: TypeNames vs ClassName

2018-03-12 Thread Carlos Rovira
Hi, long thread and very useful read here. Since Jewel is very similar to MDL in adding/removing classes I want to comment here some things: 1.- I just changed jewel typenames to the constructor and things works ok, I could remove the createElement override 2.- I have into account the use of

Re: TypeNames vs ClassName

2018-03-05 Thread Alex Harui
Harbs please post code snippets so we can understand what you are referring to. I'm not too concerned about how much code is baked into MDL, but I'm more interested in the notion that there are just-in-case patterns that are somehow more optimal than on-demand patterns. I'm thinking there are

Re: TypeNames vs ClassName

2018-03-05 Thread Harbs
> On Mar 5, 2018, at 2:18 AM, Alex Harui wrote: > > Why are there so many empty strings and why do the cost so much? Should > we reference a single global empty string? If you mean in XML, I eliminated initializing *everything* in XML unless needed and I saw a

Re: TypeNames vs ClassName

2018-03-04 Thread Alex Harui
Why are there so many empty strings and why do the cost so much? Should we reference a single global empty string? I don't think I follow why just-in-case code is less than not-just-in-case code. I don't think I've ever really seen that. Can you provide more detail? -Alex On 3/4/18, 5:24 AM,

Re: TypeNames vs ClassName

2018-03-04 Thread Harbs
> On Mar 2, 2018, at 6:46 PM, Alex Harui wrote: > > Again, the principles of PAYG are that there is as little Just-in-case > code as possible. AIUI, every MDL user will be downloading and > initializing the ClassList prototype just-in-case. This is not true of >

Re: TypeNames vs ClassName

2018-03-02 Thread Alex Harui
Again, the principles of PAYG are that there is as little Just-in-case code as possible. AIUI, every MDL user will be downloading and initializing the ClassList prototype just-in-case. This is not true of Strings. It isn't just the cost of instantiation. There are download and class

Re: TypeNames vs ClassName

2018-03-02 Thread Piotr Zarzycki
Harbs, Thanks for such a good explanation. I think I will go with your class. 2018-03-02 10:36 GMT+01:00 Harbs : > I do agree that this is pretty low on the list of priorities. I did not > have a head to work on anything “serious” and the class lists was a nice >

Re: TypeNames vs ClassName

2018-03-02 Thread Harbs
I do agree that this is pretty low on the list of priorities. I did not have a head to work on anything “serious” and the class lists was a nice distraction for me. I’m certainly fine with however Piotr handles this. I would like to point out a few things: 1. Object instantiation is pretty

Re: TypeNames vs ClassName

2018-03-01 Thread Piotr Zarzycki
Maybe let's do this in that way. I could stay with your solution where I'm using that array class, but we could move it to the MDL module. Since this problem is specific right now to that. Maybe the computation won't be so large like it is in case of MDL, where you have 5-6 properties and you need

Re: TypeNames vs ClassName

2018-03-01 Thread Alex Harui
Very nice, but IMO, this is over-engineering. We are talking about a space-delimited list where some portion of it is considered "fixed" another portion is user-settable and another portion comes from other attributes. Some generic StringUtils or ListUtils might be more PAYG, especially if they

Re: TypeNames vs ClassName

2018-03-01 Thread Harbs
What do you think of the CSSClassList class I just committed? I *think* that makes the pattern more recognizable and probably is less heavy if more than one class can be used. Harbs > On Mar 1, 2018, at 11:56 PM, Piotr Zarzycki wrote: > > Harbs, Alex, > > I just

Re: TypeNames vs ClassName

2018-03-01 Thread Piotr Zarzycki
Harbs, Alex, I just pushed implementation of computeFinalClassNames to branch feature/type_names_class_name_issue124. You can review implementation in this commit [1] and example of usage in Card and Button. I have tested with Harbs example [3] and with Card by changing orders. It's working.

Re: TypeNames vs ClassName

2018-02-28 Thread Piotr Zarzycki
Let me play with implementation of that function. It seems to me that will be much cleaner than current solution. If user actually wanted to do anythin with className - let the overriding speaks. On Wed, Feb 28, 2018, 21:51 Alex Harui wrote: > On 2/28/18, 12:27 PM,

Re: TypeNames vs ClassName

2018-02-28 Thread Alex Harui
On 2/28/18, 12:27 PM, "Harbs" wrote: >OK. I think that will work for DML components, but what if there’s a bead >which needs to add class names? What would be the “right” way to do that? >A bead cannot override the function on the strand. Do we have beads that manipulate

Re: TypeNames vs ClassName

2018-02-28 Thread Harbs
OK. I think that will work for DML components, but what if there’s a bead which needs to add class names? What would be the “right” way to do that? A bead cannot override the function on the strand. > On Feb 28, 2018, at 10:17 PM, Alex Harui wrote: > > I think you

Re: TypeNames vs ClassName

2018-02-28 Thread Alex Harui
I think you are missing that the element.className is set to computeFinalClassNames. So the user is welcome to manipulate the UIBase.className however they see fit. They can assign it a whole new space-delimited list if they want. But what gets set on element.className is computed from

Re: TypeNames vs ClassName

2018-02-28 Thread Harbs
The problem which sparked this whole issue is like this: 1. We have some components (i.e. in MDL) which add “pieces” to the class names (such as “fab”, “raised”, “colored”, etc. 2. The client might subsequently set the className to something else. 3. When the component sets the “pieces” first

Re: TypeNames vs ClassName

2018-02-28 Thread Alex Harui
On 2/28/18, 10:44 AM, "Harbs" wrote: >If it’s not public, I don’t see how a utility method could call it though. I didn't think the utility methods like addClassName/removeClassName would need to alter computeFinalClassNames(). AIUI, for most UIBase subclasses, the final

Re: TypeNames vs ClassName

2018-02-28 Thread Harbs
If it’s not public, I don’t see how a utility method could call it though. > On Feb 28, 2018, at 8:21 PM, Alex Harui wrote: > > > > On 2/28/18, 9:50 AM, "Piotr Zarzycki" > wrote: > >> Ok Understand, but

Re: TypeNames vs ClassName

2018-02-28 Thread Alex Harui
On 2/28/18, 9:50 AM, "Piotr Zarzycki" wrote: >Ok Understand, but do you agree that computeFinalClassNames - is >something >which is in the UIBase ? Yes, and probably protected instead of public. The one in UIBase just appends typenames to className. It gets

Re: TypeNames vs ClassName

2018-02-28 Thread Piotr Zarzycki
Ok Understand, but do you agree that computeFinalClassNames - is something which is in the UIBase ? 2018-02-28 18:47 GMT+01:00 Alex Harui : > I think that in the shadow setter, it would change _shadow and call > setClassName(computeFinalClassNames()); > > On 2/28/18,

Re: TypeNames vs ClassName

2018-02-28 Thread Alex Harui
I think that in the shadow setter, it would change _shadow and call setClassName(computeFinalClassNames()); On 2/28/18, 9:33 AM, "Piotr Zarzycki" wrote: >Alex, > >So we are getting back to the idea where you proposed to have function >which computes everything. >

Re: TypeNames vs ClassName

2018-02-28 Thread Piotr Zarzycki
Alex, So we are getting back to the idea where you proposed to have function which computes everything. override public function computeFinalClassNames():String { return super.computeFinalClassNames() + " " + _shadow; } Where does that function should be placed ? Does that function should be

Re: TypeNames vs ClassName

2018-02-28 Thread Alex Harui
Hi Piotr, I think am I not communicating the principles effectively. First, IMO, addClassName and removeClassName should not be in UIBase. Lots of apps can be written without needing these methods. I think they can be written as utility functions. Second, the computation of the final

Re: TypeNames vs ClassName

2018-02-28 Thread Piotr Zarzycki
Hi Alex, Sorry about that. Let me show you code and I recorded GIF with problem debugging. *Code in UIBase which I have implemented:* addClassName and removeClassName [1]. addedToParent what is happen with internal field which I have added [2] *Code for Testing* [3] - I'm adding first

Re: TypeNames vs ClassName

2018-02-27 Thread Alex Harui
Hi Piotr, I could not understand this explanation. Might be better to show actual code. For example in #3, there is a cssClass variable that I don't know about. Also you mention at the bottom setting something as empty, but I'm not sure what that is. However, IMO, this code should be in

Re: TypeNames vs ClassName

2018-02-27 Thread Piotr Zarzycki
Here is how I'm thinking to resolve that issue. I would take Harb's proposition and add to UIBase addClassName() and removeClassName(). Next I would add internal field _internalClassName:String. addClassName(value): 1) Will check if provided class name exits in _className and in

Re: TypeNames vs ClassName

2018-02-27 Thread Piotr Zarzycki
I think I have analyzed everything and have some implementation proposition. I will try to provide it later today. Thanks, Piotr 2018-02-27 13:35 GMT+01:00 Harbs : > ExpandableSearch broke too. > > > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki

Re: TypeNames vs ClassName

2018-02-27 Thread Harbs
ExpandableSearch broke too. > On Feb 25, 2018, at 6:15 PM, Piotr Zarzycki wrote: > > Harbs, > > If you are using something more than MDL Dialog in your application it > would be great to get feedback whether I didn't break for you anything. :)

Re: TypeNames vs ClassName

2018-02-26 Thread Piotr Zarzycki
I know what you mean Harbs, but it may not be so easy to achieve. classList and className at some point are wiped out. When I was working on changes in MDL it happened in addedToParent. The end of all process to save things was always concatenating. I think having couple of functions is a good

Re: TypeNames vs ClassName

2018-02-26 Thread Alex Harui
My thinking is that there are a set of defaults in typeNames that match fake type selectors and should almost never be changed at runtime. What scenario made you want to change typeNames outside the component? Then there is another set of class names that you specify outside the component.

Re: TypeNames vs ClassName

2018-02-26 Thread Harbs
I think my main point was that we wouldn’t need computeFinalClassNames() which would be overridden in subclasses. If there’s simple a _classList:Array which would have something like: protected function applyClassNames():void { element.className = className ? className : “” + “ “ +

Re: TypeNames vs ClassName

2018-02-26 Thread Piotr Zarzycki
Harbs, You simply suggesting to have several functions instead of one which computes things? On Mon, Feb 26, 2018, 20:21 Harbs wrote: > Yes. Very thorough explanation. Thanks. > > It seems to me like there should be functions for addClassName() and > removeClassName()

Re: TypeNames vs ClassName

2018-02-26 Thread Harbs
Yes. Very thorough explanation. Thanks. It seems to me like there should be functions for addClassName() and removeClassName() which would add and remove the classNames from a list. When the className is computed, the list should be concatenated to classNames (and possibly typeNames — although

Re: TypeNames vs ClassName

2018-02-26 Thread Piotr Zarzycki
Hi Alex, Great reading and explanation. My first thought was to have something which computes className together, but currently it is needed for MDL only almost. I went with this additional function Utility. I think there won't be too much time when we will need such ability like switching and

Re: TypeNames vs ClassName

2018-02-26 Thread Alex Harui
Here's my view of this problem space. This is my opinion, not marching orders. Everything is up for discussion. This is what the current code is trying to do, though. Also, important note: The order of names in the HTMLElement.className does not matter. CSS style precedence is determined by

Re: TypeNames vs ClassName

2018-02-26 Thread Harbs
Yes. The changes did break things. I committed an alternate way of fixing things. There is a discussion on Github on how strictly we avoid changing typeNames: https://github.com/apache/royale-asjs/commit/c01ebc2cc946570006d8f5cea607182e16eaf0fe#r27788371

Re: TypeNames vs ClassName

2018-02-25 Thread Piotr Zarzycki
I just pushed changes to MDL. With couple of exceptions all typeNames landed to constructor. Thanks to that changes some components started to work better. I'm wondering whether I do not break anything. Harbs, If you are using something more than MDL Dialog in your application it would be great

Re: TypeNames vs ClassName

2018-02-24 Thread Alex Harui
Sorry, I wasn't clear. The function itself can go in Basic or better yet, Core, since I don't think it has any dependencies and can be use anywhere. I was just saying that I would prefer if none of the Basic components or UIBase used your new function. You should be able to write a Royale app

Re: TypeNames vs ClassName

2018-02-24 Thread Piotr Zarzycki
I was going to put it somewhere in the Basic, but I can leave it in the MDL. The className can be undefined in the case where you wanted to add something to such "undefinded" string you will got: "undefined myClass". - I probably cannot escape from that... Maybe I'm missing some way. 2018-02-24

Re: TypeNames vs ClassName

2018-02-24 Thread Alex Harui
Looks ok to me. Seems like you don't need COMPILE::JS. It should work on all platforms. We can have lots of utility functions in org.apache.royale.utils. In terms of optimization (size/performance) a function like this is potentially overkill for the Basic set. It is fine for MDL since MDL

Re: TypeNames vs ClassName

2018-02-24 Thread Piotr Zarzycki
Alex, I used your suggestion, added some additional things and I end up with following utility [1]. Usage will looks like that: [2]. Do you think it could be part of the framework ? It's working nicely with MDL. [1] https://paste.apache.org/tsaF [2] https://paste.apache.org/xbfb Thanks, Piotr

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
Well, whether you like it or not, the wrapper is mapping a space-delimited list to the array so if you manipulate the array you have to back-calculate the string. IMO, in HTML, the "class" property is a string and people are used to entering a space-delimited list. That's why we have a className

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
It's just swapping. If I have following code [1] - it is easier to manipulate classList than className which is simple string. What utility could look like ? It would be manipulating strings, which is less convenient. [1] https://paste.apache.org/at0H 2018-02-23 21:11 GMT+01:00 Alex Harui

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
Just compiler. No need for asjs changes at this time I think. I'm still unclear on why you need to manipulate classList directly. Is there some code that is in the JS from Material that manipulates classList? Or are you just trying to swap out a name on the classList? If the latter, why not

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
You did merge vivid compiler changes or also changes from asjs repository. As for my work on MDL. I ended up with something like that [1]. The question now how to propagate that code ? This is code for the component which manipulates classList. Should I create some parent class ? General/ for MDL

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
I think I have Maven using the basic.css appropriately. There is no way to default to including a SWC in Maven and then not use it in a child project, so all example poms that aren't MDL need to bring in the BasicTheme. Also, I had to merge the compiler change from vivid-ui-set branch to get the

Re: TypeNames vs ClassName

2018-02-23 Thread Carlos Rovira
Ok, maybe I had problems in the past due to what you say. Hope this changes remove that problems too thanks 2018-02-23 19:29 GMT+01:00 Alex Harui : > Hi Carlos, > > I think we've separated out basic.css and stopped misusing "className" in > the Basic components so

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
Hi Carlos, I think we've separated out basic.css and stopped misusing "className" in the Basic components so typeNames should work as expected in subclasses like MDL and possibly even Vivid. Piotr might as well finish up MDL so we can see if there might be issues that affect Vivid. My 2 cents,

Re: TypeNames vs ClassName

2018-02-23 Thread Carlos Rovira
Hi!, can't read all the thread right now, but I want to share a word of caution with MDL When I started that library, I had to fight a lot with typenames and classnames. Alex hopefully remember several emails about this topic. I ended with the current solution. As I excluded basic css, I think I

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
Understand! :) Now I can agree with you that typeNames could be protected. Definitely. Let me play farther with MDL and see where I end up. On Fri, Feb 23, 2018, 18:28 Alex Harui wrote: > > > On 2/23/18, 8:50 AM, "Piotr Zarzycki" wrote: > >

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
On 2/23/18, 8:50 AM, "Piotr Zarzycki" wrote: >Just the opposite. The typeNames get rid of everything what is setup in >the >classList. > >But className is being add typeNames. This is what is happen: > >typeNames=mdl-card >classList.add("someclass") > >In

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
Just the opposite. The typeNames get rid of everything what is setup in the classList. But className is being add typeNames. This is what is happen: typeNames=mdl-card classList.add("someclass") In addedToParent: className += typeNames classList is being wipped out and filled by className.

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
TypeNames is supposed to override what is in classList. ClassList should contain two sets of names. Immutable ones that come from typeNames like TextInput or Card that map to the component that is pointed to by element.royale_wrapper. That allows us to "extend" the set of TypeSelectors as folks

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
I'm not sure what you put in the theme for MDL. But it shouldn't matter whether it is in a theme or in MDL's defaults.css since nobody in MDLTabsExample is trying to override it. MDL only needs its own theme if someone will want to use the structural aspects of the MDL components (the layouts

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
Reading what you are saying here regarding classList and className w have a bug. typeNames shouldn't override what is inside classList, but this is what has happened in addedToParent. Am I understand you correctly? On Fri, Feb 23, 2018, 17:11 Alex Harui wrote: > > >

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
On 2/23/18, 7:32 AM, "Piotr Zarzycki" wrote: >Alex, > >I have started to work on MDL and move all typeNames from createElement to >constructor. Unfortunately something is not right here. > >1) I still need to exclude BasicJS.swc:default.css - I did add theme to

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
I have added separate theme for MDL - didn't touch basic.css at all. I did add it as an -theme=path - this doesn't change anything in Basic module. On Fri, Feb 23, 2018, 17:05 Piotr Zarzycki wrote: > I think I see where the issue may be, but not sure if it is an

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
I think I see where the issue may be, but not sure if it is an issue. I have created separate project where I have only MDL Card component. I'm setting property shardow = "2" [1]. This property is being called, but I don't have line with typeNames - it's deleted. What is happen: 1) Constructor

Re: TypeNames vs ClassName

2018-02-23 Thread Alex Harui
MDL does not want the basic.css theme. That is why we are moving styles from Basic:swc's defaults.css to themes/basic.css. I see that the Maven plugin doesn't allow specification of a theme, so that's another task. I can do it if nobody wants to take that on. So, yes, move the Button selectors

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
A bit more on point 1. and let's take for the example simple Button. We have some styles for Button in Basic.css. MDL Button extends TextButton - some styles naturally has been added from default.css. If I create theme I should achieve that my theme classes will override default.css Button styles

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
Alex, I have started to work on MDL and move all typeNames from createElement to constructor. Unfortunately something is not right here. 1) I still need to exclude BasicJS.swc:default.css - I did add theme to MaterialDesignLite module maven build - it didn't help. 2) If I cannot setup typeNames

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
Peter, That is interesting what you are saying. What will happen then if you have class which extends other one. The parent class is setting typeNames and derived one also before super? The parent one will override it? I cannot check now how typeNames is implemented. Piotr On Fri, Feb 23,

Re: TypeNames vs ClassName

2018-02-23 Thread Peter Ent
I have been guilty of this and have been using typeNames now. I've found that I need to set typeNames before calling super() in the constructor. I thought it was done afterwards, but if I set typeNames after calling super(), the typeName I set does not show up in the HTML produced. Also, suppose

Re: TypeNames vs ClassName

2018-02-23 Thread Gabe Harbs
There’s some edge cases which seem problematic. One example: ComboBoxBiew has the following: input = new TextInput(); input.className = "ComboBoxTextInput"; button = new TextButton(); button.className =

Re: TypeNames vs ClassName

2018-02-23 Thread Gabe Harbs
I’ll help. > On Feb 23, 2018, at 10:50 AM, Alex Harui wrote: > > Quick note before I shut down for the night. > > UIBase has both a typeNames and className property. TypeNames is used to > emulate Flex-like type selectors in the CSS lookup. It should be set in > the

Re: TypeNames vs ClassName

2018-02-23 Thread Piotr Zarzycki
Alex, I will look into the MDL. Thanks, Piotr 2018-02-23 9:50 GMT+01:00 Alex Harui : > Quick note before I shut down for the night. > > UIBase has both a typeNames and className property. TypeNames is used to > emulate Flex-like type selectors in the CSS lookup. It