You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@royale.apache.org by Harbs <ha...@gmail.com> on 2019/02/01 06:36:26 UTC
Re: Problems dealing with bead substitution in Royale
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-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 <ca...@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 (<ah...@adobe.com.invalid>)
> escribió:
>
>> I hope to look at this on the weekend.
>>
>> -Alex
>>
>> On 1/31/19, 4:17 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> Bump.
>>
>> Anyone have opinions on this?
>>
>>> On Jan 30, 2019, at 12:47 PM, Harbs <ha...@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
>>>
>>>
>>> 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 <carlosrovira@apache.org
>> <ma...@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.lists@gmail.com
>> <ma...@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 <aharui@adobe.com.INVALID
>> <ma...@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" <carlosrovira@apache.org
>> <ma...@apache.org> <mailto:
>>>>> carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@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.lists@gmail.com
>> <ma...@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 <
>> carlosrovira@apache.org <ma...@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
>>>>> (<aharui@adobe.com.invalid <ma...@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" <
>> carlosrovira@apache.org <ma...@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
Re: Problems dealing with bead substitution in Royale
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Then this is a really bad subject line.
If you want to replace our event subsystem with true DOM events, feel free to do so. I think it is safe to do so now that we no longer have to support IE10 or older.
If, after that work has been done and bead events are still too heavy, then we can discuss some lighterweight notification system. But IMO, single "callback" subsystems are just too restrictive. You never know when someone else will want to be notified as well, even for testing, debugging, mocking or analytics.
Strands have a list of the beads, just like most parents know their children, but strands make no other assumptions about the beads. Adding something like "interests" and having the strand process the interests starts creating knowledge and assumptions and reducing flexibility, That breaks encapsulation. Plus it also messes up deferred instantiation.
Interests adds a new array to be returned from every bead. That's a lot of overhead. And there should not be any assumption that beads need to have any interests at all.
If a bead is not referencing a strand and is not in the strand's list of beads, then it isn't really a bead anymore. There can be other instances that associate themselves with other things that don't have to also try to be beads. Beads are a composition pattern for a component. Other patterns can share instances of bead-like things with other component instances. Anything shared is not a composition, it is sharing.
My 2 cents,
-Alex
On 2/21/19, 12:12 AM, "Harbs" <ha...@gmail.com> wrote:
Thanks for your thoughts.
My motivation for doing this has very little to do with removing beads. I have not been happy with the event system of strands and beads for a long time.
I’d be OK with removing removeBead from IStrand, but as it stands now, I think it makes sense to remove the notifications that are added.
Events are very heavy. I don’t know how often you’ve tried to step through code that dispatches events. It’s painful. There’s something like ten function calls just to call a function. To me, notifications make much more sense than events in the vast majority of cases. In my mind the main difference between notifications and events is that events are broadcasting to the whole world and there’s very little structure on how those events work. Notifying a bead from a strand directly makes the behavior much more predictable. Doing so requires a single lookup and normal function call (rather than a callback).
Now, it’s possible that some of the weight of event dispatching can be resolved by replacing the goog events with something else. But it still feels to me like a misuse of events. I like a much more structured approach.
I don’t understand why you think that this breaks capsulation. Strands already have a reference to their beads. Using the notification system, the lookup knows nothing about its beads other than there’s possibly an array of IBeads associated with a list of notification names. I don’t think your point in #1 is a concern because the parent does not know anything other than the fact that it contains IBeads (which it already does).
> 5) A central function with a giant switch statement, IMO, also breaks encapsulation and adds handler overhead. Think of how subclasses would override behavior in the base class. Each subclass would have its own switch statement.
For beads which only have a single notification interest, it adds no overhead. It does add some overhead on beads which are interested in more than one notification (i.e. a switch call), but it adds predictability in how Beads work. To me, that’s important. I don’t think it’s very common to have beads override other beads and handle notifications on multiple levels, but if both the superclass and subclass handle notifications, then yes, there would be conditional code in both classes.
> 6) Shared beads should be relative rare as well, but I'm not clear how this proposal helps.
Since the bead does not need to add event listeners to the strand, it does not need to track which strands it belongs to. This is probably more a problem in the event that the events need to be removed.
Also, the notification system would allow “detached” beads to work without even being added to a Strand. Some class could simply get its interest and send it notifications. This would likely make it easier to write unit tests for beads. It seems to me that notifications have *better* encapsulation than events.
Again: My main interest in this change is because I think it makes the interfaces and interactions of strands and beads cleaner and more predictable.
Thanks,
Harbs
> On Feb 21, 2019, at 7:58 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> It looks like a reasonable subsystem design, but given that we have a lot of code running just fine without this, and that bead substitution should be a very rare situation, I'm having trouble understanding why we would want to add an entire just-in-case subsystem.
>
> Asking beads for their interests breaks encapsulation. Why should the outside world know or care? Just so you can remove a bead? Some really sophisticated beads may not register all interests/event listeners at once, or dynamically figure out interests/events. Then this whole subsystem would get bigger.
>
> Regarding the benefits you listed:
> 1) Having "parent" object know about their children has led to lots of problems in Flex and Royale. Think of creationPolicy="all" and modules sticking in memory or modules not loading because the parent already contained the classes in the module because it referenced the module. It is much better to abstract the "children" away from the "parent". That principle of encapsulation allows deferred instantiation and loading.
> 2) I don't understand what indirection you are referring to.
> 3) I didn't understand this point either.
> 4) We could try again to make all strands IEventDispatcher, or see if we can teach the compiler to allow IStrand and IStrandEventDispatcher. That would be independent of this proposal.
> 5) A central function with a giant switch statement, IMO, also breaks encapsulation and adds handler overhead. Think of how subclasses would override behavior in the base class. Each subclass would have its own switch statement.
> 6) Shared beads should be relative rare as well, but I'm not clear how this proposal helps.
>
> If the main concern is trying to get a bead to clean up when removed, let's stop and try to find a PAYG way for that, not a just-in-case way for that. Let's see if we can agree on:
> 1) Should every bead be removable? I would say no.
> 2) If only certain beads need to be removable, then a separate interface with a cleanup methods should suffice.
> 3) Beads that want to have removable versions should have protected, not private event handlers. Then a subclass could add removability.
>
> IMO, the solution to removing beads is really this simple and doesn't require a whole new subsystem.
>
> There might be some good things to keep from the proposal. Maybe there should be a base class for all beads. If you want to create a branch and see if it makes HelloWorld smaller, then that would be a win. Maybe that base class can have a "host" or "eventStrand" property that implements IEventDispatcher to reduce the number of times we write "as EventDispatcher" and maybe that will also make HelloWorld smaller. Maybe there can then be a subclass of that baseclass that adds removeability, but I would rather it be added at the end of the inheritance chain otherwise folks will opt-in on it "just-in-case".
>
> I would need to understand more about why we need an entirely different callback/notification/event subsystem. There are definitely some lighterweight models out there, but we've already paid for DOM Events, and then how do folks decide which one to use.
>
> But my main objection is patterns that break encapsulation and require the parent to know about the child. Hopefully other parts of the proposal can be tweaked.
>
> My 2 cents,
> -Alex
>
> On 2/19/19, 9:31 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>
>> On Feb 19, 2019, at 5:14 PM, Carlos Rovira <ca...@apache.org> wrote:
>>
>> Hi Harbs,
>>
>> I finally could take a look at you notification system, I can intuit a
>> good idea but still need more info or explanation from you to get the
>> benefits. My questions is more about the global thinking of the
>> notification idea more than an implementation question:
>>
>> 1.- why we have tow methods "notify" and "sendNotification"? naming seems
>> refer to the same purpose right?
>
> “notify” is a convenience method which uses sendNotification. Since the vast majority of notifications do not need a payload, “notify” allows for easier sending of the notifications.
>
>> 2.- this system should be better to handle things like bead removal so the
>> bead knows how to do it, right? how this is performed? have we got a
>> cleaning method in the bead that should know how to clean itself to do this?
>
> Yes. Basically, you can ask any bead for a list of its interests, and that list is used to both add and remove bead references in the strand. The bead does not need to clean itself. A ututiliy method can completely strip a bead off a strand including all references necessary for notification. Take a look how that’s done here:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-5f2744f9620d90c13d8759c4a326e8cbR27&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710187454&sdata=Sbkys9%2Bd0%2Fa7qT5FLZKaoTy%2Bibgp24GLD3bGUUbjbRY%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-5f2744f9620d90c13d8759c4a326e8cbR27&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710187454&sdata=Sbkys9%2Bd0%2Fa7qT5FLZKaoTy%2Bibgp24GLD3bGUUbjbRY%3D&reserved=0>
>
>> 3.- what's the main point between dispatch events and notification? maybe
>> this is the main thing I want to learn here. IOW, what's the benefits or
>> what we get over the normal dispatch
>
> Benefits:
> 1. Beads do not reference the Strand at all. All references are from the Strand to the bead.
> 2. Event listeners have a lot of indirection when they are launched. It’s much easier to step through notification dispatching.
> 3. Because notifications have no callback passing, there’s less chance of memory leaks due to callback references.
> 4. Currently, the framework has countless uses of “_strand as IEventDispatcher”. This is not something I’m thrilled with. Notifications make things much cleaner.
> 5. There’s a single entry point for notifications in a bead. I think that makes things easier to grok.
> 6. I think notifications makes it cleaner to use a single bead on multiple strands (if so desired).
>
>> 4.- Do you see some drawback? or what's the flaw points we can get over the
>> traditional event dispatch system?
>
> Here’s the drawbacks that I see:
> 1. We’re adding some additional weight to strands and beads.
> 2. Some of the events that we’re dispatching are used on different beads such as “layoutNeeded” where we’re laying out children relative to their parents. Cases like that will be needed to be handled.
>
> Regarding #1. I think the additional weight is more than offset by code saved by not having to attach so many event handlers.
> Regarding #2: Events can still be used when they make sense, or maybe there’s some other way to handle layout issues. Not 100% sure on the best way to handle that problem.
>
>> Sorry, if I need more explanation, but I still trying to figure what's all
>> about. Hope with your explanation I'll see the big picture
>>
>> thanks
>>
>>
>> El mar., 19 feb. 2019 a las 12:03, Harbs (<harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>) escribió:
>>
>>> Bump.
>>>
>>>> On Feb 1, 2019, at 8:36 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710187454&sdata=NycT99fmjnIPLU%2FuWPhjYVt%2Bsd6zHkf6J%2FMNV5vkYfE%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710187454&sdata=NycT99fmjnIPLU%2FuWPhjYVt%2Bsd6zHkf6J%2FMNV5vkYfE%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=k9hpugO%2Bkk24UUD4kc40kxA%2F%2Bb2L%2F6LpO3XGol2XuiU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=k9hpugO%2Bkk24UUD4kc40kxA%2F%2Bb2L%2F6LpO3XGol2XuiU%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=k9hpugO%2Bkk24UUD4kc40kxA%2F%2Bb2L%2F6LpO3XGol2XuiU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=k9hpugO%2Bkk24UUD4kc40kxA%2F%2Bb2L%2F6LpO3XGol2XuiU%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=k9hpugO%2Bkk24UUD4kc40kxA%2F%2Bb2L%2F6LpO3XGol2XuiU%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=k9hpugO%2Bkk24UUD4kc40kxA%2F%2Bb2L%2F6LpO3XGol2XuiU%3D&reserved=0>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=QtWO7rD%2Frv5Z7qelmJt%2Bc4VZFF5hU8CfdqaAOY8ioeY%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710197463&sdata=QtWO7rD%2Frv5Z7qelmJt%2Bc4VZFF5hU8CfdqaAOY8ioeY%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=vroQWV7mdMmYRSXPbEy5PhjAmI87PuO1LWcqyJd53rc%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=vroQWV7mdMmYRSXPbEy5PhjAmI87PuO1LWcqyJd53rc%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=vroQWV7mdMmYRSXPbEy5PhjAmI87PuO1LWcqyJd53rc%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=vroQWV7mdMmYRSXPbEy5PhjAmI87PuO1LWcqyJd53rc%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=vroQWV7mdMmYRSXPbEy5PhjAmI87PuO1LWcqyJd53rc%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=vroQWV7mdMmYRSXPbEy5PhjAmI87PuO1LWcqyJd53rc%3D&reserved=0>>
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=mabDypKoNxsie1cZd0DPfE0TUecxvPD0Nbyq5WkqVnc%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=mabDypKoNxsie1cZd0DPfE0TUecxvPD0Nbyq5WkqVnc%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710207468&sdata=mabDypKoNxsie1cZd0DPfE0TUecxvPD0Nbyq5WkqVnc%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=Bf30HPnhZUVDsiWgRcPNr1jkE15G3NDoiYY3XXwqS0A%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=Bf30HPnhZUVDsiWgRcPNr1jkE15G3NDoiYY3XXwqS0A%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=Bf30HPnhZUVDsiWgRcPNr1jkE15G3NDoiYY3XXwqS0A%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=Bf30HPnhZUVDsiWgRcPNr1jkE15G3NDoiYY3XXwqS0A%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=Bf30HPnhZUVDsiWgRcPNr1jkE15G3NDoiYY3XXwqS0A%3D&reserved=0>>
>>>>
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=5Qa%2Br%2BkYwxQ5IW5kRijnioMWZupNrU0wKN0ug7IRHtA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=5Qa%2Br%2BkYwxQ5IW5kRijnioMWZupNrU0wKN0ug7IRHtA%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=5Qa%2Br%2BkYwxQ5IW5kRijnioMWZupNrU0wKN0ug7IRHtA%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710217478&sdata=5Qa%2Br%2BkYwxQ5IW5kRijnioMWZupNrU0wKN0ug7IRHtA%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=3ExSBsYqabDxBplOM0hyNTeBqya9b7FCw8Fk5cW0ZX0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=3ExSBsYqabDxBplOM0hyNTeBqya9b7FCw8Fk5cW0ZX0%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=3ExSBsYqabDxBplOM0hyNTeBqya9b7FCw8Fk5cW0ZX0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=3ExSBsYqabDxBplOM0hyNTeBqya9b7FCw8Fk5cW0ZX0%3D&reserved=0>>
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=Ka%2BY3t9%2FSwgr2NOj7tf9pXAoO%2B0BAmJiyuL6TB9l8ys%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=Ka%2BY3t9%2FSwgr2NOj7tf9pXAoO%2B0BAmJiyuL6TB9l8ys%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=Ka%2BY3t9%2FSwgr2NOj7tf9pXAoO%2B0BAmJiyuL6TB9l8ys%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=Ka%2BY3t9%2FSwgr2NOj7tf9pXAoO%2B0BAmJiyuL6TB9l8ys%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710227487&sdata=Ka%2BY3t9%2FSwgr2NOj7tf9pXAoO%2B0BAmJiyuL6TB9l8ys%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=67TGLft%2FtuINFBdb415tp27mxZGb%2BffhhZJp%2BAiN%2FNQ%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=67TGLft%2FtuINFBdb415tp27mxZGb%2BffhhZJp%2BAiN%2FNQ%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=67TGLft%2FtuINFBdb415tp27mxZGb%2BffhhZJp%2BAiN%2FNQ%3D&reserved=0>>
>>>>
>>>>
>>>>> On Feb 1, 2019, at 12:06 AM, Carlos Rovira <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>
>>> <mailto:carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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 (<aharui@adobe.com.invalid <ma...@adobe.com.invalid> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid>>>>)
>>>>> escribió:
>>>>>
>>>>>> I hope to look at this on the weekend.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 1/31/19, 4:17 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>> <mailto:
>>> harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>
>>>>>> Bump.
>>>>>>
>>>>>> Anyone have opinions on this?
>>>>>>
>>>>>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>> <mailto:
>>> harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=CRG735qu19y%2FJ%2BbcUSlATBIraeD0Ty%2BjQ7FY3n4tYnk%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=CRG735qu19y%2FJ%2BbcUSlATBIraeD0Ty%2BjQ7FY3n4tYnk%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=CRG735qu19y%2FJ%2BbcUSlATBIraeD0Ty%2BjQ7FY3n4tYnk%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=CRG735qu19y%2FJ%2BbcUSlATBIraeD0Ty%2BjQ7FY3n4tYnk%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=CRG735qu19y%2FJ%2BbcUSlATBIraeD0Ty%2BjQ7FY3n4tYnk%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710237496&sdata=CRG735qu19y%2FJ%2BbcUSlATBIraeD0Ty%2BjQ7FY3n4tYnk%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=%2BVvOshu3wQ9OTc%2FOYtXC%2FZ4sLlFFT1ZBP4YreNRarAI%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=%2BVvOshu3wQ9OTc%2FOYtXC%2FZ4sLlFFT1ZBP4YreNRarAI%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=%2BVvOshu3wQ9OTc%2FOYtXC%2FZ4sLlFFT1ZBP4YreNRarAI%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=%2BVvOshu3wQ9OTc%2FOYtXC%2FZ4sLlFFT1ZBP4YreNRarAI%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=%2BVvOshu3wQ9OTc%2FOYtXC%2FZ4sLlFFT1ZBP4YreNRarAI%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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=%2BVvOshu3wQ9OTc%2FOYtXC%2FZ4sLlFFT1ZBP4YreNRarAI%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 <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>
>>>>>> <mailto:carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>
>>>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@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 <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@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" <carlosrovira@apache.org <ma...@apache.org>
>>>>>> <mailto:carlosrovira@apache.org <ma...@apache.org>> <mailto:
>>>>>>>>> carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@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.lists@gmail.com <ma...@gmail.com>
>>>>>> <mailto:harbs.lists@gmail.com <ma...@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 <
>>>>>> carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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
>>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid> <mailto:aharui@adobe.com.invalid <ma...@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" <
>>>>>> carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=DMA1dmU8pW5pvO2Ew%2FlpWFSIgLGgXax8dYxLIj9J1lg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=DMA1dmU8pW5pvO2Ew%2FlpWFSIgLGgXax8dYxLIj9J1lg%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710247496&sdata=DMA1dmU8pW5pvO2Ew%2FlpWFSIgLGgXax8dYxLIj9J1lg%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0>
>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Carlos Rovira
>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0>
>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710257506&sdata=lIanb4R8BgxS9ns8mnHWKgpory0ydq1dRUAlFgkfZIM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0>
>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710267515&sdata=pwf0s6wxMXjEhx4aXeFS4%2BU8in%2BQW%2F3fxiwxq3i2ZZM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710277520&sdata=mqngSTIyD8C2KotepVllaKbFGllb0yvwHkLrcuf0qa0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0>>>
>>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C0a3d03a595e7481bf5cd08d697d45ddd%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636863335710287525&sdata=GfC%2BeaBtqF8DK8WiQZP4y94fjPJtqZJQbHCcsD5ifl0%3D&reserved=0>>
Re: Problems dealing with bead substitution in Royale
Posted by Harbs <ha...@gmail.com>.
Thanks for your thoughts.
My motivation for doing this has very little to do with removing beads. I have not been happy with the event system of strands and beads for a long time.
I’d be OK with removing removeBead from IStrand, but as it stands now, I think it makes sense to remove the notifications that are added.
Events are very heavy. I don’t know how often you’ve tried to step through code that dispatches events. It’s painful. There’s something like ten function calls just to call a function. To me, notifications make much more sense than events in the vast majority of cases. In my mind the main difference between notifications and events is that events are broadcasting to the whole world and there’s very little structure on how those events work. Notifying a bead from a strand directly makes the behavior much more predictable. Doing so requires a single lookup and normal function call (rather than a callback).
Now, it’s possible that some of the weight of event dispatching can be resolved by replacing the goog events with something else. But it still feels to me like a misuse of events. I like a much more structured approach.
I don’t understand why you think that this breaks capsulation. Strands already have a reference to their beads. Using the notification system, the lookup knows nothing about its beads other than there’s possibly an array of IBeads associated with a list of notification names. I don’t think your point in #1 is a concern because the parent does not know anything other than the fact that it contains IBeads (which it already does).
> 5) A central function with a giant switch statement, IMO, also breaks encapsulation and adds handler overhead. Think of how subclasses would override behavior in the base class. Each subclass would have its own switch statement.
For beads which only have a single notification interest, it adds no overhead. It does add some overhead on beads which are interested in more than one notification (i.e. a switch call), but it adds predictability in how Beads work. To me, that’s important. I don’t think it’s very common to have beads override other beads and handle notifications on multiple levels, but if both the superclass and subclass handle notifications, then yes, there would be conditional code in both classes.
> 6) Shared beads should be relative rare as well, but I'm not clear how this proposal helps.
Since the bead does not need to add event listeners to the strand, it does not need to track which strands it belongs to. This is probably more a problem in the event that the events need to be removed.
Also, the notification system would allow “detached” beads to work without even being added to a Strand. Some class could simply get its interest and send it notifications. This would likely make it easier to write unit tests for beads. It seems to me that notifications have *better* encapsulation than events.
Again: My main interest in this change is because I think it makes the interfaces and interactions of strands and beads cleaner and more predictable.
Thanks,
Harbs
> On Feb 21, 2019, at 7:58 AM, Alex Harui <ah...@adobe.com.INVALID> wrote:
>
> It looks like a reasonable subsystem design, but given that we have a lot of code running just fine without this, and that bead substitution should be a very rare situation, I'm having trouble understanding why we would want to add an entire just-in-case subsystem.
>
> Asking beads for their interests breaks encapsulation. Why should the outside world know or care? Just so you can remove a bead? Some really sophisticated beads may not register all interests/event listeners at once, or dynamically figure out interests/events. Then this whole subsystem would get bigger.
>
> Regarding the benefits you listed:
> 1) Having "parent" object know about their children has led to lots of problems in Flex and Royale. Think of creationPolicy="all" and modules sticking in memory or modules not loading because the parent already contained the classes in the module because it referenced the module. It is much better to abstract the "children" away from the "parent". That principle of encapsulation allows deferred instantiation and loading.
> 2) I don't understand what indirection you are referring to.
> 3) I didn't understand this point either.
> 4) We could try again to make all strands IEventDispatcher, or see if we can teach the compiler to allow IStrand and IStrandEventDispatcher. That would be independent of this proposal.
> 5) A central function with a giant switch statement, IMO, also breaks encapsulation and adds handler overhead. Think of how subclasses would override behavior in the base class. Each subclass would have its own switch statement.
> 6) Shared beads should be relative rare as well, but I'm not clear how this proposal helps.
>
> If the main concern is trying to get a bead to clean up when removed, let's stop and try to find a PAYG way for that, not a just-in-case way for that. Let's see if we can agree on:
> 1) Should every bead be removable? I would say no.
> 2) If only certain beads need to be removable, then a separate interface with a cleanup methods should suffice.
> 3) Beads that want to have removable versions should have protected, not private event handlers. Then a subclass could add removability.
>
> IMO, the solution to removing beads is really this simple and doesn't require a whole new subsystem.
>
> There might be some good things to keep from the proposal. Maybe there should be a base class for all beads. If you want to create a branch and see if it makes HelloWorld smaller, then that would be a win. Maybe that base class can have a "host" or "eventStrand" property that implements IEventDispatcher to reduce the number of times we write "as EventDispatcher" and maybe that will also make HelloWorld smaller. Maybe there can then be a subclass of that baseclass that adds removeability, but I would rather it be added at the end of the inheritance chain otherwise folks will opt-in on it "just-in-case".
>
> I would need to understand more about why we need an entirely different callback/notification/event subsystem. There are definitely some lighterweight models out there, but we've already paid for DOM Events, and then how do folks decide which one to use.
>
> But my main objection is patterns that break encapsulation and require the parent to know about the child. Hopefully other parts of the proposal can be tweaked.
>
> My 2 cents,
> -Alex
>
> On 2/19/19, 9:31 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>
>
>> On Feb 19, 2019, at 5:14 PM, Carlos Rovira <ca...@apache.org> wrote:
>>
>> Hi Harbs,
>>
>> I finally could take a look at you notification system, I can intuit a
>> good idea but still need more info or explanation from you to get the
>> benefits. My questions is more about the global thinking of the
>> notification idea more than an implementation question:
>>
>> 1.- why we have tow methods "notify" and "sendNotification"? naming seems
>> refer to the same purpose right?
>
> “notify” is a convenience method which uses sendNotification. Since the vast majority of notifications do not need a payload, “notify” allows for easier sending of the notifications.
>
>> 2.- this system should be better to handle things like bead removal so the
>> bead knows how to do it, right? how this is performed? have we got a
>> cleaning method in the bead that should know how to clean itself to do this?
>
> Yes. Basically, you can ask any bead for a list of its interests, and that list is used to both add and remove bead references in the strand. The bead does not need to clean itself. A ututiliy method can completely strip a bead off a strand including all references necessary for notification. Take a look how that’s done here:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-5f2744f9620d90c13d8759c4a326e8cbR27&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=ZyjJQvA1k8sCslnMq35%2B0SAID8dj8ydMG1siUXtmg14%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-5f2744f9620d90c13d8759c4a326e8cbR27&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=ZyjJQvA1k8sCslnMq35%2B0SAID8dj8ydMG1siUXtmg14%3D&reserved=0>
>
>> 3.- what's the main point between dispatch events and notification? maybe
>> this is the main thing I want to learn here. IOW, what's the benefits or
>> what we get over the normal dispatch
>
> Benefits:
> 1. Beads do not reference the Strand at all. All references are from the Strand to the bead.
> 2. Event listeners have a lot of indirection when they are launched. It’s much easier to step through notification dispatching.
> 3. Because notifications have no callback passing, there’s less chance of memory leaks due to callback references.
> 4. Currently, the framework has countless uses of “_strand as IEventDispatcher”. This is not something I’m thrilled with. Notifications make things much cleaner.
> 5. There’s a single entry point for notifications in a bead. I think that makes things easier to grok.
> 6. I think notifications makes it cleaner to use a single bead on multiple strands (if so desired).
>
>> 4.- Do you see some drawback? or what's the flaw points we can get over the
>> traditional event dispatch system?
>
> Here’s the drawbacks that I see:
> 1. We’re adding some additional weight to strands and beads.
> 2. Some of the events that we’re dispatching are used on different beads such as “layoutNeeded” where we’re laying out children relative to their parents. Cases like that will be needed to be handled.
>
> Regarding #1. I think the additional weight is more than offset by code saved by not having to attach so many event handlers.
> Regarding #2: Events can still be used when they make sense, or maybe there’s some other way to handle layout issues. Not 100% sure on the best way to handle that problem.
>
>> Sorry, if I need more explanation, but I still trying to figure what's all
>> about. Hope with your explanation I'll see the big picture
>>
>> thanks
>>
>>
>> El mar., 19 feb. 2019 a las 12:03, Harbs (<harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>) escribió:
>>
>>> Bump.
>>>
>>>> On Feb 1, 2019, at 8:36 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0>>
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=Dw6mjxE54icP7JJHr7gK8DQ1ak%2BIfbkZCJslTcx8v04%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=Dw6mjxE54icP7JJHr7gK8DQ1ak%2BIfbkZCJslTcx8v04%3D&reserved=0>>
>>>>
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0>>
>>>>
>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0>>
>>> <
>>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0>>
>>>>
>>>>
>>>>> On Feb 1, 2019, at 12:06 AM, Carlos Rovira <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>
>>> <mailto:carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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 (<aharui@adobe.com.invalid <ma...@adobe.com.invalid> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid>>
>>> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid>>>>)
>>>>> escribió:
>>>>>
>>>>>> I hope to look at this on the weekend.
>>>>>>
>>>>>> -Alex
>>>>>>
>>>>>> On 1/31/19, 4:17 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>> <mailto:
>>> harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>
>>>>>> Bump.
>>>>>>
>>>>>> Anyone have opinions on this?
>>>>>>
>>>>>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>> <mailto:
>>> harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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 <carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@apache.org>>
>>>>>> <mailto:carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@gmail.com>>
>>>>>> <mailto:harbs.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@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 <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>>
>>>>>> <mailto:aharui@adobe.com.INVALID <ma...@adobe.com.INVALID> <mailto:aharui@adobe.com.INVALID <ma...@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" <carlosrovira@apache.org <ma...@apache.org>
>>>>>> <mailto:carlosrovira@apache.org <ma...@apache.org>> <mailto:
>>>>>>>>> carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@gmail.com> <mailto:harbs.lists@gmail.com <ma...@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.lists@gmail.com <ma...@gmail.com>
>>>>>> <mailto:harbs.lists@gmail.com <ma...@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 <
>>>>>> carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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
>>>>>>>>> (<aharui@adobe.com.invalid <ma...@adobe.com.invalid> <mailto:aharui@adobe.com.invalid <ma...@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" <
>>>>>> carlosrovira@apache.org <ma...@apache.org> <mailto:carlosrovira@apache.org <ma...@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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Carlos Rovira
>>>>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Carlos Rovira
>>>>>>>>>>
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>>>
>>>>>>>>> <
>>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Carlos Rovira
>>>>>>>>
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>> <
>>>>>>
>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Carlos Rovira
>>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>>>
>>>>
>>>
>>>
>>
>> --
>> Carlos Rovira
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0><https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>>
Re: Problems dealing with bead substitution in Royale
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It looks like a reasonable subsystem design, but given that we have a lot of code running just fine without this, and that bead substitution should be a very rare situation, I'm having trouble understanding why we would want to add an entire just-in-case subsystem.
Asking beads for their interests breaks encapsulation. Why should the outside world know or care? Just so you can remove a bead? Some really sophisticated beads may not register all interests/event listeners at once, or dynamically figure out interests/events. Then this whole subsystem would get bigger.
Regarding the benefits you listed:
1) Having "parent" object know about their children has led to lots of problems in Flex and Royale. Think of creationPolicy="all" and modules sticking in memory or modules not loading because the parent already contained the classes in the module because it referenced the module. It is much better to abstract the "children" away from the "parent". That principle of encapsulation allows deferred instantiation and loading.
2) I don't understand what indirection you are referring to.
3) I didn't understand this point either.
4) We could try again to make all strands IEventDispatcher, or see if we can teach the compiler to allow IStrand and IStrandEventDispatcher. That would be independent of this proposal.
5) A central function with a giant switch statement, IMO, also breaks encapsulation and adds handler overhead. Think of how subclasses would override behavior in the base class. Each subclass would have its own switch statement.
6) Shared beads should be relative rare as well, but I'm not clear how this proposal helps.
If the main concern is trying to get a bead to clean up when removed, let's stop and try to find a PAYG way for that, not a just-in-case way for that. Let's see if we can agree on:
1) Should every bead be removable? I would say no.
2) If only certain beads need to be removable, then a separate interface with a cleanup methods should suffice.
3) Beads that want to have removable versions should have protected, not private event handlers. Then a subclass could add removability.
IMO, the solution to removing beads is really this simple and doesn't require a whole new subsystem.
There might be some good things to keep from the proposal. Maybe there should be a base class for all beads. If you want to create a branch and see if it makes HelloWorld smaller, then that would be a win. Maybe that base class can have a "host" or "eventStrand" property that implements IEventDispatcher to reduce the number of times we write "as EventDispatcher" and maybe that will also make HelloWorld smaller. Maybe there can then be a subclass of that baseclass that adds removeability, but I would rather it be added at the end of the inheritance chain otherwise folks will opt-in on it "just-in-case".
I would need to understand more about why we need an entirely different callback/notification/event subsystem. There are definitely some lighterweight models out there, but we've already paid for DOM Events, and then how do folks decide which one to use.
But my main objection is patterns that break encapsulation and require the parent to know about the child. Hopefully other parts of the proposal can be tweaked.
My 2 cents,
-Alex
On 2/19/19, 9:31 AM, "Harbs" <ha...@gmail.com> wrote:
> On Feb 19, 2019, at 5:14 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I finally could take a look at you notification system, I can intuit a
> good idea but still need more info or explanation from you to get the
> benefits. My questions is more about the global thinking of the
> notification idea more than an implementation question:
>
> 1.- why we have tow methods "notify" and "sendNotification"? naming seems
> refer to the same purpose right?
“notify” is a convenience method which uses sendNotification. Since the vast majority of notifications do not need a payload, “notify” allows for easier sending of the notifications.
> 2.- this system should be better to handle things like bead removal so the
> bead knows how to do it, right? how this is performed? have we got a
> cleaning method in the bead that should know how to clean itself to do this?
Yes. Basically, you can ask any bead for a list of its interests, and that list is used to both add and remove bead references in the strand. The bead does not need to clean itself. A ututiliy method can completely strip a bead off a strand including all references necessary for notification. Take a look how that’s done here:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-5f2744f9620d90c13d8759c4a326e8cbR27&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=ZyjJQvA1k8sCslnMq35%2B0SAID8dj8ydMG1siUXtmg14%3D&reserved=0
> 3.- what's the main point between dispatch events and notification? maybe
> this is the main thing I want to learn here. IOW, what's the benefits or
> what we get over the normal dispatch
Benefits:
1. Beads do not reference the Strand at all. All references are from the Strand to the bead.
2. Event listeners have a lot of indirection when they are launched. It’s much easier to step through notification dispatching.
3. Because notifications have no callback passing, there’s less chance of memory leaks due to callback references.
4. Currently, the framework has countless uses of “_strand as IEventDispatcher”. This is not something I’m thrilled with. Notifications make things much cleaner.
5. There’s a single entry point for notifications in a bead. I think that makes things easier to grok.
6. I think notifications makes it cleaner to use a single bead on multiple strands (if so desired).
> 4.- Do you see some drawback? or what's the flaw points we can get over the
> traditional event dispatch system?
Here’s the drawbacks that I see:
1. We’re adding some additional weight to strands and beads.
2. Some of the events that we’re dispatching are used on different beads such as “layoutNeeded” where we’re laying out children relative to their parents. Cases like that will be needed to be handled.
Regarding #1. I think the additional weight is more than offset by code saved by not having to attach so many event handlers.
Regarding #2: Events can still be used when they make sense, or maybe there’s some other way to handle layout issues. Not 100% sure on the best way to handle that problem.
> Sorry, if I need more explanation, but I still trying to figure what's all
> about. Hope with your explanation I'll see the big picture
>
> thanks
>
>
> El mar., 19 feb. 2019 a las 12:03, Harbs (<harbs.lists@gmail.com <ma...@gmail.com>>) escribió:
>
>> Bump.
>>
>>> On Feb 1, 2019, at 8:36 AM, Harbs <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2b4ced1196f39150a85b0cd61bbb338dL64&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=OyLk%2B0QNvu6M8sP%2BkNWHGEmLR8QafRm%2Bu83k8TC9T7M%3D&reserved=0>
>>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-1579cf5aa28be79326d96804b8ff5b85R95&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=XKBbc%2BCV%2Fteblkw5NFk0f1YBqbq5S8qzyU8cgdnoKL8%3D&reserved=0>
>>>
>>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656440802&sdata=fe3alVQBAgbXv89iJpsE6TV95aHKcq8TUNHv0RN09lM%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-7b616cac43f87537a5c667f91f1b332fR54&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=Dw6mjxE54icP7JJHr7gK8DQ1ak%2BIfbkZCJslTcx8v04%3D&reserved=0>
>>>
>>>
>>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-75385354048a329d33d5708f25f4befdR41&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=g%2Be2ARXmhDSLRrgW%2FsklPhb%2BJ00B3ef6CaypNaOYLYw%3D&reserved=0>
>>>
>>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0>
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F1b2a45c91397e485be93d56925f2c31417726bb7%23diff-2e3a3b6cec1ef4fc0444d75bda6183e4R84&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=oTd5R5iAg74jYze6uLAMRI84WxcX6FAUkXc24W0vYjk%3D&reserved=0>
>>>
>>>
>>>> On Feb 1, 2019, at 12:06 AM, Carlos Rovira <carlosrovira@apache.org <ma...@apache.org>
>> <mailto:carlosrovira@apache.org <ma...@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 (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>
>> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid>>>)
>>>> escribió:
>>>>
>>>>> I hope to look at this on the weekend.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 1/31/19, 4:17 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:
>> harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>>
>>>>> Bump.
>>>>>
>>>>> Anyone have opinions on this?
>>>>>
>>>>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.lists@gmail.com <ma...@gmail.com> <mailto:
>> harbs.lists@gmail.com <ma...@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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656450824&sdata=wXQCjuHO6JhGSAJGX5PkseaDmJf65gqTlP97PM15bsI%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=u75lvuGE1xJhVdV4s5OFbhT9%2BgR8fjVfWDKf1jsY2VY%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 <carlosrovira@apache.org <ma...@apache.org>
>>>>> <mailto:carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@gmail.com>
>>>>> <mailto:harbs.lists@gmail.com <ma...@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 <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>
>>>>> <mailto:aharui@adobe.com.INVALID <ma...@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" <carlosrovira@apache.org
>>>>> <ma...@apache.org> <mailto:
>>>>>>>> carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@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.lists@gmail.com
>>>>> <ma...@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 <
>>>>> carlosrovira@apache.org <ma...@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
>>>>>>>> (<aharui@adobe.com.invalid <ma...@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" <
>>>>> carlosrovira@apache.org <ma...@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%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>>>
>>>>>>>> <
>>>>>>>>
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>>>
>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Carlos Rovira
>>>>>>>>>>>>
>>>>>>>>
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>>>
>>>>>>>> <
>>>>>>>>
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656460811&sdata=R7a0rAEazGapoEBDLbLZr4g1WuT7Ad%2BdGnFFRRTaFmw%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>>>
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Carlos Rovira
>>>>>>>>>
>>>>>>>>
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>>>
>>>>>>>> <
>>>>>>>>
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Carlos Rovira
>>>>>>>
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>> <
>>>>>
>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Carlos Rovira
>>>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>>
>>>
>>
>>
>
> --
> Carlos Rovira
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0 <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Cedad6916ea8e4b01f82108d696900319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636861942656470820&sdata=3wVjmlNkThi%2BSXcb7wUQ%2BW7kft5fAQfTS22sYVwdjD4%3D&reserved=0>
Re: Problems dealing with bead substitution in Royale
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs
El mar., 19 feb. 2019 a las 18:30, Harbs (<ha...@gmail.com>) escribió:
>
>
> Yes. Basically, you can ask any bead for a list of its interests, and that
> list is used to both add and remove bead references in the strand. The bead
> does not need to clean itself. A ututiliy method can completely strip a
> bead off a strand including all references necessary for notification. Take
> a look how that’s done here:
>
> https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-5f2744f9620d90c13d8759c4a326e8cbR27
>
>
I think most of the time, beads would need some code on its own that should
be run when removed, but anyway maybe that's no a problem
>
> Benefits:
> 1. Beads do not reference the Strand at all. All references are from the
> Strand to the bead.
2. Event listeners have a lot of indirection when they are launched. It’s
> much easier to step through notification dispatching.
> 3. Because notifications have no callback passing, there’s less chance of
> memory leaks due to callback references.
> 4. Currently, the framework has countless uses of “_strand as
> IEventDispatcher”. This is not something I’m thrilled with. Notifications
> make things much cleaner.
> 5. There’s a single entry point for notifications in a bead. I think that
> makes things easier to grok.
> 6. I think notifications makes it cleaner to use a single bead on multiple
> strands (if so desired).
>
ok, seems good
>
> > 4.- Do you see some drawback? or what's the flaw points we can get over
> the
> > traditional event dispatch system?
>
> Here’s the drawbacks that I see:
> 1. We’re adding some additional weight to strands and beads.
>
in some places I think we should not be extremely purist.
> 2. Some of the events that we’re dispatching are used on different beads
> such as “layoutNeeded” where we’re laying out children relative to their
> parents. Cases like that will be needed to be handled.
>
> Regarding #1. I think the additional weight is more than offset by code
> saved by not having to attach so many event handlers.
> Regarding #2: Events can still be used when they make sense, or maybe
> there’s some other way to handle layout issues. Not 100% sure on the best
> way to handle that problem.
>
> > Sorry, if I need more explanation, but I still trying to figure what's
> all
> > about. Hope with your explanation I'll see the big picture
> >
For me seems ok. I understand that although we add this we always can rely
on the old system, and migrate if we want different parts little by little
right?. And don't seems to much code added, so for me this doesn't break
PAYG. As I said before I think we should not be purist to the limit.
Maybe I'd need to experiment a bit with all this stuff to end understanding
and assimilate.
What do think others? any problem to add this notification system?
thanks
--
Carlos Rovira
http://about.me/carlosrovira
Re: Problems dealing with bead substitution in Royale
Posted by Harbs <ha...@gmail.com>.
> On Feb 19, 2019, at 5:14 PM, Carlos Rovira <ca...@apache.org> wrote:
>
> Hi Harbs,
>
> I finally could take a look at you notification system, I can intuit a
> good idea but still need more info or explanation from you to get the
> benefits. My questions is more about the global thinking of the
> notification idea more than an implementation question:
>
> 1.- why we have tow methods "notify" and "sendNotification"? naming seems
> refer to the same purpose right?
“notify” is a convenience method which uses sendNotification. Since the vast majority of notifications do not need a payload, “notify” allows for easier sending of the notifications.
> 2.- this system should be better to handle things like bead removal so the
> bead knows how to do it, right? how this is performed? have we got a
> cleaning method in the bead that should know how to clean itself to do this?
Yes. Basically, you can ask any bead for a list of its interests, and that list is used to both add and remove bead references in the strand. The bead does not need to clean itself. A ututiliy method can completely strip a bead off a strand including all references necessary for notification. Take a look how that’s done here:
https://github.com/apache/royale-asjs/commit/1b2a45c91397e485be93d56925f2c31417726bb7#diff-5f2744f9620d90c13d8759c4a326e8cbR27
> 3.- what's the main point between dispatch events and notification? maybe
> this is the main thing I want to learn here. IOW, what's the benefits or
> what we get over the normal dispatch
Benefits:
1. Beads do not reference the Strand at all. All references are from the Strand to the bead.
2. Event listeners have a lot of indirection when they are launched. It’s much easier to step through notification dispatching.
3. Because notifications have no callback passing, there’s less chance of memory leaks due to callback references.
4. Currently, the framework has countless uses of “_strand as IEventDispatcher”. This is not something I’m thrilled with. Notifications make things much cleaner.
5. There’s a single entry point for notifications in a bead. I think that makes things easier to grok.
6. I think notifications makes it cleaner to use a single bead on multiple strands (if so desired).
> 4.- Do you see some drawback? or what's the flaw points we can get over the
> traditional event dispatch system?
Here’s the drawbacks that I see:
1. We’re adding some additional weight to strands and beads.
2. Some of the events that we’re dispatching are used on different beads such as “layoutNeeded” where we’re laying out children relative to their parents. Cases like that will be needed to be handled.
Regarding #1. I think the additional weight is more than offset by code saved by not having to attach so many event handlers.
Regarding #2: Events can still be used when they make sense, or maybe there’s some other way to handle layout issues. Not 100% sure on the best way to handle that problem.
> Sorry, if I need more explanation, but I still trying to figure what's all
> about. Hope with your explanation I'll see the big picture
>
> thanks
>
>
> El mar., 19 feb. 2019 a las 12:03, Harbs (<harbs.lists@gmail.com <ma...@gmail.com>>) escribió:
>
>> Bump.
>>
>>> On Feb 1, 2019, at 8:36 AM, Harbs <harbs.lists@gmail.com <ma...@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-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-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-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-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>
>> <
>> 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 <carlosrovira@apache.org <ma...@apache.org>
>> <mailto:carlosrovira@apache.org <ma...@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 (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>
>> <mailto:aharui@adobe.com.invalid <ma...@adobe.com.invalid>>>)
>>>> escribió:
>>>>
>>>>> I hope to look at this on the weekend.
>>>>>
>>>>> -Alex
>>>>>
>>>>> On 1/31/19, 4:17 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com> <mailto:
>> harbs.lists@gmail.com <ma...@gmail.com>>> wrote:
>>>>>
>>>>> Bump.
>>>>>
>>>>> Anyone have opinions on this?
>>>>>
>>>>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.lists@gmail.com <ma...@gmail.com> <mailto:
>> harbs.lists@gmail.com <ma...@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 <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 <carlosrovira@apache.org <ma...@apache.org>
>>>>> <mailto:carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@gmail.com>
>>>>> <mailto:harbs.lists@gmail.com <ma...@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 <aharui@adobe.com.INVALID <ma...@adobe.com.INVALID>
>>>>> <mailto:aharui@adobe.com.INVALID <ma...@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" <carlosrovira@apache.org
>>>>> <ma...@apache.org> <mailto:
>>>>>>>> carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@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.lists@gmail.com
>>>>> <ma...@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 <
>>>>> carlosrovira@apache.org <ma...@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
>>>>>>>> (<aharui@adobe.com.invalid <ma...@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" <
>>>>> carlosrovira@apache.org <ma...@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> <http://about.me/carlosrovira <http://about.me/carlosrovira>>
>>>
>>
>>
>
> --
> Carlos Rovira
> http://about.me/carlosrovira <http://about.me/carlosrovira>
Re: Problems dealing with bead substitution in Royale
Posted by Carlos Rovira <ca...@apache.org>.
Hi Harbs,
I finally could take a look at you notification system, I can intuit a
good idea but still need more info or explanation from you to get the
benefits. My questions is more about the global thinking of the
notification idea more than an implementation question:
1.- why we have tow methods "notify" and "sendNotification"? naming seems
refer to the same purpose right?
2.- this system should be better to handle things like bead removal so the
bead knows how to do it, right? how this is performed? have we got a
cleaning method in the bead that should know how to clean itself to do this?
3.- what's the main point between dispatch events and notification? maybe
this is the main thing I want to learn here. IOW, what's the benefits or
what we get over the normal dispatch
4.- Do you see some drawback? or what's the flaw points we can get over the
traditional event dispatch system?
Sorry, if I need more explanation, but I still trying to figure what's all
about. Hope with your explanation I'll see the big picture
thanks
El mar., 19 feb. 2019 a las 12:03, Harbs (<ha...@gmail.com>) escribió:
> Bump.
>
> > On Feb 1, 2019, at 8:36 AM, Harbs <ha...@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 <carlosrovira@apache.org
> <ma...@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 (<aharui@adobe.com.invalid
> <ma...@adobe.com.invalid>>)
> >> escribió:
> >>
> >>> I hope to look at this on the weekend.
> >>>
> >>> -Alex
> >>>
> >>> On 1/31/19, 4:17 AM, "Harbs" <harbs.lists@gmail.com <mailto:
> harbs.lists@gmail.com>> wrote:
> >>>
> >>> Bump.
> >>>
> >>> Anyone have opinions on this?
> >>>
> >>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.lists@gmail.com <mailto:
> harbs.lists@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 <carlosrovira@apache.org
> >>> <ma...@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.lists@gmail.com
> >>> <ma...@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 <aharui@adobe.com.INVALID
> >>> <ma...@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" <carlosrovira@apache.org
> >>> <ma...@apache.org> <mailto:
> >>>>>> carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@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.lists@gmail.com
> >>> <ma...@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 <
> >>> carlosrovira@apache.org <ma...@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
> >>>>>> (<aharui@adobe.com.invalid <ma...@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" <
> >>> carlosrovira@apache.org <ma...@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>
> >
>
>
--
Carlos Rovira
http://about.me/carlosrovira
Re: Problems dealing with bead substitution in Royale
Posted by Harbs <ha...@gmail.com>.
Bump.
> On Feb 1, 2019, at 8:36 AM, Harbs <ha...@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 <carlosrovira@apache.org <ma...@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 (<aharui@adobe.com.invalid <ma...@adobe.com.invalid>>)
>> escribió:
>>
>>> I hope to look at this on the weekend.
>>>
>>> -Alex
>>>
>>> On 1/31/19, 4:17 AM, "Harbs" <harbs.lists@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Bump.
>>>
>>> Anyone have opinions on this?
>>>
>>>> On Jan 30, 2019, at 12:47 PM, Harbs <harbs.lists@gmail.com <ma...@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 <carlosrovira@apache.org
>>> <ma...@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.lists@gmail.com
>>> <ma...@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 <aharui@adobe.com.INVALID
>>> <ma...@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" <carlosrovira@apache.org
>>> <ma...@apache.org> <mailto:
>>>>>> carlosrovira@apache.org <ma...@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.lists@gmail.com <ma...@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.lists@gmail.com
>>> <ma...@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 <
>>> carlosrovira@apache.org <ma...@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
>>>>>> (<aharui@adobe.com.invalid <ma...@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" <
>>> carlosrovira@apache.org <ma...@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>
>