Hi Greg, I'm progressing with some application and discovered that we are dispatching CHANGE event from here [1] - I'm wondering whether we really need it. Model is being update in that operation - I believe it should be enough.
Just to make it clear there is no issue - I mean CHANGE event doesn't fire two times etc. because of that. I didn't check whether it makes any difference. [1] https://bit.ly/2GeQ5En Thanks, Piotr pon., 24 gru 2018 o 11:51 Piotr Zarzycki <[email protected]> napisał(a): > Hi Carlos, > > You have less events flying around the head. :) > > Piotr > > On Mon, Dec 24, 2018, 11:32 AM Carlos Rovira <[email protected]> > wrote: > >> Thanks Piotr and Greg, >> >> I'm catching up with all the thread. I'm testing and seems all is ok, >> Seems >> Jewel List, ComboBox, DropDownList are now much better and robust :) >> Great work! Thanks for working on this! :) >> >> Carlos >> >> >> >> >> >> El dom., 23 dic. 2018 a las 9:16, Piotr Zarzycki (< >> [email protected]>) >> escribió: >> >> > 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 >> > > > >>> > >> >> > > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
