Right.
> On May 31, 2018, at 10:29 AM, Carlos Rovira <[email protected]> wrote: > > Just an important point here: I understand that in this case, we're talking > about a metadata analyzed at compiler time, so there's no cost at runtime > and that metadata will not be preserved. I think that would be great > improvement > > I think Alex is thinking in some kind of metadata at runtime, but I > understand this is not the case. > > thanks > > 2018-05-31 8:58 GMT+02:00 Harbs <[email protected] > <mailto:[email protected]>>: > >> 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 <[email protected]> >> 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" <[email protected] >>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> 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 <[email protected] >>>> <mailto:[email protected]>> >> 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, "[email protected] >>>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> on behalf of >> Carlos Rovira" < >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>><mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> on behalf >> of >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> 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 <[email protected] >>>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>>: >>>> >>>>> 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 <[email protected] >>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 5/18/18, 2:50 AM, "Harbs" <[email protected] >>>>>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> 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= >>>> <https://na01.safelinks.protection.outlook.com/?url=> >> http%3A%2F%2Fabout.me >> <http://2fabout.me/>%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com >> <http://40adobe.com/>% >> 7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42% >> 2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0 <https://na01.safelinks >> <https://na01.safelinks/>. >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% >> <http://protection.outlook.com/?url=http%3A%2F%2Fabout.me%> >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>% >> 7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42% >> 2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0><https:// >> na01.safelinks.protection.outlook.com/?url=http%3A%2F% >> <http://na01.safelinks.protection.outlook.com/?url=http%3A%2F%> >> 2Fabout.me >> <http://2fabout.me/>%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com >> <http://40adobe.com/>% >> 7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42% >> 2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0 <https://na01.safelinks >> <https://na01.safelinks/>. >> protection.outlook.com/?url=http%3A%2F%2Fabout.me% >> <http://protection.outlook.com/?url=http%3A%2F%2Fabout.me%> >> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com <http://40adobe.com/>% >> 7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178de >> cee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42% >> 2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0>> >> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira>
