>
> It is a bug. In the framework. The defaults.css for Basic has a
> .DynamicDataGrid in it. It shouldn't have that. (There might be another
> framework bug where a ClassReference in .DynamicDataGrid referenced DataGrid
> which bring in DataGridButtonBar which brings in ButtonBar) That's an
> example of Class Selectors being used instead of Type Selectors. If we
> created an actual subclass of DataGrid called DynamicDataGrid then the CSS
> could use a Type Selector instead of a Class Selector and the problem goes
> away. IMO, we need to decide on some good ways to stop using class
> selectors or prune class selectors.
>
OK. Great. I assumed the bug was in the compiler. Great to hear it’s not. Yes.
We definitely need to get rid of those class selectors from framework CSS. I
can work on that.
>
> I don’t understand why the compiler cannot build a list of used classes
> and drop any CSS references not used.
>
> It does have that depending on what you mean by "used". If "used" means
> referenced by the code, it appears to be working correctly. If you are
> suggesting that the compiler tracks whether a class is actually instantiated,
> that's a bit harder mainly because we would need to retain that information
> in the SWC somewhere and we don't currently store compile-time information
> elsewhere in the SWC. We could try to prune more in post-processing for JS
> only. We could search every JS file for "new Button", but even then, I think
> you'd miss where a className was stored in a variable and then instantiated
> which is what ValuesManager does. So I'm not sure the compiler can truly
> know what classes got directly instantiated.
I think including code from class selectors is an acceptable limitation.
(feature?) My comment was because of my erroneous assumption that the bug was
in the compiler.
> I’m not sure we’re talking the same language. The class selector for
> ImageButton will always be (in HTML css) .ImageButton. So if you have a basic
> ImageButton and a Jewel ImageButton, there will be CSS conflicts in the
> compiled HTML CSS.
>
> The above statement isn't true. I already mentioned upthread that the HTML
> css could be .org_apache_royale_basic_ImageButton.
>
> I think there is a fundamental disagreement here. I think we should be
> approximating how Type Selectors work. That is because fully qualified type
> names are essentially already guaranteed to be unique. The compiler will
> catch duplicates. IMO, we want to leverage strong typing. It is Royale's
> technical advantage over all of the manual conventions I see folks having to
> use in other JS frameworks. I think you want to propose some scheme to use
> class selectors and not use Type Selectors. This is doable, but requires a
> manual convention. The component developer theoretically already decided on
> how to make the fully qualified component name unique by selecting a unique
> package name. Now you want the component developer to have to identify
> another unique name to ensure the class selector names don't collide. And
> those names are going to want to be "friendly" names like "Basic" and
> "Jewel". I don't get why using QNames is not sufficient. If it is too
> verbose in the output, maybe we can find a way to shorten it. IMO,
> uniqueness is probably better handled by tooling instead of manual
> conventions.
>
> Let's make sure we can't use Type Selectors before discussion a scheme for
> using Class Selectors. Uniqueness is built in to Type Selectors.
I think we are in agreement but the wires are being crossed on terminology.
I am in total agreement that framework CSS should always use Type Selectors. In
other words, defaults.css should include:
RadioButton
{
IBeadModel:
ClassReference("org.apache.royale.html.beads.models.ValueToggleButtonModel");
IBeadView:
ClassReference("org.apache.royale.html.beads.RadioButtonView");
font-size: 11px;
font-family: Arial;
}
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.
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”.
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.
> 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 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
*/
> 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.
Thanks,
Harbs
P.S. I’m going to be off-line for a couple of days.
