views:

119

answers:

1

I am looking to subclass RemoteObject. Instead of:

<mx:RemoteObject ... >
    <mx:method ... />
    <mx:method ... />
</mx:RemoteObject>

I want to do something like:

<remoting:CustomRemoteObject ...>
    <mx:method ... />
    <mx:method ... />
</remoting:CustomRemoteObject>

where CustomRemoteObject extends mx.rpc.remoting.mxml.RemoteObject like so:

package remoting
{
    import mx.rpc.remoting.mxml.RemoteObject;

    public class CustomRemoteObject extends RemoteObject
    {
        public function CustomRemoteObject(destination:String=null)
        {
            super(destination);
        }
    }
}

However, when doing so and declaring a CustomRemoteObject in MXML as above, the flex compiler shows the error:

Could not resolve <mx:method> to a component implementation

At first I thought it had something to do with CustomRemoteObject failing to do something, despite that (or since) it had no change except as to the name. So, I copied the source from mx.rpc.remoting.mxml.RemoteObject into CustomRemoteObject and modified it so the only difference was a refactoring of the class and package name. But still, the same error.

Unlike many MXML components, I cannot cmd+click <mx:method> in FlashBuilder to open the source. Likewise, I have not found a reference in mx.rpc.remoting.mxml.RemoteObject, mx.rpc.remoting.RemoteObject, or mx.rpc.remoting.AbstractService, and have been unsuccessful in find its source online.

Which leads me to the questions in the title:

  • What exactly is <mx:method>? (yes, I know it's a declaration of a RemoteObject method, and I know how to use it, but it's peculiar in regard to other components)
  • Why did my attempt at subclassing RemoteObject fail, despite it effectually being a rename? Perhaps the root, why can mx.rpc.remoting.mxml.RemoteObject as an MXML declaration accept <mx:method> child tags, yet the source of said class cannot when refactored in name only?
  • A: 

    The syntax you're looking at ('mx:method') is a way to define properties in MXML instead of in ACtionScript. IF this were extending a "standard" UIComponent, you'd do this:

    <remoting:CustomRemoteObject ...>
        <remoting:method ... />
        <remoting:method ... />
    </remoting:CustomRemoteObject>
    

    However, since method is not a property on RemoteObject, there is probably some compiler magic behind the scenes. I bet it turns the "methods" tags into the operation array.

    You'll probably need to do that manually, something like this:

    <remoting:CustomRemoteObject ...>
      <remoting:Operations>
        <remoting:method ... />
        <remoting:method ... />
       </remoting:Operations>
    </remoting:CustomRemoteObject>
    

    But, you may have to parse through code and/or run in debug mode and/or review the generated actionscript to figure out exactly what is going on and how "method" is turned into the operations array.

    I thought the source of the remoting classes was available in the SDK; but perhaps just the open source SDK not the Adobe supported SDK. You can download the open source SDK at opensource.adobe.com

    Half of this post is guessing.

    www.Flextras.com
    I think you're right about the compiler magic. There is an operations setter in AbstractService with the comment, "The Operations array is usually only set by the MXML compiler if you create a service using an MXML tag."Furthermore, that setter takes an Object and loops the properties of it taking the property name to be the operation name and the property value to be an AbstractOperation.The part that still confuses me is how an array of <mx:method> triggers the operations setter, and why the compiler error in a subclass of RemoteObject.
    Ryan Wilson