Using IntelliJ IDEA 12 for Flex Development

Question

I have been using Flex / Flash Builder for a number of years. The latest release of Flash Builder (4.7) seems to come with quite a few problems, the biggest of those being:

Answer 1

Since I can't think of a gentle way of putting this, I'll just be blunt: I'm afraid the reason only two people think this is a critical bug, is that most seasoned Flex developers will agree that using <fx:Script source="some_file.as"/> is bad practice.
You effectively create two files that represent one class. From a readablity POV, which you seem concerned about, that's not a good move. One of these files (the .as file) is just a bunch of functions that cannot exist in their own right: they are tightly coupled to another file/class, but just looking at the .as file there is no way of knowing which class it is coupled to. Of course you can use some kind of naming convention to work around this, but in the end ActionScript/Flex is supposed te be used as a statically typed language, not a scripting language relying on mixins and naming conventions (don't get me wrong: I'm not saying scripting languages are bad practice; it's just not how ActionScript was conceived).

So what are your alternatives?
I suppose the main reason behind this construct is that you wish to separate MXML from ActionScript code, or in more abstract terms: separate the view from the logic. Fortunately this can be achieved in a few other, cleaner ways. Which solutions are available to you depends whether we're talking Flex 3 (or earlier) or Flex 4. I realise that you may not have time to refactor your code to one of the proposed solutions, but I didn't want to leave you with just a "that's not good practice" answer.

Flex 3 (mx)

Code behind: A lot of developers used the so-called "code behind" pattern to separate their logic from their view. You can find plenty of information on the topic by Googling "flex code behind". I don't need to repeat all that in here. I'm not much of a fan of the concept because it relies heavily on inheritance and the two resulting classes are still pretty tightly coupled, but at least we're talking two classes. If you design your architecture well, you may even be able to reuse some of your base classes.

Compose model en controller: I used to create a separate "presentation model" class and a "controller" class for each MXML view and then use it something like this:

<!--MyView.mxml-->
<mx:VBox>
    <m:MyModel id="model"/>
    <c:MyController model="{model}" view="{this}"/>
    ...
</mx:VBox>

MVC purists won't like this, but it worked pretty well for me in thencontext of Flex applications.
Later when Direct Injection supporting frameworks (like Parsley) made their appearance, I could use injection to wire all those classes instead of hard-wiring them like in this example.

MVC frameworks: My knowledge of this topic is sparse (because in my opinion Flex is a very decent MVC framework that requires no third-party additions, but that's another disussion), but in short: they can help you separate logic from view in a clean way.

Flex 4 (Spark)

With Flex 4, the Spark skinning architecture was introduced, which allows for very nicely separated view and logic. You create a so-called 'host component' class in plain ActionScript, which contains all of the behavioural code, and a 'skin' class in MXML which defines the visual representation of the component. This makes designing reusable components very easy.

As per your request, here's a simplified example of how you might use Spark skinning to create your signup form.
Let's start with the skin class since it's easy to understand. It's just a form with some input fields. The HostComponent metadata tells the skin it's supposed to work together with the SignUp host component.

<!--SignUpSkin.mxml: the visual representation-->
<s:Skin xmlns:fx="http://ns.adobe.com/mxml/2009"
        xmlns:s="library://ns.adobe.com/flex/spark">

    <fx:Metadata>
        [HostComponent("net.riastar.view.SignUp")]
    </fx:Metadata>

    <s:Form>
        <s:FormHeading label="Sign up"/>

        <s:FormItem label="User name">
            <s:TextInput id="userInput"/>
        </s:FormItem>

        <s:FormItem label="Password">
            <s:TextInput id="passwordInput" displayAsPassword="true"/>
        </s:FormItem>

        <s:Button id="submitButton" label="Submit" 
                  enabled="{hostComponent.canSave}"/>
    </s:Form>

</s:Skin>

And now the host component in pure ActionScript. It has to extend SkinnableComponent to be able to use our skin (there's also SkinnableContainerwhich I've just recently explained in this question: Flex mxml custom component - how to add uicomponents?, but we won't be needing that here).

public class SignUp extends SkinnableComponent {

    [SkinPart(required="true")]
    public var userInput:SkinnableTextBase;

    [SkinPart(required="true")]
    public var passwordInput:SkinnableTextBase;

    [SkinPart(required="true")]
    public var submitButton:IEventDispatcher;


    [Bindable]
    public var canSave:Boolean;


    override protected function partAdded(partName:String, instance:Object):void {
        super.partAdded(partName, instance);

        switch (instance) {
            case userInput:
                userInput.addEventListener(TextOperationEvent.CHANGE, 
                                           handleUserInputChange);
                break;
            case passwordInput:
                passwordInput.addEventListener(TextOperationEvent.CHANGE, 
                                               handlePasswordInputChange);
                break;
            case submitButton:
                submitButton.addEventListener(MouseEvent.CLICK, 
                                              handleSubmitButtonClick);
        }
    }

    private function handleUserInputChange(event:TextOperationEvent):void {
        validateUsername(userInput.text);
    }

    ...

}

What's important here?
The variables marked as SkinPart will automatically be assigned the components with the same id that exist in the Skin you just created. For instance <s:TextInput id="userInput"/> will be injected into public var userInput:SkinnableTextBase;. Note that the type is different: SkinnableTextBase is the base class of TextInput; this allows us to create another skin with e.g. a TextArea instead of a TextInput and it'll work without touching the host component.
partAdded() is called whenever a SkinPart is added to the display list, so that's where we hook up our event listeners. In this example we're validating the username whenever its value changes.
When the validation is done, you can simply set the canSave property to true or false. The binding in the skin on this property will automatically update the Button's enabled property.

And to use both of these classes together:

<v:SignUp skinClass="net.riastar.skin.SignUpSkin"/>

Answer 2

I actually have become quite fond of using RobotLegs.

In my MXML views I try to keep all logic outside of the MXML and simply dispatch events out to the mediator. From there I can put code in the mediator to the heavier AS needed.