How to call a remoteObject method that is outside of my TitleWindow component on Flex?

Question

I have a TitleWindow component. It allows me to save some data provided through 3 TextInput .

That data "fills" a DropDownList which is in another TitleWindow component, not inside the original one.

How can I call the remoteObject method that fills (or refresh) my DropDownList ?

Any ideas will be appreciated!

Answer 1

You can simply use a Singleton as a model if you'd like, this will allow you to share data, but beware keep data only that needs to be shared in here or it will just become a global nightmare.

Using a singleton means you'll have a class that you can only ever have one instance of. If you put properties in that class any time you reference it it will be the same memory throughout the application execution.

http://blog.pixelbreaker.com/actionscript-3-0/as30-better-singletons

Marking the singleton class or individual properties as Bindable will make it so you can watch for the changes and call a function.

http://livedocs.adobe.com/flex/3/html/help.html?content=databinding_8.html

Putting this together you have something like this:

[Singleton.as]

package
{
    [Bindable]
    public class Singleton
    {
        public var myListData:Array;
        public static var instance:Singleton;
        public static function getInstance():Singleton
        {
            if( instance == null ) instance = new Singleton( new SingletonEnforcer() );
            return instance;
        }

        public function Singleton( pvt:SingletonEnforcer )
        {
            // init class
        }
    }
}

internal class SingletonEnforcer{}

Somewhere else you want to get a handle on this

[MyTitleWindow.as]

var instance:Singleton = Singleton.getInstance();
instance.myListData = [1,2,3];

[MyTitleWindowWithAList]

var instance:Singleton = Singleton.getInstance();
BindingUtils.bindSetter(funcUpdateList, instance, "myListData");

private function funcUpdateList(data:Object)
{
      myList.dataProvider = data as Array;
}

Another option is to create an event that carries your data payload, dispatch that event from the first title window, and capture it, the problem with this is you have to register the listeners on the PopUpManager or SystemManager I believe because the TitleWindow's aren't direct children of the Application I believe.

Answer 2

Singletons are a bad idea and you should not get in the habit of using them. Instead, just dispatch an event from the View and catch it from something else that has access to your Service object.

Note that your Service should not be part and parcel of any View--the responsibility of a View is displaying data and capturing requests from the user to change the data, not communicating with a server.

For examples of an application written with this pattern in mind, check out

• [Refactoring with Mate] ( http://www.developria.com/2010/05/refactoring-with-mate.html ) - The example has View source enabled
• The same application done with RobotLegs - again, View Source is enabled.

Note that these are written against some popular frameworks, but they are written in such a way that you can easily replace that framework code with something else, even your own code .

For reference, here is the naiive implementation , where the service layer is being called directly in the Views. You couldn't call a different service without changing the Views, though the use of the static service means you could use it from elsewhere.

That static usage survived into the later examples, though today I would never write something depending on a globally accessible object. In part this is because I discovered Test Driven Development, and it is impossible to replace the "real" static object with an object that lets you isolate what you are testing. However, the fact that most of the code in the 2 "better" examples is insulated from that static object means that it is trivial to replace it with one that is provided some other way.

The lesson here is if you're going to use static, global objects, lock them away behind as much abstraction as you can. But avoid them if you're at all interested in best practice. Note that a Singleton is a static global object of the worst kind.