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 <aha...@adobe.com.invalid> 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" <greg.d...@gmail.com> 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.
>
>
>
