This content has been marked as final. Show 3 replies
Certainly that is ok. varInComponent is known as a property of the component. You will want to make that var "public", though
You can also use getter and setter functions if you want more control over what happens when that value is set, for example, if you wanted to run some other code.
Another way is to pull the data into the component using Application.application.myPublicMember;
Still another way is to use events to listen for a change of a value in the main app. then you can access any public member of the app using the event.target reference.
You can also pass data in custom events.
Yet another solution is to use a data model component, often implemented as a "singleton". Such a model component can be accessed anywhere in the app, and can be used to invoke bindings or trigger ChangeWatchers.
You have many options.
As much as everyone likes using singleton's in their apps, I find its use completely screwing up good design for app reusability. I know this sounds counterintuitive, but I've got a full Caringorm app here. Now I am in the position of needing to have 2 of them in another app. Think media player: The media player was written using cairngorm and works all fine and dandy on its own. But as soon as you try to make it a module/include it on a page that has 2 media players, all that singleton model locator has bought you is not much.
Cairngorm and a lot of these other MVC frameworks make a lot of assumptions about the types of apps you are creating: single instance standalone for the most part. Which is just a bad assumption in my experience...mashing things up into a bigger app is a fairly common occurence.
For me, to get around the limitations, I have to use SWFLoader and a bunch of other stuff to load my media player swf into another flex swf.
Of course, the importance of "resusability" is another assumption.
There is no single "framework", or "pattern" or "methodology" or "best practice" that is correct for all.
Always proceed with eyes open.