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 <harbs.li...@gmail.com>:
> 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 <aha...@adobe.com.INVALID>
> 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" <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>> 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 <aha...@adobe.com.INVALID>
> 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, "carlos.rov...@gmail.com <mailto:
> carlos.rov...@gmail.com> <mailto:carlos.rov...@gmail.com <mailto:
> carlos.rov...@gmail.com>> on behalf of Carlos Rovira" <
> carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com><mailto:
> carlos.rov...@gmail.com <mailto:carlos.rov...@gmail.com>> on behalf of
> carlosrov...@apache.org <mailto:carlosrov...@apache.org> <mailto:
> carlosrov...@apache.org <mailto:carlosrov...@apache.org>>> 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 <harbs.li...@gmail.com <mailto:
> harbs.li...@gmail.com>>:
> >>
> >>> 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 <aha...@adobe.com.INVALID
> <mailto:aha...@adobe.com.INVALID>>
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 5/18/18, 2:50 AM, "Harbs" <harbs.li...@gmail.com <mailto:
> harbs.li...@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
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >> --
> >> Carlos Rovira
> >> https://na01.safelinks.protection.outlook.com/?url=
> http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%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%2Fabout.me%
> 2Fcarlosrovira&data=02%7C01%7Caharui%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%
> 2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%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%2Fabout.me%
> 2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%
> 7Caee5e54c6ada489ec79c08d5bf2332fa%7Cfa7b1b5a7b34438794aed2c178de
> cee1%7C0%7C0%7C636625080285751377&sdata=LQlu181aXL1Md42%
> 2BDlfUR8ajl6eTR7hcVTQsg9%2BXqMI%3D&reserved=0>>
>
>
--
Carlos Rovira
http://about.me/carlosrovira
