Great! More tests the better. I will switch to your branch as well when you make the changes.
Many Thanks for help with that. Let's see what's more comes on the road. :) Best, Piotr On Sat, Dec 22, 2018, 11:23 PM Greg Dove <[email protected]> wrote: > I already checked this against the app that we are working on, so feel free > to merge that in if it fixes the problem you were seeing, Piotr. > For the more general changes with dispatching from strand and avoiding > IEventDispatcher-ness , I can come back to that and try to do a refactor > sweep through these changes as discussed with Alex, and the other component > sets in a couple of weeks. But I will do that in a refactor branch. I'm not > using the other component sets at the moment, and although I know there are > example projects to check against, I think checking against a 'real-world' > app is also important. Maybe Harbs and any any others who perhaps may have > used Basic or Express etc in actual apps will be able to verify things for > those component sets in the refactor branch at the time, if they have been > using them. I will make a request for others to check things when I do > that. > > > > > On Sun, Dec 23, 2018 at 1:22 AM Piotr Zarzycki <[email protected]> > wrote: > > > Greg, > > > > I have fixed issues with navigation in my application code. I'm ok with > > changes in that branch. > > > > Thanks for all changes! > > Piotr > > > > sob., 22 gru 2018 o 10:18 Piotr Zarzycki <[email protected]> > > napisał(a): > > > > > Greg, > > > > > > In your app are you using navigation in that way? > > > Maybe I need to call some prevent method somewhere. > > > > > > Thanks, > > > Piotr > > > > > > On Sat, Dec 22, 2018, 9:57 AM Piotr Zarzycki < > [email protected]> > > > wrote: > > > > > >> Greg, > > >> > > >> Good news. I was able to build framework using ant and produce IDE > > >> artifacts. Tested your changes and looks good. However I see other > > issue. I > > >> have following code [1]. When I click on link in navigation (I'm > > listening > > >> on change event) - I'm trying to change view using > > ApplicationMainContent - > > >> it's navigates me to new website with new url instead changing view. > > >> > > >> I need to investigate why it is happen. Apart of that I believe we are > > ok > > >> with that branch. > > >> > > >> [1] https://paste.apache.org/UzJI > > >> > > >> Thanks, Piotr > > >> > > >> > > >> pt., 21 gru 2018 o 09:29 Greg Dove <[email protected]> napisał(a): > > >> > > >>> Ok Piotr, I'm not sure what is happening there. It does seem strange > - > > >>> shell.view.royale.Shell seems like a class and somehow has org > > >>> <http://shell.view.royale.shell.org/ > >.apache.royale.jewel.Application > > >>> appended to it. > > >>> > > >>> I don't think that is related to anything I did (and it works fine > > >>> against > > >>> the 'real-world' app I tested against - with maven build). Can you > > build > > >>> Tour de Jewel ok? > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Dec 21, 2018 at 9:04 PM Piotr Zarzycki < > > >>> [email protected]> > > >>> wrote: > > >>> > > >>> > Hi Greg, > > >>> > > > >>> > Thanks for your changes. Unfortunately I'm not able so far properly > > >>> build > > >>> > my real world app using Maven. I build Jewel module by Maven, so I > > have > > >>> > setup my app to be buildable with Maven. Unfortunately I'm getting > > >>> weird > > >>> > exception during running app. > > >>> > > > >>> > SimpleCSSValuesImpl.js:102 Uncaught TypeError: Cannot read property > > >>> > 'string' of undefined > > >>> > at > > >>> > > > >>> > > > >>> > > > org.apache.royale.core.AllCSSValuesImpl.org.apache.royale.core.SimpleCSSValuesImpl.init > > >>> > (SimpleCSSValuesImpl.js:102) > > >>> > at > > >>> > shell.view.royale.Shell.org > > >>> > .apache.royale.jewel.Application.set__valuesImpl > > >>> > (Application.js:311) > > >>> > at shell.view.royale.Shell.org.apache.royale.jewel.Application > > [as > > >>> > constructor] (Application.js:46) > > >>> > at Function.childCtor.base (base.js:2515) > > >>> > > > >>> > Above exception is not occurs when I'm building using Nightly. I > > >>> probably > > >>> > will have to build framework by ant and prepare IDE compatible > > >>> environment > > >>> > or will try to rebuild whole framework by Maven and try again. > > >>> > > > >>> > Thanks, Piotr > > >>> > > > >>> > czw., 20 gru 2018 o 10:49 Piotr Zarzycki < > [email protected]> > > >>> > napisał(a): > > >>> > > > >>> > > Hi Greg, > > >>> > > > > >>> > > Great news, cause I was going to look into that somewhere between > > >>> > > Christmas and New Year. I would be happy to test your changes! Do > > not > > >>> > > hesitate push it! > > >>> > > > > >>> > > Thank you so much! > > >>> > > Piotr > > >>> > > > > >>> > > czw., 20 gru 2018 o 10:39 Greg Dove <[email protected]> > > >>> napisał(a): > > >>> > > > > >>> > >> 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: > > >>> > >> >> > > > > > > > > > > > >>> > >>
