Hi Alex, 2018-03-13 19:20 GMT+01:00 Alex Harui <[email protected]>:
> Hi Carlos, > > I took a quick look. > > 1) I don't see how if the user did: > > myComp.className = "Carlos"; > myComp.className = ""; > > Right this case is missing, we need to add it, but seems simple since is deal with value == "" > That 'Carlos' would be removed from the classList. > > 2) I still don't like that we are calling split and apply on classList > even for simple assignment of a single className > > 3) I don't like that as we aggregate typeNames that we will reset > className to "" and call split more than once. Not to mention the > overhead of the extra function calls now that typeNames is not a var and > now a getter/setter. > ok > > > That said, I also took another look at the Basic UIBase code and don't > like it either. Seems like it could be optimized as well and have > setClassName call computeFinalClassNames. > > Regarding performance. I think the key issue is that every change to > element.className or element.classList can cause a DOM update, so you > don't want to change element.className or element.classList more than once > during the initialization of the component. I didn't watch the videos you > linked to, but in the first link to a blog post, that person was just > replacing a one-time setting of className to a string with a call to > classList.add. But his code is probably pre-parsed into the parameter > list to classList.add. We have to compute it from a String.split. And > the current code you have proposed is going to change classList several > times as we aggregate typeNames. That doesn't seem right. > I think the video is short and explained very well. I think is good to review it But I think is ok to change my code to get a better performant one. Mine was created only to see it works, now we need to tune depending on the different entry points as you say > If you want to use classList everywhere, I think we'd have to shadow it > with an array so we only set the array of strings on classList as needed, > but classList isn't set up to do a full replacement, AFAICT. > > IMO, if you want to continue to pursue use of classList, you would focus > on just replacing computeFinalClassNames and/or setClassName with > classList handling and see how it looks. Leave typeNames as a var and let > it aggregate without touching classList. UIBase will eventually call > setClassName in addedToParent. That is the point in the lifecycle where > the user might have set some classNames and the typeNames have been > aggregated and maybe "fab" or "primary" has been set as well. Either you > track everything in a shadow array or you do one big split then. > > Do we know if you set className then read classList, doesn't classList > represent the things set in className? If that's the case, then in > MDL/Jewel, "fab" and "primary" should just check to see if addedToParent > has been called and the classNames/classList has been stuffed and if it > has, just call classList.toggle. > > However, IMO, the simplest solution should be to leave UIBase as is. MDL > and Jewel should just have to override computeFinalClassNames to include > adding "fab"/"primary" to the final set of strings. I don't understand > why other work would be needed. But the "fab"/"primary" getter setters > should be able to call classList.toggle instead of computeFinalClassNames > and/or setClassName. > > If you want to separately prove that it is faster to call String.split() > and set classList instead of passing the space-delimited strings to > className, that's fine too. The difference for us vs the link you posted > is that we MUST start with space-delimited strings coming from the MXML, > so at least one split() call is required. > I spend some hours trying and * change typeNames to only one var again, then in addToParent I reset the className, I think this solves the problem of using typeNames lots of times and call split and apply lots of times * I tried to create again a computedFinalClassNames to handle classList. * The only problem I see is that if don't see any way to avoid call split and apply each time you call setClassName since a compute final is needed. Or I'm missing something? Maybe could be good that you write some code (pseudo code) here better to explain what you propose since I don't know if I'm understanding your phrases accurately It's time for me to go to sleep, tomorrow I'll check if you posted something to try it thanks! > > Of course, I could be missing something... > -Alex > > On 3/13/18, 10:30 AM, "[email protected] on behalf of Carlos Rovira" > <[email protected] on behalf of [email protected]> wrote: > > >Hi Alex, > > > >right, I tested it in JewelExample. If you find something that does not > >conform to what you thinked please let me know to address it. > >I think it should not be very difficult to handle some isolated case with > >what we have > > > >thanks > > > > > > > >2018-03-13 18:24 GMT+01:00 Alex Harui <[email protected]>: > > > >> Hi Carlos, > >> > >> Just so I'm clear, you believe that UIBase.as in the jewel-ui-set branch > >> addresses all of these issues? I've just been watching commits, so if > >>you > >> think that's the case then I will look at the current state of your > >>UIBase. > >> > >> Thanks, > >> -Alex > >> > >> On 3/13/18, 10:14 AM, "[email protected] on behalf of Carlos > >>Rovira" > >> <[email protected] on behalf of [email protected]> wrote: > >> > >> >Hi Alex, > >> > > >> >2018-03-13 17:50 GMT+01:00 Alex Harui <[email protected]>: > >> > > >> >> Hi Carlos, > >> >> > >> >> I do not think you are considering all of the scenarios in your > >>proposed > >> >> code. I'm sad that I have to delineate them again, but I will try. > >> >> > >> >> 1) In Basic there are two sets of strings: The fixed set from > >>typeNames > >> >> that should "never" change. And the className set from the user that > >> >>can > >> >> not only add, but also remove a set of HTML classes. > >> >> > >> >> > >> >I see the next email so I respond to this in the following, I solved > >>that > >> >and explain later > >> > > >> > > >> >> 2) In MDL and I guess Jewel, there is a third set. They are tied to > >> >> properties like you said. "fab" and "primary", and things like that. > >> >> > >> > > >> >Yes this will be the normal case in users. People using Jewel or other > >>UI > >> >set with look and feel will > >> >use properties as their normal basis in the same way they do now in MDL > >> > > >> > > >> >> > >> >> 3) For PAYG reasons, it would be great if Basic did not have to > >> >> contemplate the third set. > >> >> > >> >> 4) For PAYG reasons, it would be nice if Basic did not have to assume > >> >> conversion to array and call split(). The current code in the > >>develop > >> >> branch lets the browser do the split() in native code. > >> >> > >> > > >> >for 3 and 4 what's the best way to left UIBase untouched so I can use > >>my > >> >code in Jewel? > >> >Is the actual way of duplicating the code for UIBase in my own library > >>the > >> >best way? > >> > > >> > > >> >> > >> >> Then, as a performance consideration, Harbs claims that changing > >> >>classList > >> >> is expensive. > >> >> > >> > > >> >I don't will say that there's a low performance, but my guess is that > >>is > >> >nothing that we should have in consideration, but we can discuss it > >>later. > >> > > >> > > >> >> > >> >> So, your proposed solution MUST allow the user to delete/remove any > >> >> strings they added without removing strings added from typeNames or > >>from > >> >> the "fab"/"primary" properties. > >> > > >> > > >> >That's now working > >> > > >> > > >> >> And allow add/remove of the user's > >> >> strings before or after changing properties like "fab" and "primary". > >> >> > >> > > >> >as we are dealing with a collection this is working and only one copy > >>of > >> >the string is maintained and outputted, I think in this way > >> >less errors of this kind should happen > >> > > >> > > >> >> > >> >> Show us how that will work. I'm pretty sure it is possible. Then we > >> >>will > >> >> debate the performance aspects. > >> >> > >> > > >> >I have it right now completely working in my branch, so it's a matter > >>to > >> >try it in JewelExample > >> > > >> > > >> >> > >> >> Thanks, > >> >> -Alex > >> >> > >> >> On 3/13/18, 6:49 AM, "[email protected] on behalf of Carlos > >> >>Rovira" > >> >> <[email protected] on behalf of [email protected]> > wrote: > >> >> > >> >> >So, you if is == you expect that setting className in royale you > >>remove > >> >> >all > >> >> >inclusive typeNames? > >> >> >Harbs, className is not equal to class in HTML > >> >> > > >> >> >2018-03-13 14:08 GMT+01:00 Harbs <[email protected]>: > >> >> > > >> >> >> className in Royale == class in HTML. > >> >> >> > >> >> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira > >> >><[email protected]> > >> >> >> wrote: > >> >> >> > > >> >> >> > I think we're getting to the point in this discussion. > >> >> >> > > >> >> >> > For me as a user, I expect to use className property to "add", > >>and > >> >>not > >> >> >> > override all I have > >> >> >> > for that reason in MDL and now in Royale we decided to create > >> >> >>properties > >> >> >> > (that use to be boolean) like "primary" or in MDL "fab" to add > >>or > >> >> >>remove > >> >> >> > those properties (since are library properties that are managed > >> >> >> > specifically). > >> >> >> > I don't want to set primary and then className removes that! I > >> >>think > >> >> >>that > >> >> >> > function is not right and will be the cause of many problems. > >> >> >> > > >> >> >> > If the user wants to remove all class names, he can do with a > >> >>method > >> >> >>that > >> >> >> > callls element.classList.remove, but the behavior by default > >> >> >>shouldn't be > >> >> >> > to use className to get rid of all what we have. > >> >> >> > > >> >> >> > If you work with html directly , is normal to write > >>class="class1 > >> >> >>class2 > >> >> >> > ..." and create from scratch > >> >> >> > > >> >> >> > in Royale you write mxml and as3 and use className to add > >> >>additional > >> >> >> > classes that are not in the api but not to remove the ones the > >> >> >>component > >> >> >> > set plus the ones the user "switched" on/off due to properties > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > 2018-03-13 13:42 GMT+01:00 Harbs <[email protected]>: > >> >> >> > > >> >> >> >> No. className is supposed to *replace* the entire classList > >>minus > >> >>the > >> >> >> >> internally managed ones (i.e. typeNames). Your code drastically > >> >> >>changes > >> >> >> the > >> >> >> >> current behavior. > >> >> >> >> > >> >> >> >> You cannot use add for that and replacing the classList will > >> >>destroy > >> >> >> your > >> >> >> >> custom class names. > >> >> >> >> > >> >> >> >>> On Mar 13, 2018, at 2:34 PM, Carlos Rovira > >> >><[email protected] > >> >> > > >> >> >> >> wrote: > >> >> >> >>> > >> >> >> >>> Solving the multiple string value problem: > >> >> >> >>> > >> >> >> >>> This: <j:TextButton text="PRIMARY" className="myCustomStyle > >>some > >> >> >>other" > >> >> >> >>> primary="true"/> > >> >> >> >>> > >> >> >> >>> *<button type="button" class="jewel button textbutton > >> >>myCustomStyle > >> >> >> some > >> >> >> >>> other primary" style="margin: 10px 0px 0px; display: > >> >> >> >>> block;">PRIMARY</button>* > >> >> >> >>> > >> >> >> >>> with this change > >> >> >> >>> > >> >> >> >>> COMPILE::JS > >> >> >> >>> protected function setClassName(value:String):void > >> >> >> >>> { > >> >> >> >>> var classes:Array = value.split(" "); > >> >> >> >>> element.classList.add.apply(element.classList, classes); > >> >> >> >>> } > >> >> >> >>> > >> >> >> >>> I think this was all the problems we have right? > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> 2018-03-13 13:20 GMT+01:00 Carlos Rovira > >> >><[email protected]>: > >> >> >> >>> > >> >> >> >>>> Hi Piotr, > >> >> >> >>>> > >> >> >> >>>> that's one of the advantages of a collection, order doesn't > >> >> >>matter! :) > >> >> >> >>>> > >> >> >> >>>> <j:TextButton text="PRIMARY" className="myCustomStyle" > >> >> >> primary="true"/> > >> >> >> >>>> > >> >> >> >>>> output: > >> >> >> >>>> > >> >> >> >>>> *<button type="button" class="jewel button textbutton > >> >>myCustomStyle > >> >> >> >>>> primary" style="margin: 10px 0px 0px; display: > >> >> >> block;">PRIMARY</button>* > >> >> >> >>>> > >> >> >> >>>> this is one of the reason to change, since you'll end trying > >>to > >> >> >>figure > >> >> >> >>>> what comes in first or not. > >> >> >> >>>> > >> >> >> >>>> Do you need more evidence? > >> >> >> >>>> > >> >> >> >>>> Thanks > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> 2018-03-13 12:48 GMT+01:00 Piotr Zarzycki > >> >> >><[email protected] > >> >> >> >: > >> >> >> >>>> > >> >> >> >>>>> In my example orders matters. Setup first className than > >>your > >> >> >> property. > >> >> >> >>>>> > >> >> >> >>>>> > >> >> >> >>>>> On Tue, Mar 13, 2018, 12:39 Harbs <[email protected]> > >> >>wrote: > >> >> >> >>>>> > >> >> >> >>>>>> Hi Carlos, > >> >> >> >>>>>> > >> >> >> >>>>>> I definitely appreciate the work you are doing. I’m swamped > >> >>with > >> >> >> work > >> >> >> >>>>>> right now, so I don’t have the time to spend helping you. > >> >>(Sorry > >> >> >> about > >> >> >> >>>>>> that.) :-( > >> >> >> >>>>>> > >> >> >> >>>>>> I think the discussions here are about pretty minor points. > >> >>You > >> >> >>can > >> >> >> >>>>>> certainly implement jewel how you think makes sense, but if > >> >>you > >> >> >>want > >> >> >> >> to > >> >> >> >>>>>> make changes to basic in areas which are not broken, there > >> >>needs > >> >> >>to > >> >> >> >> be a > >> >> >> >>>>>> really good reason to do so. > >> >> >> >>>>>> > >> >> >> >>>>>> My $0.02, > >> >> >> >>>>>> Harbs > >> >> >> >>>>>>> On Mar 13, 2018, at 1:31 PM, Carlos Rovira < > >> >> >> [email protected]> > >> >> >> >>>>>> wrote: > >> >> >> >>>>>>> > >> >> >> >>>>>>> Hi Piotr, > >> >> >> >>>>>>> > >> >> >> >>>>>>> thanks for your words, but is difficult to work on > >>something > >> >> >>when > >> >> >> you > >> >> >> >>>>>>> believe in your vision and others no, and more over when > >>all > >> >>the > >> >> >> >> facts > >> >> >> >>>>>> you > >> >> >> >>>>>>> see corroborates that vision. It's difficult to maintain > >>live > >> >> >>the > >> >> >> >>>>> moto in > >> >> >> >>>>>>> that scenario. > >> >> >> >>>>>>> > >> >> >> >>>>>>> but anyway for you Kindly words > >> >> >> >>>>>>> > >> >> >> >>>>>>> Carlos > >> >> >> >>>>>>> > >> >> >> >>>>>>> > >> >> >> >>>>>>> 2018-03-13 12:21 GMT+01:00 Piotr Zarzycki < > >> >> >> [email protected] > >> >> >> >>>>>> : > >> >> >> >>>>>>> > >> >> >> >>>>>>>> Carlos, > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> In my opinion you are not facing the wall from US. You > >>are > >> >> >>facing > >> >> >> >> the > >> >> >> >>>>>> wall > >> >> >> >>>>>>>> from lack of volounteers who can help, do the job. > >> >> >> >>>>>>>> Believe me your Jewel effort in my list of tasks is > >>almost > >> >>on > >> >> >>the > >> >> >> >>>>> Top. I > >> >> >> >>>>>>>> have to fiinish planned work in TranspiledActionScript > >>first > >> >> >>and I > >> >> >> >>>>> hope > >> >> >> >>>>>> to > >> >> >> >>>>>>>> join. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> When it will be - maybe in couple of weeks. In the end > >> >> >>something > >> >> >> >>>>> have to > >> >> >> >>>>>>>> pay the bills and Royale is only fraction of that. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> I contribute in other related areas. I Wish I could > >> >>contribute > >> >> >>in > >> >> >> >>>>> your > >> >> >> >>>>>> way > >> >> >> >>>>>>>> or Alex and Peter. > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> Thanks for your work! > >> >> >> >>>>>>>> Piotr > >> >> >> >>>>>>>> > >> >> >> >>>>>>>> On Tue, Mar 13, 2018, 12:00 Piotr Zarzycki < > >> >> >> >>>>> [email protected]> > >> >> >> >>>>>>>> wrote: > >> >> >> >>>>>>>> > >> >> >> >>>>>>>>> I personally said - Go and try, report back. I have gave > >> >>you > >> >> >>an > >> >> >> >> real > >> >> >> >>>>>>>> world > >> >> >> >>>>>>>>> examples where classList failed. Try and post the > >>results. > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> 2018-03-13 11:49 GMT+01:00 Carlos Rovira < > >> >> >> [email protected] > >> >> >> >>> : > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>>> Hi, > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> it's very hard to me to invest lot of time both in > >>tryin > >> >>to > >> >> >> >> develop > >> >> >> >>>>>>>>>> something useful in the look and feel field for us > >>where > >> >>no > >> >> >> other > >> >> >> >>>>> is > >> >> >> >>>>>>>> doing > >> >> >> >>>>>>>>>> work, trying to explain and discuss all issues I find > >> >>without > >> >> >> get > >> >> >> >>>>> any > >> >> >> >>>>>>>>>> traction. It's like to face a wall all the time. > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> Maybe I'm wrong with my proposals but other times my > >> >> >>perception > >> >> >> is > >> >> >> >>>>>> that > >> >> >> >>>>>>>>>> things are settled in a particular way > >> >> >> >>>>>>>>>> and we don't want to change it since is working in the > >> >> >>current > >> >> >> >>>>> state. > >> >> >> >>>>>>>> But > >> >> >> >>>>>>>>>> I > >> >> >> >>>>>>>>>> think we always where thinking of change things as we > >> >>evolve > >> >> >> >>>>> Royale. > >> >> >> >>>>>>>> We're > >> >> >> >>>>>>>>>> in a 0.9.2 release, we're not in 1.0, but the way we're > >> >> >>managing > >> >> >> >>>>> all > >> >> >> >>>>>>>>>> issues > >> >> >> >>>>>>>>>> seems to > >> >> >> >>>>>>>>>> me that we're fine with what we have now and we are > >> >>freezing > >> >> >>the > >> >> >> >>>>> API. > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> In all the issues raised last days only CSS compiler > >> >>errors > >> >> >>are > >> >> >> >>>>> real > >> >> >> >>>>>>>> bugs, > >> >> >> >>>>>>>>>> since without that fixes royale can't output concrete > >>CSS > >> >> >>rules > >> >> >> (I > >> >> >> >>>>>> think > >> >> >> >>>>>>>>>> those not require any discussion) > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> The font injection is maybe another bug (don't know > >>why a > >> >> >>class > >> >> >> in > >> >> >> >>>>> a > >> >> >> >>>>>>>> theme > >> >> >> >>>>>>>>>> is not "visible" by the final app), but can be > >> >>workarounded > >> >> >>with > >> >> >> >> an > >> >> >> >>>>>> html > >> >> >> >>>>>>>>>> that setup the font for now. > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> Things like classNames discussion are not critical (I > >> >>know), > >> >> >> it's > >> >> >> >>>>>> just a > >> >> >> >>>>>>>>>> matter to refine the API since I had problems each > >>time I > >> >>go > >> >> >> that > >> >> >> >>>>>> path, > >> >> >> >>>>>>>>>> first with MDL and now with Jewel. Maybe I'm the only > >>one > >> >> >>since > >> >> >> no > >> >> >> >>>>>> other > >> >> >> >>>>>>>>>> has tried what I'm trying to do: Creating Themes. > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> In my opinion, give the users only a way to manage > >> >>classNames > >> >> >> vía > >> >> >> >>>>>>>> string, > >> >> >> >>>>>>>>>> is insufficient and cumbersome and deserves at a > >>minimun > >> >>some > >> >> >> API > >> >> >> >>>>>>>> methods > >> >> >> >>>>>>>>>> since is an important point in how UI is stylized, and > >>how > >> >> >> >> controls > >> >> >> >>>>>> and > >> >> >> >>>>>>>>>> objects in html can be "extended" or diferenciated > >>(Alex > >> >> >> explained > >> >> >> >>>>>> very > >> >> >> >>>>>>>>>> well the importance of this in the typenames thread). > >>So > >> >>some > >> >> >> API > >> >> >> >>>>> to > >> >> >> >>>>>>>> ease > >> >> >> >>>>>>>>>> that is for me very Wellcome since I'm doing that work, > >> >>and > >> >> >>will > >> >> >> >> be > >> >> >> >>>>>> more > >> >> >> >>>>>>>>>> users doing that work. In this point, I don't think we > >> >>should > >> >> >> >>>>> shield > >> >> >> >>>>>> us > >> >> >> >>>>>>>> in > >> >> >> >>>>>>>>>> things like PAYG or if that is a bit less performant. > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> To close and avoid having much discussion to not reach > >>to > >> >> >>some > >> >> >> >>>>>> valuable > >> >> >> >>>>>>>>>> point: I can try to go with what we have, but makes me > >> >>feel > >> >> >>not > >> >> >> >> so > >> >> >> >>>>>> good > >> >> >> >>>>>>>>>> about the continuous rejection of my proposals. As > >>well, > >> >>you > >> >> >>are > >> >> >> >>>>>> saying > >> >> >> >>>>>>>>>> that we should wait to what users demand...but I'm an > >> >>user of > >> >> >> the > >> >> >> >>>>> API, > >> >> >> >>>>>>>> and > >> >> >> >>>>>>>>>> my perception as a "zero user" seems to be not > >>valuable. > >> >> >>Since I > >> >> >> >>>>> don't > >> >> >> >>>>>>>> get > >> >> >> >>>>>>>>>> traction on this, I'll try to continue with what we > >>have > >> >>and > >> >> >> >> report > >> >> >> >>>>>> back > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> 2018-03-13 9:24 GMT+01:00 Harbs > >><[email protected]>: > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>>> +1. > >> >> >> >>>>>>>>>>> > >> >> >> >>>>>>>>>>>> On Mar 13, 2018, at 10:08 AM, Alex Harui > >> >> >> >>>>> <[email protected]> > >> >> >> >>>>>>>>>>> wrote: > >> >> >> >>>>>>>>>>>> > >> >> >> >>>>>>>>>>>> I am so sad and frustrated that we have spent so much > >> >>time > >> >> >>on > >> >> >> >>>>>>>>>> managing a > >> >> >> >>>>>>>>>>>> set of strings. I just don't think we have the > >>people > >> >> >>power > >> >> >> to > >> >> >> >>>>>>>>>> continue > >> >> >> >>>>>>>>>>>> to seek perfection until it is truly needed by a > >>user. > >> >> >> >>>>>>>>>>> > >> >> >> >>>>>>>>>>> > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>>> -- > >> >> >> >>>>>>>>>> Carlos Rovira > >> >> >> >>>>>>>>>> > >> >> >>https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me% > >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> 7Ce137bd7a9095473c2bcc08 > >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C63656545817565873 > >> >> > >>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 > >> >> >> >>>>>>>>>> > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> -- > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> Piotr Zarzycki > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>>> Patreon: > >> >> >>*https://na01.safelinks.protection.outlook.com/?url= > >> >> https%3A%2F%2Fwww.pat > >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com > >> >> %7Ce137bd7a9095 > >> >> >>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178de > >> >> cee1%7C0%7C0%7C6365654 > >> >> >>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7% > >> >> 2BiDRjzQWyG9GPG1rs2Bw%3D&rese > >> >> >>rved=0 > >> >> >> >>>>>>>>> > >> >> >><https://na01.safelinks.protection.outlook.com/?url= > >> >> https%3A%2F%2Fwww.pat > >> >> >>reon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com > >> >> %7Ce137bd7a9095 > >> >> >>473c2bcc08d588e95a01%7Cfa7b1b5a7b34438794aed2c178de > >> >> cee1%7C0%7C0%7C6365654 > >> >> >>58175658737&sdata=DNkm0Dce279Klqlmt%2BF7YV7% > >> >> 2BiDRjzQWyG9GPG1rs2Bw%3D&rese > >> >> >>rved=0>* > >> >> >> >>>>>>>>> > >> >> >> >>>>>>>> > >> >> >> >>>>>>> > >> >> >> >>>>>>> > >> >> >> >>>>>>> > >> >> >> >>>>>>> -- > >> >> >> >>>>>>> Carlos Rovira > >> >> >> >>>>>>> > >> >> >>https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me% > >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> 7Ce137bd7a9095473c2bcc08 > >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C63656545817565873 > >> >> > >>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 > >> >> >> >>>>>> > >> >> >> >>>>>> > >> >> >> >>>>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>>> -- > >> >> >> >>>> Carlos Rovira > >> >> >> >>>> > >> >> >>https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me% > >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> 7Ce137bd7a9095473c2bcc08 > >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C63656545817565873 > >> >> > >>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 > >> >> >> >>>> > >> >> >> >>>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> -- > >> >> >> >>> Carlos Rovira > >> >> >> >>> > >> >> >>https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me% > >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> 7Ce137bd7a9095473c2bcc08 > >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C63656545817565873 > >> >> > >>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > -- > >> >> >> > Carlos Rovira > >> >> >> > > >> >> >>https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me% > >> >> >>2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> 7Ce137bd7a9095473c2bcc08 > >> >> >>d588e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C63656545817565873 > >> >> > >>>>7&sdata=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 > >> >> >> > >> >> >> > >> >> > > >> >> > > >> >> >-- > >> >> >Carlos Rovira > >> >> >https://na01.safelinks.protection.outlook.com/?url= > >> >> http%3A%2F%2Fabout.me%2 > >> >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> >> 7Ce137bd7a9095473c2bcc08d5 > >> >> >88e95a01%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> >> 7C636565458175658737&s > >> >> >data=wBMX4vjDjPJZiYA8HcTGKv43mQQbQdaRXJRS%2BM5%2BO5c%3D&reserved=0 > >> >> > >> >> > >> > > >> > > >> >-- > >> >Carlos Rovira > >> >https://na01.safelinks.protection.outlook.com/?url= > >> http%3A%2F%2Fabout.me%2 > >> >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > >> 7Cce849efb1cf84ab780ae08d5 > >> >8905f78a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > >> 7C636565581091621628&s > >> >data=5bptuicHsczeSJ84dMNT8%2FFZG42Ai732OmY8QCEbgXo%3D&reserved=0 > >> > >> > > > > > >-- > >Carlos Rovira > >https://na01.safelinks.protection.outlook.com/?url= > http%3A%2F%2Fabout.me%2 > >Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com% > 7C6de99e3bf5d844c2d09508d5 > >890825d0%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0% > 7C636565590443837727&s > >data=S%2F5fMzHFvlp8PHkdA28CcWSeMvcly1YJXTmDz6l0fUM%3D&reserved=0 > > -- Carlos Rovira http://about.me/carlosrovira
