Piotr, Alex, fyi I found some time to spend on this today, and Piotr, I should be ready to push the changes I made to your branch tomorrow morning my time (local time - GMT+13). It seems to be fine so far with 'selectionChange' for binding based on model changes and 'change' for class event meta. I have been been testing so far against Tour de Jewel, but I will test against our real-world project as well before I push to your branch Piotr.
-Greg On Wed, Dec 19, 2018 at 7:45 AM Greg Dove <[email protected]> wrote: > Alex, I can't remember offhand, but I think we used that once in only one > place, and I did it really quickly. I am sure there will be a way to avoid > it. > I think the bigger issue is the way I did the changes to the model to > support dispatching change events for programmatic changes, which I think > Piotr was looking at. > Maybe I can take a look at that later today, but I can't be certain. > The simplest fix might be to revert everything I did and add binding for > the selection changes (currently 'selectedIndexChanged' and > 'selectedItemChanged' which I know you say could be 'selectionChanged') in > addition to 'change' (as discussed) and make sure the component is > dispatching those from the model (if it does not already do so). If > 'selectionChanged' (or whatever it is) is already happening as a result of > 'change' in addition to setter triggered changes, then it could be a simple > swap for the binding event only (as discussed also) > > But this last part was also applicable to the wholesale change to all > component sets we were discussing, not just Jewel. > > > > > On Wed, Dec 19, 2018 at 7:17 AM Alex Harui <[email protected]> > wrote: > >> Greg, Carlos, >> >> Can one of you put together a simple test case that demonstrates your >> need for this "OnStartup" bead? It doesn't need server access. You can >> probably inject a dataProvider on applicationComplete or have the user push >> a button if the issue is about deferred arrival of server data. >> >> IMO, we have to be more concerned about getting the patterns right >> regressions, and the best way to avoid getting regressions is to provide a >> simple test case that demonstrates a problem in the patterns. >> >> Hopefully, "OnStartup" beads are not going to be required and won't be >> part of the framework. The usability of the framework will go down if >> folks have to keep adding more and more "OnThis" and "OnThat" beads to get >> their app to work. The approachability of the framework in terms of >> documentation and number of classes won't scale either if we don't get >> these patterns right. This doesn't mean that you can't use an "onStartup" >> bead in your app in order to meet some deadline, and share it with others, >> but we have to be careful about what patterns we promote in the SDK. >> >> My 2 cents, >> -Alex >> >> On 12/18/18, 12:17 AM, "Greg Dove" <[email protected]> wrote: >> >> Hi Piotr, >> >> I would be happy to work on it, and wish I could, but the problem for >> me at >> the moment is that I can't make it a priority, because for now at >> least it >> is functioning as we need it, and there are plenty of things that are >> not >> (mostly unrelated to Jewel). While the implementation as it stands >> might >> not be 'right', it does function as we need it to for now. I suspect >> that >> is what Carlos meant when he said he was concerned about regressions. >> >> I have other stuff queued up to add in other areas too, like >> AMFBinaryData >> and AMFNetConnection but will need to do more work to generalize it, >> as I >> have it these working in a way that is almost complete, but mostly >> focused >> on what is sufficient for what Carlos needs for now. >> >> I hope to get some free time in early January to finish up these >> things. >> >> >> >> >> On Tue, Dec 18, 2018 at 11:53 AM Piotr Zarzycki < >> [email protected]> >> wrote: >> >> > Hi Guys, >> > >> > I definitely need to a way of resolve that problem. I will review >> emails >> > tomorrow. >> > >> > However if you Greg would like to try something go for it. Would be >> great >> > if you could use my branch where changes which removes dispatching >> "change" >> > event from model are in place. >> > >> > Thanks, Piotr >> > >> > pon., 17 gru 2018 o 23:46 Alex Harui <[email protected]> >> > napisał(a): >> > >> > > Hi Greg, >> > > >> > > I haven't looked at how pervasive this change would be. I'm >> mainly >> > saying >> > > that Flex worked with these categories of events and I think >> Royale can >> > too >> > > and would eliminate the need for DispatchChangeOnStartup and >> things like >> > > that. >> > > >> > > You could be right that the models only need to dispatch >> selectionChange >> > > and not "change", as long as the controllers are guaranteed to >> update the >> > > model in a way that fires selectionChange. I have this feeling >> that in >> > > Flex there were some backdoors for updating properties without >> > dispatching >> > > events and dispatching the event "later", but I don't think we've >> had to >> > > write such code in Royale and maybe we won't have to or can't >> because the >> > > browser will update right away in many cases. There were >> somethings you >> > > could do in Flash knowing that all rendering was deferred to frame >> > > updates. In Royale, with separate models, the controller code >> can't just >> > > set the backing variable. >> > > >> > > So, if you want to give it a try having only selectionChange as >> the >> > > bindable event, go for it. >> > > >> > > -Alex >> > > >> > > On 12/17/18, 12:35 PM, "Greg Dove" <[email protected]> wrote: >> > > >> > > Thanks Alex. >> > > >> > > I only looked in Basic TextInput because I was looking for a >> simpler >> > > example of the general case being discussed. That code looks >> like it >> > > might >> > > need some work on the swf side in any case. >> > > I was just looking for the 'programmaticChange' vs >> > > 'userInitiatedChange' >> > > differences. >> > > >> > > Based on a quick look at the other Basic classes, the >> conclusions >> > > appear >> > > similar. They are bindable via 'change' only. >> > > And the models all dispatch both selectedIndexChanged and >> > > selectedItemChanged. >> > > >> > > So it seems like you are proposing broad changes for >> everything, if >> > > they >> > > are to also support binding changes for programmatic changes? >> > > >> > > For me, the change in something (or nothing) being 'selected' >> > logically >> > > occurs as a result of either user change or programmatic >> change. On >> > > that >> > > basis would it be possible to have the selectionChange as the >> sole >> > > Binding >> > > event (which occurs from setter induced change and from user >> induced >> > > change) and the 'change' event as user-interaction only as >> the class >> > > level >> > > event type (as it is now)? >> > > >> > > I have not thought about this as much as you (Alex and >> others) have, >> > so >> > > maybe that last suggestion does not make sense. But I really >> think >> > > that for >> > > whatever does make sense it would be great to settle on >> something and >> > > get >> > > it consistent for all components asap. >> > > >> > > >> > > >> > > >> > > On Tue, Dec 18, 2018 at 8:43 AM Alex Harui >> <[email protected] >> > > >> > > wrote: >> > > >> > > > Hi Greg, >> > > > >> > > > You are correct that there is a pain point around binding >> overhead >> > > and >> > > > PAYG. I can't think of a PAYG way of adding the ability to >> add >> > more >> > > > binding events via beads that doesn't have too much >> overhead for >> > > folks not >> > > > interested in those extra events. Actually, there are some >> ways >> > > that are >> > > > JS-only like replacing prototype-methods, but I don't think >> we >> > > should rely >> > > > on mutable class definitions. In many cases we make >> trade-offs >> > and >> > > Basic >> > > > ends up being what we think almost all folks "must have". >> > > > >> > > > When we first started out I was hoping to reduce binding >> overhead >> > > which is >> > > > why some of the beads look like they do, but these days I >> think it >> > > is more >> > > > important to separate interactive events from binding/setup >> events. >> > > Folks >> > > > who don't use a particular binding event can always replace >> the >> > > model and >> > > > top-level component with a version without events they are >> not >> > > interested >> > > > in, or in the JS output, run a post-process to cull out >> metadata. >> > > But >> > > > under the "almost all folks" rule, I think "almost all >> folks" don't >> > > want to >> > > > run interaction handling code at setup time. Especially if >> that >> > > handling >> > > > code runs any sort of animation or does any other heavy >> processing. >> > > > >> > > > I could be wrong, but I'm pretty sure that if you just take >> a >> > > <select> >> > > > element, you can set its initial selection value without it >> > > dispatching an >> > > > event called "change". Then when a user selects an item >> you get a >> > > "change" >> > > > event. IMO, this is why "change" should be an interactive >> event >> > and >> > > not a >> > > > binding event. >> > > > >> > > > So these are the reasons I think we should adjust the basic >> beads >> > to >> > > > separate interactive events from setup events and why >> "change" is >> > an >> > > > interactive event. >> > > > >> > > > Now, we could renew the effort to make Basic the truly >> smallest >> > > > implementation and move some of this logic to Express, but >> I keep >> > > seeing >> > > > code creep into Basic to handle situations that almost all >> folks >> > > need. >> > > > >> > > > TextInput, on the other hand, has been an exception of >> sorts in >> > > Flex. The >> > > > Flash/AIR runtime dispatches "change" on certain kinds of >> changes. >> > > So >> > > > early implementations in Royale tried to mimic that >> behavior for >> > > folks >> > > > coming from Flex. But maybe we should change that and make >> Basic >> > > TextInput >> > > > more consistent with browser behavior. The emulation >> components >> > can >> > > mimic >> > > > the old Flex behavior. So I think using TextInput as >> precedent is >> > > > misleading. >> > > > >> > > > Thoughts? >> > > > -Alex >> > > > >> > > > On 12/17/18, 10:55 AM, "Greg Dove" <[email protected]> >> wrote: >> > > > >> > > > Alex, I was giving this some more thought also. I >> understood >> > > that you >> > > > meant >> > > > to add extra events for binding from your previous >> comments. >> > > > >> > > > But isn't the established pattern to add a bead to >> listen for >> > the >> > > > selectionChange and redispatch it as change? >> > > > >> > > > At least that seems to be the case elsewhere >> > > > >> > > > If I look at the code in Basic TextInput... >> > > > it dispatches 'textChange' and 'change' but is only >> Bindable >> > via >> > > > 'change'. >> > > > There is effort to keep them distinct/separate. >> > > > (OT: It looks like the swf side needs some consistency >> in the >> > > html >> > > > setter >> > > > same as the text setter.) >> > > > >> > > > So TextInput appears to have 2 distinct events but only >> be >> > > Bindable >> > > > for one >> > > > ('change'). So I presume that to make that support >> programmatic >> > > > changes it >> > > > would be by adding a bead to listen to the 'textChange' >> and >> > > redispatch >> > > > as >> > > > 'change' ? >> > > > >> > > > Adding extra Bindable events adds weight because it >> affects >> > > binding >> > > > data, >> > > > and creates more runtime support for the same feature >> in use >> > > cases >> > > > that may >> > > > not need it. I don't see how that can be 'PAYG-ised' >> because >> > > binding >> > > > support for different event types is either there at >> compile >> > > time or >> > > > it is >> > > > not in the component. So if the above is true for >> TextInput (at >> > > this >> > > > stage >> > > > it's a guess/observation, I did not try this yet), then >> could >> > it >> > > not be >> > > > similar for selection based components? >> > > > >> > > > To me 'change' seems like something generic and does >> not sound >> > > > specific to >> > > > being user-initiated change. My understanding is that >> it just >> > > happens >> > > > to be >> > > > that way by default, unless you configure it to include >> > > programmatic >> > > > changes via bead. >> > > > If it is like this for Basic TextInput, why can it not >> be the >> > > same for >> > > > other components ? ( >> > > > >> > > > >> > > > >> > > > On Tue, Dec 18, 2018 at 7:32 AM Alex Harui >> > > <[email protected]> >> > > > wrote: >> > > > >> > > > > I took a quick look at ArrayListSelection. It could >> use some >> > > > > improvements, such as only dispatching a single >> > > selectionChange event >> > > > > instead of both selectedIndexChange and >> selectedItemChange. >> > > > > >> > > > > Some controller should dispatch the "change" event, >> not the >> > > model. >> > > > > >> > > > > I took a quick look at List.as, (a top level >> component). It >> > > should >> > > > have >> > > > > bindable metadata that looks like this: >> > > > > >> > > > > [Bindable("change")] >> > > > > [Bindable("selectionChange")] >> > > > > public function get selectedIndex():int >> > > > > >> > > > > Similar for selectedItem. The [Event] metadata for >> List is >> > > > correct, It >> > > > > should only list interactive events like "change" and >> not >> > > bindable >> > > > events >> > > > > like selectionChange. This usually improves >> performance by >> > not >> > > > having the >> > > > > UI react to setup. >> > > > > >> > > > > Once all of those changes are made, we should discuss >> any >> > > remaining >> > > > issues. >> > > > > >> > > > > My 2 cents, >> > > > > -Alex >> > > > > >> > > > > On 12/17/18, 10:14 AM, "Piotr Zarzycki" < >> > > [email protected]> >> > > > > wrote: >> > > > > >> > > > > Basic ArrayListSelection model doesn't dispatch >> that >> > > event. I >> > > > believe >> > > > > we >> > > > > don't have to do this or rather do this only if >> we really >> > > need >> > > > it, for >> > > > > example if someone make programatic change of >> > > selectedIndex. - >> > > > This is >> > > > > general problem how to do that ? >> > > > > >> > > > > If I change selectedIndex - my model dispatch >> > > > selectedInexChanged - >> > > > > where >> > > > > should I catch it and dispatch "change" event ? >> My though >> > > are >> > > > nowhere, >> > > > > unless someone wanted to do that and have a bead. >> > > > > >> > > > > >> > > > > pon., 17 gru 2018 o 19:08 Alex Harui >> > > <[email protected]> >> > > > > napisał(a): >> > > > > >> > > > > > Hi Piotr, >> > > > > > >> > > > > > I may not be understanding your problem. Not >> all >> > models >> > > will >> > > > > dispatch a >> > > > > > change event, but it is hard to imagine a >> selection >> > > model that >> > > > > doesn't. >> > > > > > >> > > > > > -Alex >> > > > > > >> > > > > > On 12/17/18, 9:36 AM, "Piotr Zarzycki" < >> > > > [email protected]> >> > > > > wrote: >> > > > > > >> > > > > > I will review your email again and see what >> can I >> > do >> > > this. >> > > > > However >> > > > > > this one >> > > > > > is a second problem. First one was about >> > programmatic >> > > > change >> > > > > discover >> > > > > > - If >> > > > > > you are talking about that - Let me check >> your >> > > earlier >> > > > emails. >> > > > > > >> > > > > > Thanks, >> > > > > > Piotr >> > > > > > >> > > > > > pon., 17 gru 2018 o 18:30 Alex Harui >> > > > <[email protected]> >> > > > > > napisał(a): >> > > > > > >> > > > > > > FWIW, I would much rather see energy >> spent on >> > > trying to >> > > > > implement the >> > > > > > > patterns I suggested earlier, which will >> > hopefully >> > > > eliminate >> > > > > the >> > > > > > need for >> > > > > > > DispatchChangeOnStartup. >> > > > > > > >> > > > > > > My 2 cents, >> > > > > > > -Alex >> > > > > > > >> > > > > > > On 12/17/18, 4:34 AM, "Piotr Zarzycki" < >> > > > > [email protected]> >> > > > > > wrote: >> > > > > > > >> > > > > > > Carlos, >> > > > > > > >> > > > > > > I don't understand this sentence -> " >> If not >> > > we can >> > > > get >> > > > > involved >> > > > > > in >> > > > > > > pursues >> > > > > > > problems >> > > > > > > that are not real." - What do you >> mean here ? >> > > > > > > >> > > > > > > Ok I can wait for Alex review. >> > > > > > > >> > > > > > > However your review and look into >> above >> > problem >> > > > doesn't >> > > > > need >> > > > > > Alex's >> > > > > > > attention. This bead >> > (DispatchChangeOnStartup) >> > > > probably >> > > > > won't >> > > > > > work >> > > > > > > doesn't >> > > > > > > matter if we fix programmatic change >> or not. >> > - >> > > > Unless I >> > > > > bring >> > > > > > back >> > > > > > > dispatching "change" event from model >> - which >> > > rather >> > > > is not >> > > > > > > recommended in >> > > > > > > previous discussion. >> > > > > > > >> > > > > > > Thanks, Piotr >> > > > > > > >> > > > > > > pon., 17 gru 2018 o 13:14 Carlos >> Rovira < >> > > > > [email protected] >> > > > > > > >> > > > > > > napisał(a): >> > > > > > > >> > > > > > > > Hi Piotr, >> > > > > > > > >> > > > > > > > I think we should solve first the >> > programatic >> > > > change so >> > > > > I can >> > > > > > test >> > > > > > > the >> > > > > > > > branch and see regressions. If not >> we can >> > get >> > > > involved in >> > > > > > pursues >> > > > > > > problems >> > > > > > > > that are not real. I think Alex >> missed this >> > > > discussion. >> > > > > I'll >> > > > > > point >> > > > > > > him in >> > > > > > > > this thread to see if he can give >> his >> > opinion >> > > > about the >> > > > > ways >> > > > > > you >> > > > > > > proposed >> > > > > > > > in the initial thread email. >> > > > > > > > >> > > > > > > > Thanks! >> > > > > > > > >> > > > > > > > El lun., 17 dic. 2018 a las 10:57, >> Piotr >> > > Zarzycki >> > > > (< >> > > > > > > > [email protected]>) >> escribió: >> > > > > > > > >> > > > > > > > > Hi Carlos, >> > > > > > > > > >> > > > > > > > > I just noticed that if model do >> not >> > > dispatch >> > > > change >> > > > > event - >> > > > > > your >> > > > > > > bead >> > > > > > > > > DispatchChangeOnStartup won't work >> > because >> > > it >> > > > simply >> > > > > based on >> > > > > > > dispatching >> > > > > > > > > "change" event trough model. >> > > > > > > > > >> > > > > > > > > I'm wondering whether it won't be >> enough >> > > if that >> > > > bead >> > > > > listen >> > > > > > for >> > > > > > > > > "beadsAdded" (here I think it >> should be >> > > > registered for >> > > > > > > "initComplete" >> > > > > > > > > instead) and dispatch change >> event once. >> > I >> > > made >> > > > the >> > > > > changes >> > > > > > to >> > > > > > > that bead, >> > > > > > > > > but I don't have scenario which >> you are >> > > using it. >> > > > > > > > > >> > > > > > > > > Will you be able to test my >> changes on >> > > your >> > > > > application end >> > > > > > using >> > > > > > > my >> > > > > > > > > branch ? Above changes are not >> fully >> > > related to >> > > > what >> > > > > we are >> > > > > > > discussing >> > > > > > > > > here, so programmatic change >> still won't >> > > work >> > > > yet. >> > > > > Please >> > > > > > review >> > > > > > > those >> > > > > > > > > changes as well [1] >> > > > > > > > > >> > > > > > > > > Those new changes are just to >> check >> > > whether I >> > > > won't >> > > > > break >> > > > > > any of >> > > > > > > your >> > > > > > > > > functionality on startup. I will >> move for >> > > > creating >> > > > > bead for >> > > > > > > discovering >> > > > > > > > > programmatic changes, but first >> would >> > like >> > > to >> > > > know >> > > > > whether >> > > > > > till now >> > > > > > > > > everything is working fine. >> > > > > > > > > >> > > > > > > > > [1] >> > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fcommit%2F14f6354e037e5854900ef5620581f6914bd604c4&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284003207&sdata=ceIkx4wphA1rgpPQ1yLQEIac6MJ4HSwKxIS7nmbC3Gg%3D&reserved=0 >> > > > > > > > > >> > > > > > > > > Thanks, Piotr >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > pt., 14 gru 2018 o 19:55 Carlos >> Rovira < >> > > > > > [email protected]> >> > > > > > > > > napisał(a): >> > > > > > > > > >> > > > > > > > > > Hi Piotr, >> > > > > > > > > > >> > > > > > > > > > after check example code, we >> have: >> > > > > > > > > > >> > > > > > > > > > <j:ComboBox >> id="watchmenComboBox" >> > > > > > > dataProvider="{listModel.watchmen}"> >> > > > > > > > > > ... >> > > > > > > > > > then NS: >> > > > > > > > > > >> > > > > > > > > > <j:NumericStepper >> > > > > > valueChange="watchmenComboBox.selectedIndex = >> > > > > > > > > > event.target.value" minimum="0" >> > > maximum="5"/> >> > > > > > > > > > >> > > > > > > > > > and finally >> > > > > > > > > > >> > > > > > > > > > <j:Label >> id="watchmenComboBoxResult" >> > > html= >> > > > > > > > > > >> > > > "{describeItem(watchmenComboBox.selectedItem)}"/> >> > > > > > > > > > >> > > > > > > > > > I think right now works as >> expected, >> > > since the >> > > > > change is >> > > > > > > programatic >> > > > > > > > (is >> > > > > > > > > > not the user clicking in the >> combo list >> > > and >> > > > selecting >> > > > > > other item >> > > > > > > > > > >> > > > > > > > > > So I think a bead should be >> better in >> > > this >> > > > case, that >> > > > > > takes care >> > > > > > > of >> > > > > > > > this >> > > > > > > > > > behavior. >> > > > > > > > > > >> > > > > > > > > > I'm interested in Alex response >> about >> > > how to >> > > > handle >> > > > > it >> > > > > > > > > > >> > > > > > > > > > Thanks Piotr for working on this >> > > > > > > > > > >> > > > > > > > > > Carlos >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > El vie., 14 dic. 2018 a las >> 17:02, >> > Piotr >> > > > Zarzycki (< >> > > > > > > > > > [email protected]>) >> escribió: >> > > > > > > > > > >> > > > > > > > > > > Hi Carlos, >> > > > > > > > > > > >> > > > > > > > > > > I have created issue [1] and >> branch >> > > [2] for >> > > > > problem with >> > > > > > double >> > > > > > > > > dispatch >> > > > > > > > > > > "change" event. >> > > > > > > > > > > I have pushed changes when I'm >> > > removing from >> > > > > > > ArrayListSelectionModel >> > > > > > > > > > > dispatch of change event. >> > > > > > > > > > > >> > > > > > > > > > > Above action successfully fix >> however >> > > like I >> > > > > thought it's >> > > > > > > introduces >> > > > > > > > > > > another one which I would >> like to >> > > discuss >> > > > how to >> > > > > fix. I >> > > > > > have >> > > > > > > deployed >> > > > > > > > > > > temporary Tour De Jewel here >> [3] in >> > > order to >> > > > show >> > > > > you >> > > > > > and to >> > > > > > > others >> > > > > > > > > that >> > > > > > > > > > > issue. >> > > > > > > > > > > >> > > > > > > > > > > *New Issue:* >> > > > > > > > > > > When you go to ComboBox and >> try to >> > > change >> > > > > selectedIndex >> > > > > > using >> > > > > > > > > > > NumericStepper it will >> successfully >> > > change >> > > > > selectedItem >> > > > > > in >> > > > > > > ComboBox. >> > > > > > > > > > > Unfortunately label on the >> right >> > sight >> > > of >> > > > ComboBox >> > > > > won't >> > > > > > be >> > > > > > > updated. >> > > > > > > > > > > >> > > > > > > > > > > *Question is:* >> > > > > > > > > > > How should be implemented >> discover of >> > > > programmatic >> > > > > > change of >> > > > > > > > > > selectedIndex >> > > > > > > > > > > and selectedItem ? >> > > > > > > > > > > >> > > > > > > > > > > *I see following options:* >> > > > > > > > > > > 1) We should listen on events >> > > > > > > > >> selectedIndexChanged/selectedItemChanged >> > > > > > > > > > and >> > > > > > > > > > > dispatch "change" from >> components >> > View >> > > bead. >> > > > In >> > > > > this way >> > > > > > we >> > > > > > > have to >> > > > > > > > > take >> > > > > > > > > > > into account places where >> "we" as a >> > > component >> > > > > setup those >> > > > > > > properties >> > > > > > > > > > > internally - In that case >> > > > "selectedIndexChanged" >> > > > > and >> > > > > > > > > > "selectedItemChanged" >> > > > > > > > > > > event shouldn't be dispatch. >> > > > > > > > > > > >> > > > > > > > > > > 2) Create separate bead which >> allows >> > > discover >> > > > > > programmatic >> > > > > > > change of >> > > > > > > > > > > selectedIndex and >> selectedItem- cause >> > > not >> > > > everyone >> > > > > > wanted to >> > > > > > > have at >> > > > > > > > > all >> > > > > > > > > > > programmatic change event in >> the >> > > component - >> > > > > probably >> > > > > > most of >> > > > > > > the >> > > > > > > > cases >> > > > > > > > > > > will be opposite. >> > > > > > > > > > > >> > > > > > > > > > > What others think about that ? >> > > > > > > > > > > >> > > > > > > > > > > [1] >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fissues%2F353&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=i2ZNUl1KvL60iqlZt888Q0aowpNvTaVnyQqgFGAvCVs%3D&reserved=0 >> > > > > > > > > > > [2] >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Ftree%2Fbugfix%2Fissue_353_double_dispatch_of_change_event_in_Jewel_List&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=%2BewtJrgepDQvKgQxx4MtI3tpyoedNnwsjPFtmnfzY2A%3D&reserved=0 >> > > > > > > > > > > [3] >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftranspiledactionscript.com%2Fdev%2Froyale%2F%23&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=uCD2RJp2iFdW9%2BHjScGeJKaR87qaAT6%2FUDvAgOYAk5Y%3D&reserved=0 >> > > > > > > > > > > >> > > > > > > > > > > Thanks, >> > > > > > > > > > > -- >> > > > > > > > > > > >> > > > > > > > > > > Piotr Zarzycki >> > > > > > > > > > > >> > > > > > > > > > > Patreon: * >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=%2BYYs6ucuVcxDBnsY%2BjPWNAhKsLBVTYWQLbIO%2F6iaze0%3D&reserved=0 >> > > > > > > > > > > < >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=%2BYYs6ucuVcxDBnsY%2BjPWNAhKsLBVTYWQLbIO%2F6iaze0%3D&reserved=0 >> > > > > > > >* >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > -- >> > > > > > > > > > Carlos Rovira >> > > > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=J1FV%2B%2B98n8X%2B63fllpZNMqVxwGiWKMZxcVmVWiQQq8w%3D&reserved=0 >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > -- >> > > > > > > > > >> > > > > > > > > Piotr Zarzycki >> > > > > > > > > >> > > > > > > > > Patreon: * >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=%2BYYs6ucuVcxDBnsY%2BjPWNAhKsLBVTYWQLbIO%2F6iaze0%3D&reserved=0 >> > > > > > > > > < >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=%2BYYs6ucuVcxDBnsY%2BjPWNAhKsLBVTYWQLbIO%2F6iaze0%3D&reserved=0 >> > > > > > > >* >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > > > > > > -- >> > > > > > > > Carlos Rovira >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284013217&sdata=J1FV%2B%2B98n8X%2B63fllpZNMqVxwGiWKMZxcVmVWiQQq8w%3D&reserved=0 >> > > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > -- >> > > > > > > >> > > > > > > Piotr Zarzycki >> > > > > > > >> > > > > > > Patreon: * >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > > > > > > < >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > > > > > > >* >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > -- >> > > > > > >> > > > > > Piotr Zarzycki >> > > > > > >> > > > > > Patreon: * >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > > > > > < >> > > > > > >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > > > > > >* >> > > > > > >> > > > > > >> > > > > > >> > > > > >> > > > > -- >> > > > > >> > > > > Piotr Zarzycki >> > > > > >> > > > > Patreon: * >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > > > > < >> > > > > >> > > > >> > > >> > >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > > > > >* >> > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > >> > -- >> > >> > Piotr Zarzycki >> > >> > Patreon: * >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> > < >> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.patreon.com%2Fpiotrzarzycki&data=02%7C01%7Caharui%40adobe.com%7Ca945ffe445614a538d4d08d664c13319%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636807178284023226&sdata=mrx6J9BeewcazF%2F6FE8xAZlfCB72VZC15zgvIOP1JEg%3D&reserved=0 >> >* >> > >> >> >>
