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]> 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]> on behalf of Carlos Rovira" > <[email protected] <mailto:[email protected]> on behalf of > [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]>: > >> 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]> >> wrote: >>> >>> >>> >>> On 5/18/18, 2:50 AM, "Harbs" <[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=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>
