royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)
Date Fri, 18 May 2018 23:50:57 GMT


On 5/18/18, 2:50 AM, "Harbs" <harbs.lists@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



Mime
View raw message