This just seems like too much work for the hopefully seldom case of mixing
TLC's from various component sets. Remember that in "Terminology and
Concepts", the TLC's are just collections of beads. There should be little
dependencies of the beads on the host strand. Folks should be able to break
any TLC into its "exploded component".
There should be so little code in a TLC, that there really shouldn't be much
advantage to having a TLC in one component set subclass a TLC in another
component. The big re-use of code should come from subclassing and aggregating
beads and reusing utility functions.
Any manually controlled naming scheme just sets up another place for mistakes
and collisions. I think there are many more important things for us to work
on, like getting the emulation components to run.
My 2 cents,
-Alex
On 6/6/18, 12:28 AM, "Harbs" <harbs.li...@gmail.com> wrote:
While I was trying to figure out how the compiler handles CSS, a new idea
came to me which I think is better than any of the ideas we had until now (if I
might say so myself). ;-p
Basically, we can just use the component manifest file.
One of the issues I was struggling with is that if the type selector is
defined and hard-coded in the component class, that very much limits how other
component sets can use the component. I think this is part of what was
bothering Carlos as well.
By adding a new attribute to components, I think we can solve this problem
very nicely. For example in express-manifest:
<component id="Button" class="org.apache.royale.html.Button"
lookupOnly="true" typeNames=".express.Button”/>
Would define that any express|Button (used in an express namespace) should
be written with a selector of “.express.Button”. That is even if the class is
the same as one used by a different component set.
Of course, of that to work, the correct typeNames need to be assigned to
the classes. I think that could be defined in the CSS:
Button{
TypeNames: “.express.Button”;
}
Of course, this would require using ValuesManager to look up the classNames
for the component (i.e. this.typeNames =
ValuesManager.valuesImpl.getValue(this, "typeNames") as String), so it’s not
completely PAYG.
I would suggest for this one of a few of courses of action:
1. We could create a protected setTypeNames method in UIBase which would be
virtual and overridden by subclasses to either write the typeNames directly or
use the ValuesManager.
2. We could create a protected setTypeNames method in UIBase which uses the
ValuesManager by default and the subclasses would only override the method if
they want to set it directly.
3. We do nothing in UIBase, and each component decides whether to implement
a protected setTypeNames method (or similar) which could work in one of the two
aforementioned ways.
#3 is the most PAYG.
#2 is the least PAYG, but the most DRY. According to Royale principles, it
would generally not be the way we’d go, but I would prefer it because it gives
the most predictable behavior in terms of declarable CSS. TypeNames is also
pretty “Core” to Royale component sets, so it’s somewhat appropriate. It also
allows users to remove default CSS selectors from specific components should
they choose to do so.
Thoughts?
Harbs
> On Jun 1, 2018, at 9:25 AM, Alex Harui <aha...@adobe.com.INVALID> wrote:
>
> OK, then I think we are on roughly the same page. Earlier I proposed a
map of package names to short names. However, I just realized that it needs to
be a map of MXML namespaces to short names, and metadata won't work because I
think the rules get chosen by MXML namespace instead of package names because
you can map the same class into different MXML namespaces. If you want to map
"library://ns.apache.org/jewel <library://ns.apache.org/jewel>" to ".jewel." it
would have the desired result.
>
> My 2 cents,
> -Alex
>
> On 5/30/18, 11:58 PM, "Harbs" <harbs.li...@gmail.com
<mailto:harbs.li...@gmail.com>> wrote:
>
> 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> <mailto: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
<mailto: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>> <mailto: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>><mailto: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>> <mailto: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> <mailto: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> <mailto: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> <mailto: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%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>><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>>>
