we can refer to objects that are outside the component but in the main application.
There are two ways for that:
1.We can create a single ton class and then using the object of the single ton class (for the main of the application), then we can use objects by using the object of this single ton class, we can access any object which is the part of main application and is outside the component.
2. Other way around is just use Application.application in the script to access the objects of the application which are outside the component but within the main application.
Hopfully, this will serve as an answer to your question.
Can you tell me what you are refering to when you say "ton class"?
Sorry i mean to say "SingleTon Class";
It is class which returns only one object and that object is the object of the class itself;
I believe he meant "singleton".
right I meant singleton class
If this app gets too big , the singleton design pattern atrocity will be your downfall.
Warning I am expressing my opinion on how singletons are dangerous. Especially since noob architects have an unholy affinity for them in solving ALL programming problems.
I feel singletons are bad for a number of reasons. This doesn't mean they don't have a place , but so do guillotines and rabid chimpanzees. The singleton creates a "global" variable which is available to all classes in the application. As the singleton becomes a dependency in multiple classes , it becomes hard to track the state during the execution of a program. This leads to bugs that are hard if not impossible to track down , due to the fact that the value in question could have been changed anywhere at anytime by any accessible object or process, possibly depending on the EXACT use-case scenario ( i.e service call changes singleton data A , user clicks B which is bound to singleton data , view C which reads singleton data gets broken , whereas any other order works fine).
The worst thing , is that it is easy to overdose on singletons especially if the architects/developers don't have the hardware between the ears to keep the singletons in their place. On one of my contracts , singletons where used EVERYWHERE. Sending service calls , receiving service call results , handling user gestures , containing model collections , dispatching events , controlling views etc etc. The worst problem culminated with the fact that PureMVC was being used , and instead of initializing the mediator with a view component , it was initialized with a singleton. You can imagine the countless adventures you can have when your controller has to communicate with the view , through an object which is being manipulated by other classes.
Long story short , the singleton in real-world scenarios can cause spectacular class dependencies leading to "Action-at-a-distance". The end result is that if one developer touches the singleton , all the other use cases can become unpredictable (think Heisenberg Principle , "100% sure it works here in this case , but 0% sure it works everywhere else in other cases"). Since the global state is a big unknown , unit testing becomes less-useful because your "unit" test has to work with a global variable.
Once again , this is my experience. I'm sure there is someone out there who will counter that singletons are the best things SVN , but once you see the dark-side , you will never want to go back.