royale-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harbs <harbs.li...@gmail.com>
Subject Re: Type Selector Approximation (was Re: [DISCUSS] Explanation of the changes)
Date Thu, 31 May 2018 07:43:34 GMT
Right.

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message