The change event is dispatched when a date is selected. That's the only public event. Due to the way the DateChooser is constructed, the header part (with the month selection buttons) updates the model which sends a "displayedMonthChanged" event. The view is looking for this event and then regenerates the data for the List displaying the month. Same for the year.
—peter From: Harbs <harbs.li...@gmail.com<mailto:harbs.li...@gmail.com>> Reply-To: "users@royale.apache.org<mailto:users@royale.apache.org>" <users@royale.apache.org<mailto:users@royale.apache.org>> Date: Thursday, October 26, 2017 at 1:41 PM To: "users@royale.apache.org<mailto:users@royale.apache.org>" <users@royale.apache.org<mailto:users@royale.apache.org>> Subject: Re: Convert s:DateChooser to js:DateChooser The DateChooser has both months and years. Presumably, the change event should apply to the specific date selected (although the event is actually called “selectedDateChanged”), while the “month" and “year” events are display events (hence the names displayMonthChanged and displayYearChanged). On Oct 26, 2017, at 7:41 PM, Piotr Zarzycki <piotrzarzyck...@gmail.com<mailto:piotrzarzyck...@gmail.com>> wrote: Peter, You have mention about monthChaned event. I didn't check myself, but in most of our components we are using only change event. It is probably quite common event in html world - What actually is doing change event in DateChooser? Maybe that is the answer for all changes? Thanks, Piotr On Thu, Oct 26, 2017, 18:14 Peter Ent <p...@adobe.com<mailto:p...@adobe.com>> wrote: After looking over what you want, I think this isn't falling into the PAYG philosophy. Most users of DateChooser won't need to dispatch a monthChanged event. The thing to do is subclass the DateChooserView and make that dispatch the monthChanged event. The Basic package is supposed to deliver the most common features with the least overhead. Sometimes the code we/I wrote isn't as performant as it could be, so that would be a PAYG improvement to make it smaller or faster (or there could be a bug in that an event that is supposed to be dispatched isn't). But adding more events and properties just enlarges the components which is not PAYG. If you think a particular property or event would benefit every user of the component, then we can have a discussion about adding that to Basic. On the other hand, the Express version of DateChooser could be extended to extras (like a monthChanged event) out of the box. And this probably is true of other requests for DateChooser. The Express package is meant to be a quicker way to get started with Royale since a number of the components there have more beads and features packaged into them; Express is not PAYG in that sense. We can also consider creating another package that tries to mimic old Flex as closely as possible. The bottom line is, we want to keep Basic really basic and provide the underpinnings for creating a fast and fluid application, adding to it only when and where necessary. A lot of that may fall onto the shoulders of app developers, more so than it did with Flex. ‹peter On 10/26/17, 4:46 AM, "doug777" <doug777...@gmail.com<mailto:doug777...@gmail.com>> wrote: >Hey Justin, > >That's fantastic. Big thank-you from me. > >Doug > > > >-- >Sent from: >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-roy >ale-users.20374.n8.nabble.com<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fale-users.20374.n8.nabble.com%2F&data=02%7C01%7C%7C3160a263993c4b03bfb708d51c98df32%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446365258826007&sdata=PXipcmb95EZd8pRtlA7JHvIDexMLiCQqVLkUIhwpAb8%3D&reserved=0>%2F&data=02%7C01%7C%7Ce6634fbdf06c4f411e7508d >51c4e1b43%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446044150566225& >sdata=CjeJaHA3joQpC3ChCzaix7%2BZvg97Gm3P5lSUXwZlBBw%3D&reserved=0
