Re: fx:Declarations. I don't recall the exact reasons why that happened in Flex 4. It might have been for Spark Skinning where the children have to be passed down to the skin, but it might have been a performance optimization where an array of children is built and passed to the skin and not some other requirement. I think our MXMLDataInterpreter is tolerant of Flex 3 patterns because we don't build out that array, the children are parented as they are created and if the instance isn't an IChild then we don't try to parent it. Maybe if we see that is a performance issue that we'll get stricter about it.
HTH, -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. > > >
