Hi Alex, And I think that approach is perfectly valid. But we tend to think the rest of us are wrong, and I think that's not the case. Don't you think that if we solve this king of problems (let's call it "styling problems"), we can get a more visual Royale to put material online in website and social networks, and as well new example apps that looks beautiful and that will bring more active users on board?
I think we are pursuing the same, I think as well we need the actual strategy we are following, some people in emulation effort, some others, in theming, some others in tools...and so on. People will not come if you get emulation working but it looks ugly, and as well not come if we get Jewel working but they don't have the emulation strategy solved, and will not come if we have the other points, but they can't use IntelliJ (for example) in a huge team that use that tool...and so on... so for me all is important, and although I thing I'll not a emulation user, I see the huge benefits it can bring to royale. You can look at it in other way, I don't see Harbs and me (for example) investing time in emulation, so better to work in other parts that needs improvement as well right? thanks 2018-06-06 19:20 GMT+02:00 Alex Harui <[email protected]>: > IMO, the thing that will have the greatest impact on whether Adobe will > continue to pay me to work full time on Royale is how many active users we > have at the end of the year, not whether we have a really cool way of > avoiding type selector name collisions. So I am asking folks to consider > that we may be better off just getting things to work for more users > instead of taking longer to make them perfect for one. And that's why > emulation components are my highest priority. > > My 2 more cents, > -Alex > > On 6/6/18, 9:37 AM, "Carlos Rovira" <[email protected]> wrote: > > I think as well this is important. Very important. We must notice that > we > are a multidisciplinar team and we must take advantage of that making > each > one work in the areas where they get the most of it. I think if Harbs > wants > to make this happen, I think he should do that. For needs, I think MX > emulation is important, but not more or less than get this solve as > well. > Think that, for example, in my case or in Harbs case, probably will > not use > MX emulation at all, while others will use it. In the other part, we'll > make heavy use of that feature. > > I already said this, I thought as well on "typeNames" problem of > hardcode > in a class, as when I see in a class hardcoded styles...I see many > problems > in those kind of things, so taking the time and energy to solve it, I > think > is a time well invested. > > My 2... > > Thanks > > > > 2018-06-06 18:26 GMT+02:00 Harbs <[email protected]>: > > > > This just seems like too much work for the hopefully seldom case of > > mixing TLC's from various component sets. > > > > Well, I am already doing that… Maybe I’m the exception, but it’s not > a > > theoretical need. ;-) > > > > It also would enable us to use Basic and Express TLCs in Jewel — > without > > subclassing at all. > > > > There’s a bigger picture aspect of this as well which is probably > most > > important. It would enable component sets to declare how their > typenames > > should be written in CSS. Right now, Carlos is forced to write his > Jewel > > CSS using class selectors. I would really like to be able to change > that to > > type selectors and declaring the selectors in the manifest would > enable > > that. > > > > This might be something I could work on, but I’d likely need > direction. > > > > Thanks, > > Harbs > > > > > On Jun 6, 2018, at 6:33 PM, Alex Harui <[email protected]> > wrote: > > > > > > 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" <[email protected]> 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 <[email protected]> > > 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" <[email protected] <mailto: > > [email protected]>> 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 > <[email protected]> > > 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" <[email protected] <mailto: > > [email protected]> <mailto:[email protected] <mailto: > > [email protected]>>> 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 > <[email protected] > > <mailto:[email protected]>> 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, "[email protected] <mailto: > > [email protected]> <mailto:[email protected] <mailto: > > [email protected]>> <mailto:[email protected] <mailto: > > [email protected]> <mailto:[email protected] <mailto: > > [email protected]>>> on behalf of Carlos Rovira" < > > [email protected] <mailto:[email protected]> <mailto: > > [email protected] <mailto:[email protected]>><mailto: > > [email protected] <mailto:[email protected]> <mailto: > > [email protected] <mailto:[email protected]>>> on > behalf of > > [email protected] <mailto:[email protected]> <mailto: > > [email protected] <mailto:[email protected]>> <mailto: > > [email protected] <mailto:[email protected]> <mailto: > > [email protected] <mailto:[email protected]>>>> 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 <[email protected] > <mailto: > > [email protected]> <mailto:[email protected] <mailto: > > [email protected]>>>: > > >>>> > > >>>>> 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 > <[email protected] > > <mailto:[email protected]> <mailto:[email protected] > > <mailto:[email protected]>>> > > >>>>> wrote: > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> On 5/18/18, 2:50 AM, "Harbs" <[email protected] <mailto: > > [email protected]> <mailto:[email protected] <mailto: > > [email protected]>>> 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= > https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=pgWZoLSQVVLsYl321NNQ3bmWyy8Juo > nZHMA%2BGVMIdeA%3D&reserved=0. > > 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= > https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=pgWZoLSQVVLsYl321NNQ3bmWyy8Juo > nZHMA%2BGVMIdeA%3D&reserved=0. > > 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= > https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=pgWZoLSQVVLsYl321NNQ3bmWyy8Juo > nZHMA%2BGVMIdeA%3D&reserved=0. > > 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= > https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=pgWZoLSQVVLsYl321NNQ3bmWyy8Juo > nZHMA%2BGVMIdeA%3D&reserved=0. > > 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= > https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=pgWZoLSQVVLsYl321NNQ3bmWyy8Juo > nZHMA%2BGVMIdeA%3D&reserved=0. > > 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= > https%3A%2F%2Fna01.safelinks&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=pgWZoLSQVVLsYl321NNQ3bmWyy8Juo > nZHMA%2BGVMIdeA%3D&reserved=0. > > 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 > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7Ce5da0f759d424a1dfb2708d5cbcbd74a%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636638998707297264&sdata=5abyh7R96cTSEQwFAo2WjI3zq4NQ% > 2FPNPEDZ0Xz0y9zs%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
