Hi Alex, I think Jewel born from Basic and started doing the same as Basic do in order to develop the view, CSS, etc... then is evolving to something that is usable directly. For example: in the beginning there was Button and TextButton like in Basic, then I find that only Button (with text property) was needed since is what we already use it 99% of the time. In the other hand, things like "Disabled" is already written as a bead since is a behavior that is needed sometimes. I'm trying to balance so maybe the response is that is not white, but is not back. So I think is not exactly a Express set when all is preconfigured. I must say that I'm still learning from developing Jewel and I'm testing things and sometimes I refactor to what seems a better solution. In the end I use to think in how the code finaly looks, and if is usable, flexible and how simple is to write it. So like in many other fields, iteration over an idea and decision based on empiric testing use to end in the best solution.
I think Express use to tend mostly to what Flex was, and I think not all in flex was good, so I hope Jewel could get some things equal, but be better in other fields. For example, I never liked Validation in Flex, I think is too tied to the view controls, while Validation should validate date, so be tied to models instead. As well loved the way this was implemented in GraniteDS with Metadata, maybe this could be bring to Jewel in bead form, we'll see when we come to that point. Other case I'm finding now is for example how to deal with incoming collections from a Server. In Basic List controls manage ICollectionView, so we can do what we did in Flex storing data in ArrayLists or instead, store in simple Array and then making a SingleSelectionArrayListModel, since normaly that would be what people will use. So people can plug directly their Array to list.dataprovider, and the control will knows how to consume the Array. In this case Jewel can give a preselected bead configuration that should be the use in mostly all cases, since the actual SingleSelectionCollectionViewModel in Basic is not usable unless application developers store make a conversion of the incoming Array to ArrayList to feed the control. So, in resume I think Jewel is right now in a middle step between Basic and Express in terms of low-high configuration 2018-05-24 21:48 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > Changing subject in case people have stopped reading. > > I think the question in the subject should be decided before we continue > the package name discussion. After thinking about it more, I really do > think that Jewel should default to using Express beads (which might also > mean that we need to create a few more Express beads). My reasoning is > that we've already heard from users that a "high-configuration" component > set like Basic was a pain to work with, which is why started creating a > "low-configuration" set with Express. It doesn't make sense to go back to > "high-configuration" in Jewel. Jewel should be the one component set folks > use to get to know Royale and it should have both a good default > look-and-feel (which Carlos has done) but also be "low-configuration". > Jewel has enough CSS and complex Views that we shouldn't be worried about > trying to make Jewel lighter by not using Express beads. Folks can > optimize by swapping out beads as needed. > > Thoughts? > -Alex > > On 5/22/18, 3:59 PM, "carlos.rov...@gmail.com on behalf of Carlos > Rovira" <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> > wrote: > > Hi Alex, > > I think we are saying the same in essence. > > I want to reuse beads. So lets take "TextPrompt" bead and have only > one in > all Royale (always that make the same of course), think that is in a > library called "Foundation" that depends from Core but is not core. > Seems > "Foundation" is a name less confusing than Basic. All UI sets, link > this > foundation library and take what they want from it. Normally all UI > sets > will borrow "TextPrompt" bead. The same with the pieces in you DataGrid > example. > > In the other hand, UI sets has its own implementation of "Button" (and > the > rest of components), and the CSS that wires all the beads used in that > concrete Button, and the rest of controls and components in that UI > Set. I > think we all said that we want to reuse, but we don't want to use a CSS > from other UI set. So this concrete implementations of controls and > components and the CSS should go in each library, and so we'll have > Basic, > Jewel, MDL, CreateJS,... > > Have sense to have Basic CSS and controls in Foundation? for me > clearly no, > since Jewel will not use it at all. Will use Foundation classes, (in > your > example DataGrid pieces to reuse almost all of it). Will use the CSS > that > wires all beads used in Basic, clearly not. So the code that goes in > each > UI set library is clearly not reusable at all, and we don't want the > compiler to take extra time processing the CSS that wires all beads > from a > UI Set that will not be used right?. > > The opposite will be "lets take all ui set implementations (Basic, > Jewel, > MDL, CreateJS,...) and mix altogether in a unique Foundation library > with > all control and components implementations and all the CSSs that wires > the > beads". Make this sense? For me clearly not. Moreover, in this case why > have libraries for Network, Binding, Collections...? Hope this extreme > case > showcased makes more sense to explain. > > If we want to reuse lets go and reuse, I'm all for it, but we shouldn't > have the CSS that binds all together for a UI Set that will not be used > since doesn't support anything in the normal use. And all of this even > if > we get rid of the current bugs that brings lots of things to the final > bake. > > I think a library or SWC is in essence a reusable piece, but we not > link > all existing SWC for all projects since we know we'll not using *all* > available SWCs we have, and since we don't want the compiler process > all > CSSs in all that libraries all the time, since is time consuming. For > this > reason we create the current SWC libraries, since if people will not > use > Network, they normally don't link, if they use Basic, but not Jewel, > MDL, > and CreateJS, those are not linked. > > Finaly, if I'll not use Basic...then I don't want to be obligated to > link > Basic (basic controls, and CSS) but I want to link Foundation since > are the > reusable pieces in all Royale UI Sets. > > Hope this explanation make more sense. > > Thanks > > Carlos > > > > > > > > 2018-05-22 23:43 GMT+02:00 Alex Harui <aha...@adobe.com.invalid>: > > > Hi Carlos, > > > > I guess I don't understand why separating beads from TLCs is > better. How > > will that make things better for users or other component set > developers? > > That would effectively double the number of SWCs and each TLC SWC > will need > > its bead SWC. That doesn't sound like a good thing to me, but if > that's > > what other folks want to do, that's fine with me. > > > > I was just looking through the classes in Jewel. It looks like JeweL > > doesn't have a DataGrid yet.. When it does, I would think you will > want to > > use the DataGridModel from Express as it handles both Arrays and > > ICollectionViews. We will probably create a similar model bead that > takes > > both ICollectionViews and Arrays for Lists and put that in Express as > > well. Then we might decide that is better for Jewel to use that > model > > instead. Or maybe we'll decide to create a JewelExpress set that > has those > > more general models that don't require as much configuration. > Anyway, I > > hope you agree that at some point, these more general models will be > used > > by Express and some flavor of Jewel. I don't think this general > model > > should go in Core, or Basic (or some new category called > Foundation). And > > at that point, Jewel or JewelExpress is going to re-use that code in > > Express. > > > > Component sets are encouraged to re-use existing code from any other > SWC > > since I think we've agreed that re-use is important. > > > > My 2 cents, > > -Alex > > > > On 5/21/18, 11:16 AM, "carlos.rov...@gmail.com on behalf of Carlos > > Rovira" <carlos.rov...@gmail.com on behalf of > carlosrov...@apache.org> > > wrote: > > > > Hi Alex > > > > what do you think about separating the part in Basic that is > > inherently the > > same as in Jewel (Button, CheckBox, TextInput, List, ...) along > with > > CSS > > that wire the beads for Basic UI set, and left the fundamental > building > > blocks as something that is not Core but can be reused by Basic > and > > Jewel > > (Let's call this "Foundation" Lib, I even like this name for this > > library). > > > > I mean that having "Foundation" lib and "Basic" lib, will be more > > clear, > > since we can expect what is in Basic will be never reused to > build > > other UI > > Sets (MDL, or others can still hang from there or if someone > wants to > > take > > the time refactor it). > > > > Foundation will not have any CSS wiring beads. We can return > classes > > from > > Core to Foundation. > > > > Basic will have its own CSS wiring beads, the same for Jewel. > Both will > > requiere Core and Foundation. > > > > I assume this will make all of us happy. > > > > We can as well do the package name changes to ensure consistency > along > > all > > code and libraries. > > > > Let me know what do you think > > > > thanks > > > > Carlos > > > > > > 2018-05-21 19:38 GMT+02:00 Alex Harui <aha...@adobe.com.invalid > >: > > > > > I understand this isn't the latest post on this thread, but it > is the > > > easiest one for me to reply to: > > > > > > First, the hopefully easy things we can agree on: > > > -I have no objection to dropping "Bead" off of bead class names > > > -I have no objection to moving all views into a view subfolder > as > > long as > > > nobody else is concerned about the size and performance issues. > > > -I have no objection to moving classes in Basic that are > > > org.apache.royale.html to org.apache.royale.basic. > > > -I have no objection to doing a massive rename and long as it > isn't > > me > > > doing the work. > > > -Whatever is in Core and Basic now or before Carlos's started > moving > > > things around is not perfect. > > > > > > Now for the less easy. Regarding Core vs Basic, I see it this > way: > > Basic > > > is the simplest implementation of the constructs/concepts in > > Royale. It is > > > intended to be extended and enhanced by other component sets > via our > > PAYG > > > principles. Core is intended to identify the > constructs/concepts > > and their > > > fundamental contracts. > > > > > > Think of it this way: When you open any class in Royale, you > will > > want to > > > know what kind of class it is. It is a TLC, a Bead? And what > kind > > of TLC > > > or Bead? Is it View, Model, Controller? An ItemRenderer? > These > > are the > > > categories of classes we had, even in Flex. I've probably > left out > > a few > > > categories. It is the interfaces for these categories that go > in > > Core. > > > And maybe some classes we think are universal implementations > of > > those > > > categories. And some beads that are component set agnostic, > like > > > BrowserResizeHandler, although we could move those to another > SWC > > and say > > > that Core should not have any MXML components except maybe > State. > > > > > > After any rename/refactor we decide on, Basic should still > have some > > > interfaces because those interfaces describe the contract > required > > for the > > > simplest implementation. I get that it can be a fine line > between > > > "fundamental" and "simplest", but where many classes that were > in > > Basic get > > > away from "fundamental" is mainly around Containers. The way > we > > handle > > > Containers in Basic really seems like an opinion instead of a > > universal, > > > "everyone must implement Containers this way" sort of thing. > So it > > does > > > not seem right that lots of Container-related things were > moved to > > Core. > > > > > > I thought we had agreement on the Terminology and Concepts > thread > > that > > > re-usable pieces would be organized into multiple SWCs like > Apache > > or AS3 > > > Commons. Any component set designer gets to choose what SWCs > to > > borrow > > > from. The emulation SWCs may borrow from Express because they > want > > to > > > re-use multi-purpose beads and aren't interested in the > smallest, > > fastest, > > > implementation. Assuming we fix any issues with accidentally > > dragging in > > > classes that aren't used, if you can re-use code from some > other > > group of > > > classes in another SWC, just do it. But do it because you > "want to". > > > There is no "need to". The implementers should "want" to > re-use > > code when > > > possible. > > > > > > In the end, many component sets will re-use Basic beads. > Maybe even > > > transitively because they re-use Express which re-uses Basic. > That > > should > > > be ok. That doesn't make it Core. It just that lots of > component > > sets > > > will start from simple implementations and add more complex > > functionality. > > > The goal is to minimize code size and maximize performance by > > re-using > > > code. And as I thought we had agreed upon in Terminology and > > Concepts, we > > > should not be afraid to re-use code. We are asking our users > to do > > exactly > > > the same. We must create testing infrastructure and have > review > > periods > > > and other processes so we don't break downstream component > sets or > > our > > > users applications. > > > > > > One related tidbit: IMO, the way folks will know what beads > work > > with > > > what components will be done by identifying what interfaces > the beads > > > implement, but also, I expected that we would use ASDoc as > well. If > > you > > > rummage through the source, you'll see that I annotated a few > > classes with > > > @viewbead and @toplevel. We could add more. And because our > ASDoc > > is an > > > app, we can then apply smarter filtering that help folks > narrow down > > what > > > their choices are, similar to many of the online shopping > filters I > > see. > > > > > > My 2 cents, > > > -Alex > > > > > > > > > On 5/21/18, 3:53 AM, "Harbs" <harbs.li...@gmail.com> wrote: > > > > > > Thank you for this. > > > > > > There’s two groups of files that were changed: Interfaces > and and > > > Classes. > > > > > > In general, I would be more inclined to move interfaces > than > > classes, > > > but there are some things to consider: > > > > > > 1. There are still 17 interfaces in Basic. If the 5 that > were > > moved > > > belong in Core, what about the remaining 17? > > > 2. I don’t think we’ve come to an agreement on what > belongs in > > Core > > > and what belongs in Basic. > > > 3. I’d like to some to an agreement on a package name > pattern. > > What > > > defines something belonging to a “core” path as opposed to an > “html” > > path? > > > Some classes are in supportClasses and some had that removed > from > > the path. > > > What’s the logic? etc. > > > 4. How should different pieces (such as different bead > types) be > > > defined in paths? (I don’t think we’re completely consistent > today.) > > > > > > I think we are coming to a conclusion on the CSS issues > that > > Jewel > > > brought up. I think the CSS problems can be solved no matter > whether > > we > > > move things between packages and no matter wether we change > package > > paths. > > > I think the question on reorganization needs to be discussed > on its > > own > > > right. Do you agree with that? > > > > > > First organization of packages: > > > To me, there are two primary questions related to Core vs. > Basic: > > > 1. What is the defining criteria for something to belong > in Core > > as > > > opposed to Basic? > > > 2. Is there an issue with one component set (i.e. Jewel) > to rely > > on > > > another (i.e. Basic). > > > > > > To be clear: I do believe that there is likely some > > reorganization > > > appropriate, but I’m not clear on exactly what and how. > > > > > > Depending on the answers to these questions, we can have a > > number of > > > different courses of action. We might keep things very similar > to > > how they > > > are. We might move things from Basic to Core. We might split > Basic > > into two > > > packages. Other options? > > > > > > Regarding package paths: I don’t think there’s a single > “right” > > answer > > > to that, but we do need to agree on a pattern that we all > stick to. > > > Currently (even before any refactor) package paths feel like > many are > > > haphazard, and I often have difficulty guessing what the path > is for > > a > > > specific class. I also sometimes have difficulty guessing which > > package a > > > specific class belongs to. > > > > > > These are the high-level questions I have. > > > > > > Please allow me to focus on question #2. I find it easiest > to > > discuss > > > concrete examples, so I’m taking TextPrompt, but it’s just an > > example. > > > Basic has a TextPromptBead. Jewel has TextPrompt. The code of > the two > > > classes are identical. I’m assuming TextPrompt was copied > because > > > TextPromptBead does not belong in Core (something I agree > with), and > > you > > > did not want Jewel to have a dependency on Basic. So my > question is > > > (assuming CSS and classes not used are not copied), what is > wrong > > with > > > Jewel using the TextPromptBead in Basic? To me the advantage of > > using the > > > Basic bead is that there’s no code duplication and that helps > from a > > > development perspective (i.e. only a single place to fix bugs) > and > > from a > > > perspective of code size in the resulting application (in case > both > > classes > > > are used somewhere). > > > > > > Harbs > > > > > > > On May 21, 2018, at 11:29 AM, Carlos Rovira < > > carlosrov...@apache.org> > > > wrote: > > > > > > > > Hi, > > > > > > > > as we talked I take the time to make a list of package > name > > changes. > > > > Finally 20 classes were changed from package. > > > > Here's the list from 16c0dcd643974fe708fd67a3774ea6 > e35e879811 > > (in > > > red the > > > > changes to better following) > > > > > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/MXMLBeadView.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html > > > > /MXMLBeadView.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/views/ContainerView.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/html/beads/ContainerView.as. > > > > (1) > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/views/DataContainerView.as > > > > frameworks/projects/Basic/src/ > > main/royale/org/apache/royale/ > > > html > > > > /beads/DataContainerView.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/GroupView.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html > > > > /beads/GroupView.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/IBackgroundBead.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/ > > > > html/beads/IBackgroundBead.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/IBorderBead.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html > > > > /beads/IBorderBead.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/IDropDownListView.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/html > > > > /beads/IDropDownListView.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/IListView.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > > html/beads/IListView.as. > > > > (2) > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/ITextFieldView.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/ > > > > html/beads/ITextFieldView.as (2) > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/TextFieldViewBase.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/html/beads/TextFieldViewBase.as > > > > (2) > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/layouts/LayoutChangeNotifier.as > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html > > > > /beads/layouts/LayoutChangeNotifier.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/models/ArraySelectionModel.as > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html > > > > /beads/models/ArraySelectionModel.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/beads/models/ViewportModel.as > > > > frameworks/projects/Basic/src/ > > main/royale/org/apache/royale/ > > > html > > > > /beads/models/ViewportModel.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/supportClasses/Border.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/ > > > > html/supportClasses/Border.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/supportClasses/ContainerContentArea.as > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > > html/supportClasses/ContainerContentArea.as. > > > > (2) > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/supportClasses/DataGroup.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/html/supportClasses/DataGroup.as > > > > > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/DataItemRenderer.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html/ > > > > supportClasses/DataItemRenderer.as (3) > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/MXMLItemRenderer.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html/ > > > > supportClasses/MXMLItemRenderer.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/UIItemRendererBase.as > > > > > > > > frameworks/projects/Basic/src/ > main/royale/org/apache/royale/ > > html/ > > > > supportClasses/UIItemRendererBase.as > > > > frameworks/projects/Core/src/ > main/royale/org/apache/royale/ > > > core/supportClasses/Viewport.as > > > > frameworks/projects/Basic/src/ > > > main/royale/org/apache/royale/html > > > > /supportClasses/Viewport.as > > > > > > > > Some comments: > > > > > > > > (1) "views" should follow the same package structure we > have > > with > > > other > > > > beads 8"models", "controllers"...) to be consistent. > > > > (2) should go to "core/beads/views" as well > > > > (3) item renderers that should normaly be used by final > users > > could > > > go some > > > > kind of "itemRenderers" package, while base item redeemer > > classes > > > could go > > > > again to supportClasses. > > > > > > > > As Harbs said, if we agree in the change of packages, we > > should do > > > this > > > > well and perform some other changes that make all more > > consistent > > > though > > > > libraries. > > > > > > > > Thanks > > > > > > > > Carlos > > > > > > > > > > > > > > > > > > > > 2018-05-17 11:16 GMT+02:00 Harbs <harbs.li...@gmail.com > >: > > > > > > > >> Definitely a plan. > > > >> > > > >> My guess is that if we agree on changing package paths, > there > > will > > > likely > > > >> be other classes that should be considered. > > > >> > > > >> My preference would be to have this discussion after we > > finish the > > > project > > > >> refactor discussion because I think it’s going to be > related > > to the > > > outcome > > > >> of that. > > > >> > > > >> Either way, I don’t think discussion should hold up the > 0.9.3 > > > release. > > > >> We’re already past due for a release. We want to > “release > > early and > > > release > > > >> often”… ;-) > > > >> > > > >> Thanks, > > > >> Harbs > > > >> > > > >>> On May 17, 2018, at 12:07 PM, Carlos Rovira < > > > carlosrov...@apache.org> > > > >> wrote: > > > >>> > > > >>> Ok, > > > >>> > > > >>> what if: > > > >>> > > > >>> * I take the time to generate a list of classes with > package > > name > > > changes > > > >>> * Make a thread with the list to expose it > > > >>> * Let's see from there if people can live with it > (We'll call > > > people to > > > >>> express about this changes and could see if are or not > > dramatic to > > > them) > > > >>> > > > >>> Sounds this like a plan? > > > >>> > > > >>> Thanks > > > >>> > > > >>> > > > >>> > > > >>> 2018-05-17 10:58 GMT+02:00 Harbs < > harbs.li...@gmail.com>: > > > >>> > > > >>>> Sure. Same here. > > > >>>> > > > >>>> But things are much more stable now. As we move > closer to > > “1.0”, > > > I think > > > >>>> we should be more careful about breaking changes and > > documenting > > > them > > > >> when > > > >>>> we decide they are necessary. > > > >>>> > > > >>>> As far as these specific changes go: We haven’t even > come > > to a > > > >> conclusion > > > >>>> on what (if any) package names should change yet, and > > including > > > those > > > >>>> changes in a release is premature. If we do change > package > > names, > > > I’m of > > > >>>> the opinion that they should be decided on and all > happen > > at once > > > to > > > >>>> minimize impact on end-users. > > > >>>> > > > >>>> Does that help clarify things? > > > >>>> > > > >>>> Thanks, > > > >>>> Harbs > > > >>>> > > > >>>>> On May 17, 2018, at 11:49 AM, Justin Mclean < > > > jus...@classsoftware.com> > > > >>>> wrote: > > > >>>>> > > > >>>>> Hi, > > > >>>>> > > > >>>>>> We are at the point where people are using Royale in > > > production. While > > > >>>> we can make breaking changes if they are warranted, > they > > should > > > be kept > > > >> to > > > >>>> an absolute minimum and be carefully considered and > well > > > documented if > > > >> we > > > >>>> do. > > > >>>>> > > > >>>>> There has been many previous breaking changes that > broke > > the > > > >> application > > > >>>> I was working on and some more major than this and > cost me > > a lot > > > of > > > >> time to > > > >>>> fix. Until you make it version 1.0 I think people will > > expect > > > that some > > > >>>> things may break with a new version. So why should > this be > > an > > > exception > > > >> to > > > >>>> what has happened before? Saying that however, what > would > > be good > > > to > > > >> see is > > > >>>> to provide guidance to what users need to change so > their > > app > > > works with > > > >>>> any changes / backward compatibility issues. > > > >>>>> > > > >>>>> Thanks, > > > >>>>> Justin > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> -- > > > >>> Carlos Rovira > > > >>> https://na01.safelinks.protection.outlook.com/?url= > > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui% > > 40adobe.com% > > > 7Cbbb82e5ac5e34921bfe908d5bf09044e% > 7Cfa7b1b5a7b34438794aed2c178de > > > cee1%7C0%7C0%7C636624967805497091&sdata= > > bdXVzZzjutIIwP9lWwAjosfP3JsQDt > > > rkTp%2FcrETCLE4%3D&reserved=0 > > > >> > > > >> > > > > > > > > > > > > -- > > > > Carlos Rovira > > > > https://na01.safelinks.protection.outlook.com/?url= > > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui% > > 40adobe.com% > > > 7Cbbb82e5ac5e34921bfe908d5bf09044e% > 7Cfa7b1b5a7b34438794aed2c178de > > > cee1%7C0%7C0%7C636624967805497091&sdata= > > bdXVzZzjutIIwP9lWwAjosfP3JsQDt > > > rkTp%2FcrETCLE4%3D&reserved=0 > > > > > > > > > > > > > > > > > > -- > > Carlos Rovira > > https://na01.safelinks.protection.outlook.com/?url= > > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui% > 40adobe.com% > > 7C7fb72469866647e4264108d5bf46fcb5%7Cfa7b1b5a7b34438794aed2c178de > > cee1%7C0%7C0%7C636625234021648344&sdata=VP%2BrBk%2FGm2iYVLGKZBb5W% > > 2FSAPKFpD763hkpcXbTjPkA%3D&reserved=0 > > > > > > > > > -- > Carlos Rovira > https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C956be5c671194d88bc2d08d5c037a842%7Cfa7b1b5a7b34438794aed2c178de > cee1%7C0%7C0%7C636626267659136456&sdata=Uakuu2OcNqkYSLgx1FOqFUC75funWJ > 1gZgN5pEPjzs4%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
