I’m not talking about solving subclassing here. I’m talking about one thing: How to determine what classnames the compiler writes to HTML CSS files for specific types.
Carlos and I would both like for the compiler to compile: j|Button{ background-color: #fff; } To: .jewel.Button{ background-color: #fff; } Rather than: org_apache_royale_jewel_Button{ background-color: #fff; } And we all agree that we don’t want: .Button{ background-color: #fff; } The question is how to accomplish that. We’re suggesting to include some kind of meta tag or comment in the Button class source which acts as a compiler directive to specify exactly what to output. If you have another suggestion on how we can achieve that goal, that’s fine too. Makes sense? Harbs > On May 31, 2018, at 12:30 AM, Alex Harui <aha...@adobe.com.INVALID> wrote: > > There has always been an option to keep/strip metadata in the output. It is > -compiler.keep-as3-metadata. > > I don't think I understand what you are proposing with metadata. I thought > I'd shown that there was no easy way to solve what the runtime > (ValuesManager) should do. I thought we'd agreed upthread that metadata was > not required, and we would decide on some short-name abbreviations based on > the fully qualified names (package and class name). The abbreviation scheme > doesn't have to be perfect, as long as it reduces likelihood of collision at > very low cost. An example might be that you can register abbreviation > mappings so we say that "oarh" is short for "org.apache.royale.html". > > Thoughts? > -Alex > > On 5/29/18, 5:47 AM, "Harbs" <harbs.li...@gmail.com > <mailto:harbs.li...@gmail.com>> wrote: > > Sorry for the delay in response here. I was not feeling very well last > week… (I forgot how much work an infant is…) ;-) > > I think it’s time to wrap this up. > > I don’t think there’s any completely PAYG solution to this problem. I > think conflicts need to be prevented by default. > > I like the metadata and .basic.Button approach and I think it’s more PAYG > than org_apache_royale_html_Button. Theoretically, component sets can just > use “Button” and ignore conflicts for complete PAYG (although I would not > recommend that). > > We should definitely use metadata that does not insure a runtime tax. If > we could somehow strip out the bracket metadata, I prefer that. Using > metadata would allow different component sets to make their own decisions. > > Thanks, > Harbs > >> On May 21, 2018, at 7:41 PM, Alex Harui <aha...@adobe.com.INVALID> wrote: >> >> I think we are in agreement. My most recent posts were intended to show >> that #2 is not easily solvable, if at all, and thus we should not invest >> time or energy there. >> >> My only suggestions regarding #1 is that we do not invent a second naming >> system, and that whatever we do is PAYG in the sense that I don’t expect >> users to mix component sets as much as borrow beads from other component >> sets. Folks who have the goal of building the smallest possible app with >> only one component set should not pay for the possibility of mixing in other >> component sets. >> >> My 2 cents, >> -Alex >> >> On 5/21/18, 7:00 AM, "carlos.rov...@gmail.com >> <mailto:carlos.rov...@gmail.com> <mailto:carlos.rov...@gmail.com >> <mailto:carlos.rov...@gmail.com>> on behalf of Carlos Rovira" >> <carlos.rov...@gmail.com >> <mailto:carlos.rov...@gmail.com><mailto:carlos.rov...@gmail.com >> <mailto:carlos.rov...@gmail.com>> on behalf of carlosrov...@apache.org >> <mailto:carlosrov...@apache.org> <mailto:carlosrov...@apache.org >> <mailto:carlosrov...@apache.org>>> wrote: >> >> I think Harbs is right here. >> >> We should take into account that as we focus on presentation (CSS, styles, >> drawings, colors, fonts) things are showing that before passed unnoticed. >> And now we have the chance to address all of this to make architecture and >> presentation get to its best. Both things are equally important here, >> Royale finaly has to be very careful with visual things since we are an >> interface framework, so if we get styling things works as flexible as >> possible, we can expect designers to work with royale. >> >> Thanks >> >> 2018-05-21 11:35 GMT+02:00 Harbs <harbs.li...@gmail.com >> <mailto:harbs.li...@gmail.com>>: >> >>> I’m getting confused. >>> >>> Let me try and summarize the issues as I understand them: >>> >>> There are two different types of issues: Compile time issues, and runtime >>> issues. >>> >>> Compile time issues are: >>> 1. Compiled css files do not differentiate between different packages. >>> (i.e. ImageButton type selectors will always compile to and .ImageButton >>> class selector, no matter what the package name is. >>> 2. There’s no way to prevent superclass dependencies from being included >>> in output when they are specified in Type selectors in Royale CSS files. >>> >>> Runtime issues: >>> 1. Because of the issue in #1 above, there can be css styling conflicts >>> across component sets. >>> >>> I’m pretty sure that ValuesManager is currently working fine. >>> >>> From my perspective, the only issue which *needs* to be solved is compiler >>> issue #1. That seems like a relatively simple issue to solve. Solving that >>> does not require any runtime metadata. All we need is for the “typenames” >>> variable in a class to match whatever class name selector the compiler >>> outputs in the CSS file. It does *not* need to be the same qualified class >>> name that the ValuesManager uses at runtime. The classname that’s actually >>> assigned to the HTML element needs to match the CSS class selector in the >>> CSS file and it needs to be unique across packages. >>> >>> Resolving this will fix all the runtime issue that I know of. >>> >>> Resolving compiler issue #2 is a nice “plus” if we can do it. It would >>> allow subclassing components without necessarily bringing in all the >>> superclass CSS dependencies. I *think* your main points have to do with >>> issue #2. >>> >>> Are we on the same page here, or am I missing something? >>> >>> Harbs >>> >>> >>>> On May 19, 2018, at 2:50 AM, Alex Harui <aha...@adobe.com.INVALID >>>> <mailto:aha...@adobe.com.INVALID>> >>> wrote: >>>> >>>> >>>> >>>> On 5/18/18, 2:50 AM, "Harbs" <harbs.li...@gmail.com >>>> <mailto:harbs.li...@gmail.com>> wrote: >>>> And basic.css has: >>>> RadioButton >>>> { >>>> font-size: 12px; >>>> font-family: sans-serif; >>>> } >>>> >>>> RadioButton is a Royale Type Selector as it should be. No discussion >>> on that front (with the exception that the styling should be removed from >>> the defaults.css). >>>> >>>> Te whole question is what happens in MyApp.css which is compiled >>> standard HTML CSS. >>>> >>>> Currently we get: >>>> >>>> .RadioButton { >>>> font-family: sans-serif; >>>> font-size: 12px; >>>> } >>>> >>>> This CSS comes from the Type Selector in basic.css. This seems to be >>> included in the app.css even if RadioButton is not included. But putting >>> that point aside at the moment, the question is what the class selector (in >>> app.css) should be *produced* from the type selector. >>>> >>>> It is not obvious why RadioButton is in the app.css. This might be a >>> new bug from the theme handling I did recently. I will investigate more. >>>> >>>> I think we agree that “.RadioButton" is not right because there can >>> be RadioButton from more than one component set. >>>> >>>> One option is to fully qualify the *compiled* class selector so it’s >>> named “.org_apache_royale_html_RadioButton”. I’m pretty sure this is what >>> you are proposing. The primary objection to that is that it’s a rather long >>> string and kind of “ugly”. >>>> >>>> You can choose other string transformations, but the key point is that >>> they should be derived from the unique QName. Any other scheme just means >>> that the developer has to solve the unique name problem twice which >>> increases the chance of collision. >>>> >>>> Another option is “.basic.Button”. The advantage of this approach is >>> mostly aesthetics. It also has the advantage of being theoretically more >>> flexible because CSS can be applied to “basic" and “Button” separately. Of >>> course that goes both ways and if there’s css applied to “.Button” by >>> mistake, it can effect the “basic” Button where it’s not supposed to. >>>> >>>> I'm not clear how the compiler or the ValuesManager (at runtime) can >>> efficiently associate .basic.Button with org.apache.royale.basic.Button. >>> Metadata lookups can be expensive. >>>> >>>> >>>>> If one problem is with Type Selectors in Royale inheriting styles from >>> Base Classes, we should discuss ways to manage that. Metadata is possible, >>> but metadata is expensive at runtime. >>>> >>>> Good point about extra code from meta tags. Maybe the compiler could >>> strip these out? >>>> >>>> My point is that ValuesManager will need this information at runtime. >>>> >>>> My suggestion with meta-data was a way to enable the second option. >>> It does not need to be specifically meta-tags. It could be something like >>> this as well: >>>> >>>> /** >>>> * royaleclassselector RadioButton >>>> * royaleclassprefix basic >>>> * royaleinheritsbaseselector >>>> */ >>>> >>>> These ASDoc directives are definitely not available at runtime. >>>> >>>> >>>>> There are two parts to how Type Selectors work. The main concern >>> appears to be the ClassReferences kind of CSS, which is not handled by the >>> Browser. The IValuesImpl has to decide whether to look up the base class >>> and it would have to fetch and parse metadata at runtime to do that. And, >>> as I mentioned earlier, I'm not sure the compiler can know whether the base >>> class is in the output because it was directly instantiated or not. >>>> >>>> I’m not sure how the IValuesImpl actually works, so I have no >>> thoughts on this front. I’m not clear on whether there is currently an >>> issue with that. I’ve been discussing plain CSS which *is* handled by the >>> browser. >>>> >>>>> Historically, the only reason Type Selectors inherit from Base Classes >>> in Flex is because of app developer subclassing. For sure, we the >>> framework developers can always take the time to fill out the Type >>> Selectors such that the lookup never goes to the Base Class. But the app >>> devs just want to use a component as the top tag in an MXMLComponent or do >>> a cheap "MyButton extends Button" in AS. And without inheritance, you >>> don't get any defaults and things blow up. >>>>> >>>>> We could say to the app devs:: "too bad, in Royale you gotta copy the >>> base class type selector". I would imagine non-Royale folks have to copy >>> HTML Type Selectors in some cases already. >>>>> >>>>> We could try to find all subclasses of classes that have Type Selectors >>> that don't have their own Type Selector and have the compiler auto-copy >>> that base class Type Selector (or add the subclass to the list of classes >>> for that selector. >>>> >>>> I think we *should* have inheritance (like we have today) unless a >>> subclass specifically disables it using metadata or what-have-you. >>>> >>>> >>>> Let's try some example code: >>>> >>>> <Application> >>>> <initialView> >>>> <View> >>>> <ComboBox> >>>> <RadioButton /> >>>> </View> >>>> </iniialView> >>>> </Application> >>>> >>>> Button will be linked in because ComboBox composites a Button. It will >>> also be linked in because RadioButton subclasses Button. There is code in >>> IValuesImpls that loop through the base classes to resolve Type Selector >>> inheritance. Roughly: >>>> >>>> Var baseClass:Class = thisObject.getBaseClass(); >>>> While (baseClass) { >>>> Var qname = getQualifiedClassName(baseClass); >>>> Var stylesObject:Object = styles[qname]; >>>> If (stylesObject != null && stylesObject[styleProp] !== undefined) >>>> Return stylesObject[styleProp] >>>> baseClass = baseClass.getBaseClass(); >>>> } >>>> >>>> When looking up styles for RadioButton, if you don't want this code to >>> then go check for Button (which will rightly be in the app.css because of >>> ComboBox) you will need some metadata or other information at runtime. You >>> can't rely on the Button styles not being there because the compiler saw >>> the metadata on RadioButton and decided not to put the Button styles in the >>> app.css. >>>> >>>> And also, I don't think there is a way to easily know what caused a >>> reference to Button in the first place. Take out ComboBox and replace it >>> with: >>>> >>>> <fx:Script> >>>> Var foo:Button; >>>> </fx:Script> >>>> >>>> Button never gets instantiated, but it was used and therefore linked >>> in. I don't see how the compiler could know that Button was never directly >>> instantiated and thus can be pruned from the app.css. >>>> >>>> That's why instead of coming up with fancy pruning schemes, I recommend >>> that we try different ways of solving the problems caused if Type Selectors >>> don't inherit styles from base classes ever. Then the code in the >>> IValuesImpl wouldn't have a loop. Then maybe the compiler should detect >>> that a simple subclass has no styles and add that subclass to the styles in >>> the app.css >>>> >>>> MyRadioButton, RadioButton { >>>> ... >>>> } >>>> >>>> Thoughts? >>>> -Alex >>>> >>>> >>>> >>> >>> >> >> >> -- >> Carlos Rovira >> >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42%2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0 >> >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42%2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42%2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0 >> >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42%2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0>>