Why is IItemRendererInitializer separate from IItemRendererClassFactory?
> On Feb 21, 2020, at 12:03 AM, Alex Harui <aha...@adobe.com.invalid> wrote: > > I pushed changes that I think has everything working in Jewel by using the > same "has" pattern that is used in other component sets. > > The Lists in the ToDo examples use a regular ItemRendererClassFactory instead > of SelectableItemRendererClassFactory that is now used in most other places > (List/DataGrid/Table) > > The recommended pattern for disabling selection in a list is whether you > choose a ClassFactory that attaches a Selection Bead to each renderer. There > was an exception to that rule in one of the Table examples because it wanted > only certain renderers to not have selection. I added a bead that turns off > the selection for that case. IMO, how to deal with such an exception will be > based more on what percentage of the renderers need selection. If most do, > then add a Selection Bead to all renderers but disable selection where you > don't want it. If most do not want selection, then add the bead where you > need it. > > Thanks, > -Alex > > On 2/20/20, 11:28 AM, "Carlos Rovira" <carlosrov...@apache.org > <mailto:carlosrov...@apache.org>> wrote: > > yes, Jewel has the "structure" and is organized in SASS files, then > JewelTheme has the "styling" part and is as well SASS. > so Jewel should not need to change, and people should only need to change > JewelTheme or create a new theme one using it as a template. > > I'll add examples to ant tomorrow > > thanks > > > El jue., 20 feb. 2020 a las 20:17, Alex Harui (<aha...@adobe.com.invalid>) > escribió: > >> >> >> On 2/20/20, 11:04 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: >> >> forgot to say. Can you add missing examples to ANT? don't know where >> to do >> that >> and checking Jewel don't see the use of >> SelectableItemRendererClassFactory. >> all times ItemRendererClassFactory is used >> >> I could fix the Ant side, but I don't have time. It think all you need to >> do is add it to the examples/build.xml >> >> I didn't use SelectableItemRendererClassFactory in Jewel because I wasn't >> sure if the selection was supposed to be changeable at runtime. I think >> you've confirmed that it isn't so we can change to use >> SelectableItemRendererClassFactory >> >> I knew the themes were generated by SASS, but I didn't realize the Jewel >> one was as well. >> >> -Alex >> >> El jue., 20 feb. 2020 a las 20:00, Carlos Rovira (< >> carlosrov...@apache.org>) >> escribió: >> >>> Hi Alex, >>> >>> remember that Jewel uses SASS to create the CSS. I already pushed a >> commit >>> with ["warning"]. It's not the first time I warn about it ;) >>> You must to change SASS file. The css is just generated (like other >>> generations in compiler), and is committed since no body added SASS >> to ANT. >>> Maven has a sass plugin to compile SASS. >>> >>> I saw you response and commented there >>> >>> Thanks >>> >>> Carlos >>> >>> >>> El jue., 20 feb. 2020 a las 19:55, Alex Harui >> (<aha...@adobe.com.invalid>) >>> escribió: >>> >>>> I replied on this topic on your commit email. >>>> >>>> So I don't have to copy that into this thread, read what I said in >> that >>>> email and reply on that thread and let's figure out the right thing >> to do. >>>> I am having some weird problem with my Maven build where every time >> I try >>>> to change Jewel's defaults.css something overwrites it. I'm trying >> to >>>> figure out what is going on there. >>>> >>>> -Alex >>>> >>>> On 2/20/20, 10:47 AM, "Carlos Rovira" <carlosrov...@apache.org> >> wrote: >>>> >>>> Hi Alex, >>>> >>>> I found that TodoMVC examples was not working, so I fixed it >> removing >>>> the >>>> non existing properties (hoverable and selectable). >>>> But I found Jewel ListItemRenderer has all baked, so I created a >>>> SimpleListItemRenderer (in Jewel Simple in the normal prefix >> for a >>>> "base", >>>> "basic" or "simple" option) that hast the minimum required. >>>> >>>> So at least in Jewel if people wants hoverable and selectable >>>> renderers use >>>> the normal ListItemRenderer. >>>> If don't want that indicators, use SimpleListItemRenderer. If >> you >>>> want just >>>> show hover, but not selected state, then extend Simple version >> and >>>> add " >>>> ClassSelectorListRuntimeSelectableItemRendererBead" and >> configure to >>>> have >>>> just "hoverable" to true ¿ok? >>>> >>>> Hope I understand ok how it works. Let me know if something is >> not as >>>> expected. >>>> >>>> Thanks >>>> >>>> Carlos >>>> >>>> >>>> >>>> El jue., 20 feb. 2020 a las 18:06, Alex Harui >>>> (<aha...@adobe.com.invalid>) >>>> escribió: >>>> >>>>> I'm not sure I understand what you mean by "control". >>>>> >>>>> Before the "has" changes, every ItemRenderer contained or >> inherited >>>> code >>>>> that had hovered/selected APIs that drew visuals, and the >>>> ItemRenderer also >>>>> "had" a bead like ItemRendererMouseController that set the >> hovered >>>> property >>>>> on that item renderer, and the List's controller would set the >>>> selected >>>>> property. >>>>> >>>>> Now, every ItemRenderer "has" a bead that has the >> hovered/selected >>>>> properties, and the ItemRendererMouseController and the >> Lists's >>>> controllers >>>>> get that bead instead of talking to the ItemRenderer >> directly. I >>>> guess >>>>> that's the new way of thinking for has/composition vs >>>> is/inheritance: a >>>>> component doesn't have to have all of its APIs glued to its >> API >>>> surface. >>>>> We mainly do that for convenience in MXML, but for more >> internal >>>> stuff like >>>>> this, loose-coupling via has/composition shared more code and >>>> increases >>>>> configurability, but does add some runtime overhead in its >> raw form. >>>>> Hopefully we can optimize that away. >>>>> >>>>> HTH, >>>>> -Alex >>>>> >>>>> On 2/20/20, 5:01 AM, "Piotr Zarzycki" < >> piotrzarzyck...@gmail.com> >>>> wrote: >>>>> >>>>> Hi Alex, >>>>> >>>>> Could you provide an example how would I control >>>> hovering/selecting in >>>>> item >>>>> renderer when I don't have build in hover property etc. ? >> How >>>> should I >>>>> compose such item renderer ? >>>>> >>>>> Thanks, >>>>> Piotr >>>>> >>>>> czw., 20 lut 2020 o 03:20 Alex Harui >> <aha...@adobe.com.invalid> >>>>> napisał(a): >>>>> >>>>>> I pushed the "has" changes. TourDeJewel seems to be >> working >>>>> correctly for >>>>>> me. >>>>>> >>>>>> The principle of "has" is similar to inheritance vs >>>> composition. >>>>> Just >>>>>> like top-level components like List are composed of many >>>> beads, the >>>>> item >>>>>> renderers are now composed of more beads as well. That >>>> reduces the >>>>>> requirement to add code to a class in order to "be/is" >>>> something. >>>>>> >>>>>> There used to be copies of code that drew hover and >> selected >>>> states >>>>> on >>>>>> the item renderers in each new kind of item renderer >> that >>>> couldn't >>>>> inherit >>>>>> from an item renderer that could draw selected and >> hovered >>>> states. >>>>> Now, >>>>>> the itemrenderers compose their selection visuals. A >> single >>>> item >>>>> renderer >>>>>> like StringItemRenderer can be composed with no >> selection >>>> drawing at >>>>> all, >>>>>> or with solid color selection drawing or with alternate >> color >>>>> selection >>>>>> drawing or something new. And that means that some >> new >>>> kind of >>>>> item >>>>>> renderer, like a TextInput can become an item renderer >> more >>>> easily, >>>>> by >>>>>> composing a selection visuals bead instead of having to >> add >>>> all of >>>>> that >>>>>> code. >>>>>> >>>>>> Another place I started using "has" but didn't fully >> replace >>>> the old >>>>> code >>>>>> was in handling itemRendererParent, which is now called >>>>>> itemRendererOwnerView (to try to make it more clear >> that isn't >>>>> always the >>>>>> parent of the item renderer and is sometimes an internal >>>>>> datagroup/container). Turns out a lot of our renderers >>>> didn't need >>>>> to know >>>>>> the itemRendererParent, so in many cases we no longer >> figure >>>> it out >>>>> and >>>>>> assign it. But in cases where it is needed, the >> property is >>>>> currently left >>>>>> baked into the renderer, but in some new cases, it is >>>> composed. An >>>>>> ItemRendererOwnerViewBead is added to the strand >> instead of >>>> added to >>>>> a >>>>>> class and contains the reference to the ownerView. >> Maybe >>>> someday >>>>> we'll >>>>>> fully remove the old pattern, not sure. >>>>>> >>>>>> Ideally we would do more "has" than "is". It could >> allow us >>>> to >>>>> eliminate >>>>>> much of the required code to be a top tag in an MXML >> document. >>>>>> >>>>>> Other changes in this branch were to add "Initializers" >> so the >>>>>> RendererFactories didn't bake in code for specific item >>>> renderers, >>>>> and to >>>>>> create a few base classes with overrides so there is >> less >>>> code to >>>>> maintain. >>>>>> >>>>>> There should be little if any impact to application >> code. It >>>> should >>>>>> mainly affect the internals of how item renderer-based >> things >>>> are >>>>> created. >>>>>> >>>>>> Thanks, >>>>>> -Alex >>>>>> >>>>>> On 2/17/20, 4:33 PM, "Carlos Rovira" < >> carlosrov...@apache.org >>>>> >>>>> wrote: >>>>>> >>>>>> Hi Alex, >>>>>> >>>>>> if will be of help if you point us to different >> links >>>> where we >>>>> can >>>>>> learn >>>>>> about this modifications, since I at least can just >>>> imagine what >>>>> is all >>>>>> about, but will need to get deeper in the concepts >> to >>>> understand >>>>> the >>>>>> changes and to apply this patterns. >>>>>> >>>>>> In Jewel each "list component has its own type of >>>> renderer, so >>>>> for >>>>>> example >>>>>> List uses ListItemRenderer and DataGrid has >>>>> DataGridItemRenderer, since >>>>>> usually at that component level the user needs >> similar >>>>> infrastructure >>>>>> like >>>>>> hoverable, selectable...and some (not much) more, >> don't >>>> know >>>>> right now >>>>>> how >>>>>> all this will fit with the "has" new >> pattern....I'll try >>>> it. >>>>>> >>>>>> Just one important thing. There's actual users and >>>> clients using >>>>> Jewel >>>>>> and >>>>>> other UI sets and are with very short times for >> their >>>>> migrations, so >>>>>> just >>>>>> want to ask you to test as much as possible, since >> TDJ >>>> has many >>>>>> examples >>>>>> now. Other thing you can test is new TodoMVC to see >> how it >>>>> behaves, >>>>>> since >>>>>> it uses a List with IRs. So we can ensure (as much >> as we >>>> can) >>>>> the merge >>>>>> left things working (as much as we can) >>>>>> >>>>>> Thanks for working on this, will try all of this >> tomorrow >>>>>> >>>>>> Carlos >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> El lun., 17 feb. 2020 a las 22:35, Alex Harui >>>>>> (<aha...@adobe.com.invalid>) >>>>>> escribió: >>>>>> >>>>>>> I've pushed the "has" branch that contains a >>>> refactoring of >>>>> the item >>>>>>> renderers. Tour De Jewel and MDL Example seem to >> be >>>> working >>>>> as is >>>>>> Basic >>>>>>> List Example and MX AdvancedDataGrid. >>>>>>> >>>>>>> "has" is really just calls to getBeadByType. If >> we >>>> start to >>>>> see >>>>>>> performance issues, then we'll look into >> optimizing. >>>> The >>>>> motivation >>>>>> to >>>>>>> switch to "has" came from several bugs about >> using MX >>>>> Label/CheckBox >>>>>> as >>>>>>> item renderers. In Royale, the ItemRenderers >> were in >>>> control >>>>> of the >>>>>>> visuals of their rollover and selected state. >> That is >>>> a more >>>>> proper >>>>>>> encapsulation than the way it was in Flex where >> the >>>> lists drew >>>>> the >>>>>> rollover >>>>>>> and selected states and it was hard to override >> the >>>> visuals >>>>> for a >>>>>> custom >>>>>>> item renderer. But in the develop branch Royale >> code, >>>> it would >>>>>> require >>>>>>> that custom itemrenderers implement a lot of APIs >>>> related to >>>>>> rollover and >>>>>>> selected visuals. Instead we can now reuse/share >> code >>>> for >>>>> visuals >>>>>> between >>>>>>> different renderers because a renderer now can >> "has" a >>>>>> rollover/selection >>>>>>> implementation instead of being one. >>>>>>> >>>>>>> There are more pieces involved, but there is more >>>> sharing of >>>>> code. >>>>>> Along >>>>>>> the way I found that there were some not-so-PAYG >>>> patterns >>>>> being used >>>>>> in MDL >>>>>>> and Jewel renderers that might deserve further >>>> modification. >>>>> There >>>>>> are >>>>>>> "hoverable" and "selectable" APIs that appear to >> be >>>> used to >>>>>> permanently >>>>>>> turn off selection and hover visuals. In >> general, I >>>> think >>>>> there is >>>>>> better >>>>>>> use of PAYG and composition when functionality is >>>> "built up" >>>>> and not >>>>>>> "turned off", so with the "has" pattern the >> renderers >>>> can be >>>>> added >>>>>> to a >>>>>>> list without any selection visuals at all (for a >>>> non-selectable >>>>>> list) or >>>>>>> re-composed with custom visuals that only support >>>> hoverable, >>>>> for >>>>>> example. >>>>>>> I left it "hoverable/selectable" in the API >> surface for >>>> now, >>>>> but >>>>>> something >>>>>>> to think about going forward. >>>>>>> >>>>>>> I’m going to run a few more tests before merging >> and >>>> pushing to >>>>>> develop. >>>>>>> >>>>>>> -Alex >>>>>>> >>>>>>> On 1/15/20, 10:44 PM, "Alex Harui" >>>> <aha...@adobe.com.INVALID> >>>>> wrote: >>>>>>> >>>>>>> You are welcome to try and see how many cache >> hits >>>> it >>>>> gets. I >>>>>> think >>>>>>> in renderers, we ask once per renderer. I'm not >> sure >>>> there is >>>>> a >>>>>> faster way >>>>>>> to do the first lookup of "is", but for "has" we >> could >>>> change >>>>> the >>>>>> lookup >>>>>>> and save time. >>>>>>> >>>>>>> On 1/15/20, 10:38 PM, "Greg Dove" < >>>> greg.d...@gmail.com> >>>>> wrote: >>>>>>> >>>>>>> For the 'something is ISomeInterface' >>>>>>> I had wondered in the past if these types >> of >>>> lookups >>>>> could be >>>>>>> incrementally >>>>>>> cached on the 'is' target (after first >> lookup), >>>> that >>>>> might >>>>>> make >>>>>>> sense for >>>>>>> interfaces, which are the deepest checks I >>>> think? >>>>>>> caching result (could optionally create >> the Map) >>>>>>> >>>> ISomeInterface['implMap'].set(something.constructor, >>>>>> isResult ) >>>>>>> >>>>>>> then earlier in the interface checks, it >> could >>>> do >>>>> something >>>>>> like: >>>>>>> if (ISomeInterface['implMap'] && >>>>>>> >>>> ISomeInterface['implMap'].has(something.constructor) ) >>>>> return >>>>>>> >>>> ISomeInterface['implMap'].get(something.constructor) >>>>>>> >>>>>>> I realize its extra code, but it should be >>>> quite a bit >>>>>> faster over >>>>>>> time I >>>>>>> think. >>>>>>> >>>>>>> On Thu, Jan 16, 2020 at 7:20 PM Alex Harui >>>>>>> <aha...@adobe.com.invalid> wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> Several different threads have brought >> up >>>> issues with >>>>>> sharing >>>>>>> code between >>>>>>>> component sets. Other threads have >> offered >>>>> different and >>>>>> clever >>>>>>> ways to >>>>>>>> do various things like how MXML is >> applied to >>>> a >>>>> component. >>>>>>> Meanwhile, over >>>>>>>> in MX emulation, I was starting to copy >> some >>>> code >>>>> from >>>>>> Basic to >>>>>>> MXRoyale to >>>>>>>> get the various MX components to be >> valid item >>>>> renderers. >>>>>>> MXRoyale is >>>>>>>> using Basic's item renderer architecture >>>> which is >>>>> better >>>>>>> encapsulated: the >>>>>>>> renderer draws its hovered and selected >>>> state. In >>>>> Flex, >>>>>> the >>>>>>> List draws >>>>>>>> over the renderer, which makes it hard >> to >>>> customize >>>>> the >>>>>> way the >>>>>>> renderer >>>>>>>> will look when hovered and selected. >>>>>>>> >>>>>>>> It finally occurred to me that one of >> the >>>> reasons we >>>>> end up >>>>>>> copying code >>>>>>>> is because we are still using too many >> "is" >>>> checks >>>>> instead >>>>>> of >>>>>>> "has" >>>>>>>> checks. I'm not even sure we have any >> "has" >>>> checks >>>>> in the >>>>>> Royale >>>>>>>> framework. I was afraid of the >> overhead of a >>>> "has" >>>>> check, >>>>>> but >>>>>>> I'm starting >>>>>>>> to change my mind because: >>>>>>>> >>>>>>>> 1) The "is" check actually runs a fair >> amount >>>> of >>>>> code, >>>>>>> especially for >>>>>>>> (comp is ISomeInterface) >>>>>>>> 2) The length of bead arrays don't seem >> too >>>> long. >>>>>>>> >>>>>>>> A "has" check calls >>>> getBeadByType(ISomeInterface), >>>>> so it >>>>>>> actually will run >>>>>>>> the (bead is ISomeInterface) on >> potentially >>>> the >>>>> entire >>>>>> strand >>>>>>> array/vector, >>>>>>>> although we could speed that up by >> annotating >>>> beads >>>>> or >>>>>> keeping >>>>>>> track of >>>>>>>> what is on the strand. But the code >>>> sharing/reuse >>>>>> potential of >>>>>>> this >>>>>>>> pattern seems significant to me. >>>>>>>> >>>>>>>> For example, it could change how hard >> it is >>>> to make a >>>>>> component >>>>>>> usable as >>>>>>>> a top tag in MXML. Instead of the >> component >>>> having >>>>> to >>>>>> implement >>>>>>> certain >>>>>>>> methods, the component could have a bead >>>> installed >>>>> and the >>>>>>>> MXMLDataInterpreter could talk to that >> bead >>>> instead >>>>> of the >>>>>>> component. >>>>>>>> >>>>>>>> In the case of the item renderers, >> instead of >>>>> testing if >>>>>> the >>>>>>> renderer "is" >>>>>>>> ISelectableLIstItemRenderer, it could >> ask if >>>> the >>>>> created >>>>>> widget >>>>>>> "has" an >>>>>>>> ISelectableLIstItemRenderer bead and the >>>> logic in >>>>> that >>>>>> bead can >>>>>>> be reused >>>>>>>> in both Basic and MXRoyale without being >>>> copied. >>>>>>>> >>>>>>>> Some code, like Container overrides of >>>> addElement >>>>> probably >>>>>> can't >>>>>>> be >>>>>>>> refactored into a "has". But I wonder >> how >>>> many other >>>>>> things >>>>>>> could. I'm >>>>>>>> not sure I would move everything that >> could >>>> be moved >>>>> into a >>>>>>> shared bead. >>>>>>>> We'd have to think about the overhead >> on small >>>>> components >>>>>> and >>>>>>> apps. But >>>>>>>> for MXML support and Item Renderer >> support, >>>> it seems >>>>> to >>>>>> make >>>>>>> sense. >>>>>>>> >>>>>>>> Anyway, I will look into refactoring >> the item >>>>> renderer >>>>>> code in >>>>>>> a few days >>>>>>>> unless feedback indicates otherwise. >> Bugs >>>> like #676 >>>>> and >>>>>> #681 >>>>>>> inspired this >>>>>>>> post. >>>>>>>> >>>>>>>> Of course, I could be wrong... >>>>>>>> -Alex >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Carlos Rovira >>>>>> >>>>>> >>>>> >>>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0> >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> Piotr Zarzycki >>>>> >>>>> Patreon: * >>>>> >>>> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0> >>>>> < >>>>> >>>> >> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=lM47VH2eMRha92QDljuklrrPWagubgNvaL6WurTBiwg%3D&reserved=0> >>>>>> * >>>>> >>>>> >>>>> >>>> >>>> -- >>>> Carlos Rovira >>>> >>>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0> >>>> >>>> >>>> >>> >>> -- >>> Carlos Rovira >>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0> >>> >>> >> >> -- >> Carlos Rovira >> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288392599&sdata=MegTTo0lt%2Fp1zKt6gaowEYo5a9XDkuM3SHQcCccUa2Y%3D&reserved=0> >> >> >> > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0 > > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cc5187f5b4e28463bdb1b08d7b63b1ad4%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637178237288402599&sdata=JcJWURIyUxG4bru0YjyB6xM%2FKPUEbNGfZ3zj%2FUB5jUU%3D&reserved=0>
