8 Replies Latest reply on May 29, 2010 12:43 AM by Rdsingh Ldh

    Working with <mx:Component>


      I have a component embedded in my main mxml application but want to reference objects which are outside the compenent but still part ot the application.  Can anyone tell me how this is done?  I have attached the mxml code for the components below.



      <mx:Component className="infoWindowRenderer"




      <mx:VBox backgroundColor="0xEEEEEE">


      <mx:CurrencyFormatter id="infoCurrencyFormatter"













      <mx:Label text="TIP ID: {data.PROID}" fontWeight="bold"/>

      <mx:Spacer width="100%"/>


      <mx:Label text="Agency: {data.PROGRAMMIN}"/>

      <mx:Label text="Abbrev. Description:" paddingBottom="0"/>








      <mx:Label text="Work Being Done: {data.ALL_WORK_T}"/>

      <mx:Label text="Current Funding: {data.MYBONLY}"/>

      <mx:Label text="Completion: {data.COMPLETION}"/>

      <mx:Label text="Type: {data.OVERALL_TY}"/>

      <mx:Label text="ARRA: {data.MODELED}"/>

      <mx:Label text="Contact: {data.CONTACT}"/>

      <mx:Label text="Contact At: {data.CONTACT_AT}"/>

      <mx:Label text="Total Cost: {infoCurrencyFormatter.format(data.TOTAL_COST)}"/>



        • 1. Re: Working with <mx:Component>
          Rdsingh Ldh

          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.

          • 2. Re: Working with <mx:Component>
            PegLeg7 Level 1

            Can you tell me what you are refering to when you say "ton class"?

            • 3. Re: Working with <mx:Component>
              Rdsingh Ldh Level 1




              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;

              • 4. Re: Working with <mx:Component>
                Ansury Level 3

                I believe he meant "singleton".

                • 5. Re: Working with <mx:Component>
                  Rdsingh Ldh Level 1

                  right I meant singleton class

                  • 6. Re: Working with <mx:Component>
                    UbuntuPenguin Level 4

                    If this app gets too big , the singleton design pattern atrocity will be your downfall.

                    • 7. Re: Working with <mx:Component>
                      Rdsingh Ldh Level 1

                      Hey UbuntuPenguin


                      How can singleTon be downfall in the application if the app is too big??


                      would u explain me the same??

                      • 8. Re: Working with <mx:Component>
                        UbuntuPenguin Level 4

                        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.