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