Hi Carlos,
I took a quick look.
1) I don't see how if the user did:
myComp.className = "Carlos";
myComp.className = "";
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.
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.
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.
Of course, I could be missing something...
-Alex
On 3/13/18, 10:30 AM, "carlos.rov...@gmail.com on behalf of Carlos Rovira"
<carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> 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 <aha...@adobe.com.invalid>:
>
>> 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, "carlos.rov...@gmail.com on behalf of Carlos
>>Rovira"
>> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> wrote:
>>
>> >Hi Alex,
>> >
>> >2018-03-13 17:50 GMT+01:00 Alex Harui <aha...@adobe.com.invalid>:
>> >
>> >> 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, "carlos.rov...@gmail.com on behalf of Carlos
>> >>Rovira"
>> >> <carlos.rov...@gmail.com on behalf of carlosrov...@apache.org> 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 <harbs.li...@gmail.com>:
>> >> >
>> >> >> className in Royale == class in HTML.
>> >> >>
>> >> >> > On Mar 13, 2018, at 2:55 PM, Carlos Rovira
>> >><carlosrov...@apache.org>
>> >> >> 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 <harbs.li...@gmail.com>:
>> >> >> >
>> >> >> >> 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
>> >><carlosrov...@apache.org
>> >> >
>> >> >> >> 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
>> >><carlosrov...@apache.org>:
>> >> >> >>>
>> >> >> >>>> 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
>> >> >><piotrzarzyck...@gmail.com
>> >> >> >:
>> >> >> >>>>
>> >> >> >>>>> In my example orders matters. Setup first className than
>>your
>> >> >> property.
>> >> >> >>>>>
>> >> >> >>>>>
>> >> >> >>>>> On Tue, Mar 13, 2018, 12:39 Harbs <harbs.li...@gmail.com>
>> >>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 <
>> >> >> carlosrov...@apache.org>
>> >> >> >>>>>> 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 <
>> >> >> piotrzarzyck...@gmail.com
>> >> >> >>>>>> :
>> >> >> >>>>>>>
>> >> >> >>>>>>>> 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 <
>> >> >> >>>>> piotrzarzyck...@gmail.com>
>> >> >> >>>>>>>> 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 <
>> >> >> carlosrov...@apache.org
>> >> >> >>> :
>> >> >> >>>>>>>>>
>> >> >> >>>>>>>>>> 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
>><harbs.li...@gmail.com>:
>> >> >> >>>>>>>>>>
>> >> >> >>>>>>>>>>> +1.
>> >> >> >>>>>>>>>>>
>> >> >> >>>>>>>>>>>> On Mar 13, 2018, at 10:08 AM, Alex Harui
>> >> >> >>>>> <aha...@adobe.com.INVALID>
>> >> >> >>>>>>>>>>> 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
