Bump.
> On Feb 1, 2019, at 8:36 AM, Harbs <harbs.li...@gmail.com> wrote:
>
> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2b4ced1196f39150a85b0cd61bbb338dL64
>
> <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2b4ced1196f39150a85b0cd61bbb338dL64>https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-1579cf5aa28be79326d96804b8ff5b85R95
>
> <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-1579cf5aa28be79326d96804b8ff5b85R95>
> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-7b616cac43f87537a5c667f91f1b332fR54
>
> <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-7b616cac43f87537a5c667f91f1b332fR54>
>
> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-75385354048a329d33d5708f25f4befdR41
>
> <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-75385354048a329d33d5708f25f4befdR41>
> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84
>
> <https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84>
>
>> On Feb 1, 2019, at 12:06 AM, Carlos Rovira <carlosrov...@apache.org
>> <mailto:carlosrov...@apache.org>> wrote:
>>
>> Sorry Harbs,
>> very busy this days. Very interested in take a look. Just one question. A
>> part from the implementation did you commit some example of use, so I can
>> differentiate clearly the code that is using this notification system
>>
>> thanks!
>>
>> El jue., 31 ene. 2019 a las 18:04, Alex Harui (<aha...@adobe.com.invalid
>> <mailto:aha...@adobe.com.invalid>>)
>> escribió:
>>
>>> I hope to look at this on the weekend.
>>>
>>> -Alex
>>>
>>> On 1/31/19, 4:17 AM, "Harbs" <harbs.li...@gmail.com
>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>
>>> Bump.
>>>
>>> Anyone have opinions on this?
>>>
>>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.li...@gmail.com
>>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>
>>>> I implemented the basics of my idea here:
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=2cEb3AFiH0Y31i0z0FFDHVGYJFzBlOJDMBoDME7w5F8%3D&reserved=0
>>>
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=2cEb3AFiH0Y31i0z0FFDHVGYJFzBlOJDMBoDME7w5F8%3D&reserved=0>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=2cEb3AFiH0Y31i0z0FFDHVGYJFzBlOJDMBoDME7w5F8%3D&reserved=0
>>>>
>>>>
>>>> I got my inspiration from PureMVC.
>>>>
>>>> I only made enough changes to get rid of compiler errors in Core.
>>> There’s still a lot of work I’d need to do to make it functional, but you
>>> should be able to see the architecture from that commit.
>>>>
>>>> Basically I added to IBead:
>>>>
>>>> listInterests() which allows the strand to extract from a bead what
>>> notifications it wants and:
>>>> handleNotification() where the strand sends the notification to the
>>> bead.
>>>>
>>>> Strand got notify() and sendNotification().
>>>>
>>>> Those two methods should replace virtually every use of
>>> dispatchEvent() currently being used except when it’s a legitimate event.
>>>>
>>>> Clean addition and removal of beads is actually already implemented
>>> in my POC. Check out the utility functions in org.apache.royale.utils.beads
>>>>
>>>> What do folks think?
>>>> Harbs
>>>>
>>>>> On Jan 29, 2019, at 2:10 PM, Carlos Rovira <carlosrov...@apache.org
>>> <mailto:carlosrov...@apache.org>> wrote:
>>>>>
>>>>> That sounds good Harbs,
>>>>> you could that of if you want to save some effort, first make a new
>>> email
>>>>> thread with some example of code on how this would look in the end,
>>> so we
>>>>> all can understand it and provide some feedback so your effort
>>> could be
>>>>> more easy in the end.
>>>>>
>>>>> El lun., 28 ene. 2019 a las 17:26, Harbs (<harbs.li...@gmail.com
>>> <mailto:harbs.li...@gmail.com>>) escribió:
>>>>>
>>>>>> Good point.
>>>>>>
>>>>>> If we would implement my idea of notifications, we could use
>>> utility
>>>>>> functions to clean out beads.
>>>>>>
>>>>>> If anyone is interested in this direction, I can write an
>>> implementation
>>>>>> in a branch to show what I’m talking about…
>>>>>>
>>>>>> Harbs
>>>>>>
>>>>>>> On Jan 28, 2019, at 6:22 PM, Alex Harui <aha...@adobe.com.INVALID
>>> <mailto:aha...@adobe.com.INVALID>>
>>>>>> wrote:
>>>>>>>
>>>>>>> It is fine to have a utility function such as this, but IMO, it
>>> doesn't
>>>>>> actually solve the problem. If the original bead does not know
>>> how to
>>>>>> remove itself, then a version of that bead needs to be created
>>> that does
>>>>>> know how to remove itself. While we could add replaceable
>>> versions of
>>>>>> every bead, that would flood the documentation and
>>> code-intelligence
>>>>>> eventually.
>>>>>>>
>>>>>>> Replacing beads should be a rare occurrence and the APIs should
>>> indicate
>>>>>> that. I guess I am not making myself clear, but every time I say
>>> we are
>>>>>> going to remove "removeBead" I always say that there will be a
>>> utility
>>>>>> function to do it and then someone responds with "hey we still
>>> need a way
>>>>>> to do this". That way is the utility function.
>>>>>>>
>>>>>>> It might turn out that there is a way to write most beads in a
>>> way that
>>>>>> another bead can clean it up. That requires making event handlers
>>> public
>>>>>> instead of private/protected, which isn't my favorite idea since
>>> it also
>>>>>> clutters code-intelligence and documentation.
>>>>>>>
>>>>>>> One other idea along these lines that I've never tried is a
>>> "splitter
>>>>>> bead". In electronics and elsewhere, a splitter allows one plug
>>> to plug in
>>>>>> two things, with an optional switch. So a LayoutSplitterBead
>>> (which is
>>>>>> also a strand) would allow both a HorizontalLayout and
>>> VerticalLayout to be
>>>>>> on its strand, and have some flag that switches which layout is in
>>> play by
>>>>>> redirecting calls to one of the two beads.
>>>>>>>
>>>>>>> HTH,
>>>>>>> -Alex
>>>>>>>
>>>>>>> On 1/28/19, 2:57 AM, "Carlos Rovira" <carlosrov...@apache.org
>>> <mailto:carlosrov...@apache.org> <mailto:
>>>>>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>>> wrote:
>>>>>>>
>>>>>>> Hi Harbs
>>>>>>>
>>>>>>> this seems to me the right way to go.
>>>>>>>
>>>>>>> In the current case, I think Jewel should not know about how to
>>> clean
>>>>>>> itself since is not PAYG. So Piotr should subclass the bead and
>>> add
>>>>>> the
>>>>>>> clean up functionality an configure as default in this project.
>>> Then
>>>>>> use
>>>>>>> your replaceBead to do the change
>>>>>>>
>>>>>>> thanks all for taking a look, I think we got it :)
>>>>>>>
>>>>>>> @Piotr solves that your problem?
>>>>>>>
>>>>>>> Carlos
>>>>>>>
>>>>>>>
>>>>>>> El lun., 28 ene. 2019 a las 11:20, Harbs (<
>>> harbs.li...@gmail.com <mailto:harbs.li...@gmail.com>>)
>>>>>> escribió:
>>>>>>>
>>>>>>>> I just added a utility function for this.
>>>>>>>>
>>>>>>>> I thought of checking to see if the bead has a beadRemoved()
>>> method and
>>>>>>>> conditionally calling that, but it seemed not PAYG and hacky.
>>>>>>>>
>>>>>>>> My thoughts are to use this like so:
>>>>>>>>
>>>>>>>> var removedBead:MyBeadThatKnowsHowToCleaupAfterItself =
>>>>>>>> replaceBead(strand, newBead,ILayoutBead);
>>>>>>>> if(removedBead)removedBead.cleanup();
>>>>>>>>
>>>>>>>>> On Jan 28, 2019, at 12:06 PM, Harbs <harbs.li...@gmail.com
>>> <mailto:harbs.li...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> I mentioned a long time ago that I really want to implement a
>>>>>>>> notification system for strands and beads. I’ve always felt that
>>> events
>>>>>> are
>>>>>>>> kind of hacky.
>>>>>>>>>
>>>>>>>>> I would require a little bit of scaffolding for the
>>> notifications so
>>>>>>>> it’s not truly PAYG, but the notifications could really be plug
>>> and
>>>>>> play. I
>>>>>>>> think the net result would be less code as opposed to the current
>>>>>> system of
>>>>>>>> sending events.
>>>>>>>>>
>>>>>>>>> For this case, I think a replaceBead() utility function would
>>> probably
>>>>>>>> do the trick.
>>>>>>>>>
>>>>>>>>>> On Jan 28, 2019, at 10:38 AM, Carlos Rovira <
>>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> HI Alex
>>>>>>>>>>
>>>>>>>>>> mostly agree with your thoughts. Just some points:
>>>>>>>>>>
>>>>>>>>>> * While I think beads should be "instantiation time", don't
>>> agree with
>>>>>>>>>> wanting to remove the "removeBead" method. We're a framework,
>>> and
>>>>>> people
>>>>>>>>>> will find this problem. So is difficult to explain the we
>>> don't have
>>>>>> any
>>>>>>>>>> way to do this
>>>>>>>>>> * In the other hand, I think we should have as you proposed in
>>> your
>>>>>>>>>> response, some utility function to handle this, so people
>>> could manage
>>>>>>>> it
>>>>>>>>>> in this strange case.
>>>>>>>>>>
>>>>>>>>>> So, finally, I think Piotr, should create a class function or
>>>>>> something
>>>>>>>>>> like this. If he can do something generalist, that could go to
>>> our
>>>>>>>> repo, if
>>>>>>>>>> is something more tied to his code, that should go to his
>>> codebase.
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> El lun., 28 ene. 2019 a las 6:40, Alex Harui
>>>>>> (<aha...@adobe.com.invalid <mailto:aha...@adobe.com.invalid>
>>>>>>>>> )
>>>>>>>>>> escribió:
>>>>>>>>>>
>>>>>>>>>>> I know there have been other responses, but I think this
>>> original
>>>>>> post
>>>>>>>> is
>>>>>>>>>>> the best place for my response.
>>>>>>>>>>>
>>>>>>>>>>> IMO, sealed classes are another safety/security measure.
>>> Changing
>>>>>> the
>>>>>>>>>>> code in a class at runtime invites opportunities for hacking
>>> that are
>>>>>>>>>>> really hard to detect. The set of beads assigned to a strand
>>> would
>>>>>> be
>>>>>>>>>>> instantiated in the constructor if we could do it that early,
>>> but we
>>>>>>>> want
>>>>>>>>>>> to allow someone to declare options/overrides of default
>>> behavior and
>>>>>>>> the
>>>>>>>>>>> only practical way to do it is to wait a bit. But once the
>>>>>>>> instantiation
>>>>>>>>>>> lifecycle is over, you really should be able to examine what
>>> the
>>>>>>>> instance
>>>>>>>>>>> is composed of. It shouldn't change later. Later changes
>>> create
>>>>>> all
>>>>>>>>>>> kinds of havoc for code coverage tools, debugging, and other
>>>>>>>> productivity
>>>>>>>>>>> issues.
>>>>>>>>>>>
>>>>>>>>>>> So, IMO, it is best to try to make the composition of an
>>> instance
>>>>>>>>>>> declarable at author-time. If you need to specify something
>>> for an
>>>>>>>> inner
>>>>>>>>>>> child, we have ways of doing that. ItemRenderers specify the
>>> inner
>>>>>>>>>>> children of a list. A Panel's TitleBar can be swapped for a
>>>>>> different
>>>>>>>>>>> titlebar. If you want a component that can switch between
>>> laying out
>>>>>>>>>>> horizontally and vertically, you could use states or other
>>> techniques
>>>>>>>> to
>>>>>>>>>>> swap between a child with HorizonalLayout and a child with
>>>>>>>> VerticalLayout,
>>>>>>>>>>> but changing a single child's beads at runtime is not a best
>>>>>>>> practice. You
>>>>>>>>>>> could also create a VerticalOrHorizontalLayout bead. All of
>>> these
>>>>>>>>>>> techniques make it easier to see at author-time what the
>>> pieces are.
>>>>>>>> That
>>>>>>>>>>> way, when debugging into the child where the MXML/CSS said
>>>>>>>> HorizontalLayout
>>>>>>>>>>> and you see a VerticalLayout, you are less likely to be
>>> surprised
>>>>>> and
>>>>>>>>>>> think there is a bug in the layout assignment when there
>>> isn't.
>>>>>>>>>>>
>>>>>>>>>>> And thus, because of PAYG, none of our existing beads carry
>>> code
>>>>>>>> around to
>>>>>>>>>>> cleanup if removed from the strand, and I've mentioned
>>> recently that
>>>>>> I
>>>>>>>>>>> seriously considering we should take removeBead out of
>>> IStrand and
>>>>>>>> UIBase.
>>>>>>>>>>> However, I agree with whoever responded that we shouldn't
>>> block bead
>>>>>>>>>>> removal. We should just make it a truly rare occurrence.
>>> Somebody,
>>>>>>>> some
>>>>>>>>>>> day, will come up with a rare reason to need it. But they
>>> will need
>>>>>>>> to use
>>>>>>>>>>> beads that carry extra code that does the clean up and call
>>> some
>>>>>>>> utility
>>>>>>>>>>> function that removes the bead from the strand.
>>>>>>>>>>>
>>>>>>>>>>> So, I don't fully understand this scenario and am too
>>> backlogged to
>>>>>>>> really
>>>>>>>>>>> dig through it, but please first attempt to find patterns
>>> that allow
>>>>>>>>>>> specification of the children and their layout at
>>> author-time. Think
>>>>>>>> of
>>>>>>>>>>> beads as an instantiation-time composition of a class
>>> instance. Then
>>>>>>>>>>> consider beads that can go "both ways". Then consider beads
>>> that can
>>>>>>>> be
>>>>>>>>>>> removed. But for PAYG reasons, we don't want to have all
>>> beads know
>>>>>>>> how to
>>>>>>>>>>> be removed.
>>>>>>>>>>>
>>>>>>>>>>> My 2 cents,
>>>>>>>>>>> -Alex
>>>>>>>>>>>
>>>>>>>>>>> On 1/27/19, 12:26 AM, "Carlos Rovira" <
>>> carlosrov...@apache.org <mailto:carlosrov...@apache.org>>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> Piotr and I found a situation where we don't know how to
>>> solve with
>>>>>>>>>>> some
>>>>>>>>>>> generalist solution. Hope others here could give some ideas.
>>>>>>>>>>>
>>>>>>>>>>> The setup: We have a layout bead that decorates the strand
>>> with a
>>>>>> css
>>>>>>>>>>> class
>>>>>>>>>>> selector. The bead is configured in CSS as a default bead
>>>>>>>>>>>
>>>>>>>>>>> The problem: We found that adding another layout bead at
>>> runtime
>>>>>> that
>>>>>>>>>>> "substitute" the default bead and adds other CSS class
>>> selector,
>>>>>> left
>>>>>>>>>>> the
>>>>>>>>>>> selector(s) from the old layout bead untouched.
>>>>>>>>>>>
>>>>>>>>>>> Notice that adding the new layout bead in MXML through beads
>>> array
>>>>>> is
>>>>>>>>>>> ok,
>>>>>>>>>>> since (I think) default bead is never instantiated and the
>>> second
>>>>>> one
>>>>>>>>>>> is
>>>>>>>>>>> the only one running its code. The problem happens if we try
>>> to do
>>>>>>>> the
>>>>>>>>>>> change at runtime at a later time.
>>>>>>>>>>>
>>>>>>>>>>> So, our question is: How to deal with beads that are already
>>>>>>>>>>> instantiated
>>>>>>>>>>> and needs to be removed. How we should operate with it?
>>> Should be
>>>>>>>> have
>>>>>>>>>>> some
>>>>>>>>>>> removal mechanism in Royale to do this?
>>>>>>>>>>>
>>>>>>>>>>> For more info and code about this issue, Piotr shared some
>>> source
>>>>>>>> code
>>>>>>>>>>> in
>>>>>>>>>>> other recent thread about Jewel Group.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Carlos Rovira
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cfb012802edf24182500708d687760032%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636845338238445672&sdata=ZR2VesdgNq80z88EeTEk35wd5rhqlDmXMD3Z37Qro1U%3D&reserved=0
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> http://about.me/carlosrovira <http://about.me/carlosrovira>
>
