Some thoughts about Flex DataBinding code generation: Binding was considered a performance problem in Flex and every time I looked into it I came away with the idea that by having a better component lifecycle and different kinds of binding instances that are smart about the lifecycle and scenario that we would have better performance. Flex evaluated the bindings many more times than was necessary in many cases. And also, without the "priority" option in EventDispatcher, we can't always get bindings to evaluate before/after other event handlers.
So that's why in Royale, there is an ItemRendererDataBinding class that knows to wait for the data property to be set in the item renderer because that's really the first time it makes sense to evaluate bindings in an item renderer. And why there is in "initBindings" event in Royale Container. So if there are binding bugs in Royale, I'd rather that we step back and look at the lifecycle and scenario and consider when the optimal time is to evaluate (or re-evaluate) bindings instead of redundantly evaluating bindings like in Flex. My 2 cents, -Alex On 2/6/20, 11:48 PM, "Greg Dove" <[email protected]> wrote: I will be doing some other comparisons with Flex soon for Bindings, so I might be able to do that actually. I will probably just create an issue and note things down if I do that and only come back to them later. I did work on something for bindings related to the needsEventDispatcher stuff sometime in the distant past, I think adding that part might not be too difficult. The other thing I wonder about is the change that happened between Flex3 and Flex4 with the addition of fx:Declarations for non-visual instances. iirc this was only inside mxml subclasses of visual components. I was able to put: <business:Services id="services" /> in my test project View alongside all the other top level visual element children. I think for Flex 4 that should be inside fx:Declarations, but it seems to work Flex3 style in royale - is that correct? not something critical... just wondering about it.... On Fri, Feb 7, 2020 at 7:29 PM Alex Harui <[email protected]> wrote: > OK, thanks for figuring it out. > > I'm not familiar with this scenario at all. My main goal was to debug the > data stream since most folks aren't familiar with it. > > It is true that, currently, to be an MXML tag you have to implement > certain methods. Maybe that will change someday based on what I learn in > the "has" experiment. > > If you have time to explore further, I suppose you could compile with Flex > and the -keep option and see if there are other transformations in the > generated AS. > > Thanks, > -Alex > > On 2/6/20, 10:11 PM, "Greg Dove" <[email protected]> wrote: > > This is related to compiler changes following a specific request in > users > list. > Changes were made to the compiler to help cairngorm ServiceLocator > work > in mxml. > > > @aharui : > > there was a change that added the following to an mxml subclass of > ServiceLocator in a local test project (GithubCommitsViewer): > > this.generateMXMLAttributes > ([2, > 'configuratorService', > false, > [mx.rpc.http.mxml.HTTPService, 2, 'id', true, 'configuratorService', > 'resultFormat', true, 'text', 0, 0, null], > 'commitsService', > false, > [mx.rpc.http.mxml.HTTPService, 2, 'id', true, 'commitsService', > 'resultFormat', true, 'text', 0, 0, null], > 0, > 0 > ]); > > But the ServiceLocator class does not implement the > generateMXMLAttributes > method. > So I can manually implement it on the original class (although this > seems > not necessary in Flex), like so: > > public function generateMXMLAttributes(descriptor:Array):void{ > MXMLDataInterpreter.generateMXMLProperties(this, descriptor); > } > > > But that alone was not enough. I also had to change the original > ServiceLocator class to extend from royale EventDispatcher because it > was > not being automatically 'upgraded' by the compiler to EventDispatcher > (like > Bindable does for regular actionscript VO classes, for example). > Without > this change the 'id' properties being set throw errors when the > generated > setter code tries to dispatch 'valueChange'. > > So the good news is I can get it to work. But it seems like we have > some > more things to address here to get it to automatically 'upgrade' the > mxml > definitions similar to Flex. > > >
