What is the best practice - singleton & components

Question

I am converting a Flex 3.5 project to 4.0 and have hit a few snags.  One issue that I'm not sure about is the way to address labels.  We switch between English and Spanish if you click a button.
I decided to make the component's labels all based on a singleton class.  The label values there would alter between the languages.  I made them bindable in the singleton.
1) should I directly associate the labels with the singleton "get" method for the appropriate label
2) should I have a bindable variable in the component that is set from the singleton "get" method and then associate that variable with the various labels
The first method saves a variable in the component while the second seems slightly more readable.
Way one:
        [Bindable]
        protected var childSupLabel:String = getLabels.getExpChildSupLabel();
        <DHSclasses:AutoResizableTextArea
              id="courtOrderedChildSupportLabel"
              text="{childSupLabel}"
              autoResize="true"
              editable="false"
              tabEnabled="false"
              textAlign="right"
              wordWrap="true"
              left="5"
              width="89%"/>
Way two:
                <DHSclasses:AutoResizableTextArea
                    id="elderlyMedicalExpensesLabel"
                    text="{getLabels.getExpMedExpLabel()}"
                    autoResize="true"
                    editable="false"
                    tabEnabled="false"
                    textAlign="right"
                    wordWrap="true"
                    left="5"
                    width="89%"/>

Answer 1

Jerry,
I keep asking for a simple test case.  It should only take an hour or so to create, much less time than you’ve spent and we’ve spent trying to guess how your code works from snippets.  There are two common approaches to creating such a test case.  One is to start from an empty app and copy in a few things at a time, another is to start with a copy of the current app and comment stuff out.  A test case is unambiguous.  I put it into the debugger and the problem will appear and we can make explicit recommendations.  Emails and code snippets are way to ambiguous.  Flex isn’t particularly hard, and the folks on the forum are quite helpful, but you have to help us help you by removing ambiguity.  I know the temptation is to hope that spending 30 seconds to send a snippet and question will save you from the hour of creating the test case, but the way I see it, there are several advantages to taking the hour to prepare the test case.  They are:
    -you might be waiting that hour for a response anyway,
    -in preparing the test case, a significant number of people discover the solution on their own, long before the hour is up
    -the chances you’ll get bad advice goes way down.
    -the inability to create a test case quickly serves as an indicator that your app is not modular enough
I have touched many of the support issues you’ve logged via your support contract with Adobe.  Their process is also quite similar.  The support tech will ask for a simple test case.  By using the Adobe Support, you will get guaranteed, dedicated responses.  That’s what you’ve paid for.  Use it to your advantage.
You are welcome to fire off the quick 30-second question, but when a responder asks for a test case, it is time to take the time to create one.  Also, you started your last reply by saying “I listen”, but Amy and I both have mentioned the Array event dispatching issue and I have asked for a test case several times.
I will repeat a guess one more time as to the nature of this particular problem, which I described in an earlier response, then I will no longer respond to this thread until I see a simple test case posted.  And that is: The variable for the English class is not being initialized before it is being used.  When you step through in the debugger, all get functions in the class get called in order to populate the debugger’s variables pane, and that can cause initialization of values to occur in a different order than when you just run the app.  Variables with metadata are implemented as get functions so they can be affected.
Adobe wants all of our customers to continue to use Flex.  Flex’s main advantage is reduced development costs.  The best way to show your management the advantages of Flex is the continue to improve your development practices to be more efficient, and that includes the development of modular code, use of existing features like the ResourceManager instead of trying to develop your own, and a refinement of the way you use resources like forums, the internet, and Adobe Support in getting your application ready for production.
Going from Flex 3 to Flex 4 is a big change in development practices if you want to use the Spark components.  The principle behind Spark was to enable designers to control every aspect of the visuals without having to learn about ActionScript and CSS styles.  If that principle does not provide a significant advantage to you, then the MX components may make you happier.  Spark also provides a consistent skinning workflow.  If you don’t do much custom skinning because everything you need to change is available via CSS, then you also have less of a reason to use the Spark components. You can still move to Flex 4 and use the MX components and still get the advantages of two-way data binding, the new states syntax, and more.  Just use the MX components and specify the Halo theme, as I have suggested before.
-Alex