8 Replies Latest reply on Jun 28, 2006 1:47 PM by njadobe

    Some ideas based on Visual Studio and ASP.NET

    Michiel1978
      Here's some ideas I took from Visual Studio and ASP.NET:

      A contextual menu on a placed control in the design view?

      Code behind, so an MXML-file has a twin brother that is an AS-file, same class, controls are available by ID in the AS, methods are available in the MXML?

      'Better' code hinting, so most recently or most likely to be used comes first, already used attributes don't show up again, that sort of stuff.
        • 1. Re: Some ideas based on Visual Studio and ASP.NET
          ntsiii Level 3
          Visual Studio is about version 10 from Microsoft. Flex Builder (Eclipse) is open source and still version 0 from Adobe.

          The money spent developing VS is, well, more, than the money spent on Flex Builder.

          You may get your wishes someday, and I might still get to visit the moon in my lifetime.

          Tracy
          • 2. Re: Some ideas based on Visual Studio and ASP.NET
            chrisichris
            quote:


            Code behind, so an MXML-file has a twin brother that is an AS-file, same class, controls are available by ID in the AS, methods are available in the MXML?


            You can do that with <script src="scriptbehind.as"/> where the scriptbehind is an the actionscript file and gets imported. You can also use the include statement. It's documented here http://livedocs.macromedia.com/labs/1/flex20beta3/00000456.html .

            However coming from JavaLand I don't realy like this feature because now you have two files which share the same scope and that is in my experience harder to maintain and read (always switching between editors) than even having all in one. . I am currently experiementing with something else.

            Disclaimer: I am not experienced with ActionScript/Flex at all but I think this one is better (advices are of course very wellcome):

            Currently I prefer to cerate a class which contains the eventhandlers and exposes bindable properties and does encapsulte it's code nicely. The MXML file uses an instance of this class for event-registrations and property-binding. The backing class does know nothing about the MXML file (has no reference to it). It just exposes properties and fires events. This way the two files can internally be modified independently. Especially the MXML file can be modified and you are sure you never break code in the backing class. It is also easier to test.

            • 3. Re: Some ideas based on Visual Studio and ASP.NET
              inlineblue Level 1
              quote:

              Originally posted by: chrisichris
              Currently I prefer to cerate a class which contains the eventhandlers and exposes bindable properties and does encapsulte it's code nicely. The MXML file uses an instance of this class for event-registrations and property-binding. The backing class does know nothing about the MXML file (has no reference to it). It just exposes properties and fires events. This way the two files can internally be modified independently. Especially the MXML file can be modified and you are sure you never break code in the backing class. It is also easier to test.


              But then wouldn't you still need AS code in the MXML file? At some point your AS code needs to refer to visual assets declared by the MXML, right?
              • 4. Re: Some ideas based on Visual Studio and ASP.NET
                Graeme Harker Level 1
                For what it's worth, I agree with you (but anybody would agree with you who's grown up with Visual Studio). The fact that my Flex.NET blog is the third most visited Flex site agregated on MXNA over the last month reflects that there's a significant interest in making Flex work with .NET but Adobe seems to have a bit of a blind spot in the .NET space so don't expect much from Adobe on this front. Perhaps one day someone will write a Visual Studio plug-in that works with the Flex SDK so we won't have to struggle with Eclipse.
                • 5. Re: Some ideas based on Visual Studio and ASP.NET
                  Graeme Harker Level 1
                  For what it's worth, I agree with you (but anybody would agree with you who's grown up with Visual Studio). The fact that my Flex.NET blog is the third most visited Flex site agregated on MXNA over the last month reflects that there's a significant interest in making Flex work with .NET but Adobe seems to have a bit of a blind spot in the .NET space so don't expect much from Adobe on this front. Perhaps one day someone will write a Visual Studio plug-in that works with the Flex SDK so we won't have to struggle with Eclipse.
                  • 6. Re: Some ideas based on Visual Studio and ASP.NET
                    chrisichris Level 1
                    quote:

                    Originally posted by: inlineblue
                    quote:

                    Originally posted by: chrisichris
                    Currently I prefer to cerate a class which contains the eventhandlers and exposes bindable properties and does encapsulte it's code nicely. The MXML file uses an instance of this class for event-registrations and property-binding. The backing class does know nothing about the MXML file (has no reference to it). It just exposes properties and fires events. This way the two files can internally be modified independently. Especially the MXML file can be modified and you are sure you never break code in the backing class. It is also easier to test.


                    But then wouldn't you still need AS code in the MXML file? At some point your AS code needs to refer to visual assets declared by the MXML, right?


                    Depending how much coupling you want you can pass in through function parameters what the functions need, or you can provide the constructor of the backing class with what it needs. You can also provide in the constructor the whole MXML and than access the visual assets from there (they are public ).

                    ie.
                    [mxml file 'editarticel.mxml']
                    <mx:Application ... applicationComplete="initApp()">
                    //all code needed
                    private var bc:EditArticelBC;
                    private function initApp():void {
                    bc = new EditArticelBC(this);
                    }
                    //only mxml comes here
                    .....
                    <mx:TextInput id="cArtPriceTI" text="{bc.articel.price}"/>
                    <mx:Button label="New" id="cArticelNewBtn" click="bb.newArticel()"/>
                    </mx:Application>

                    [AS class file]
                    package {
                    public class EditArticelBC {
                    [Bindable] public var articel:Articel;
                    private var mx:editarticel;

                    public function EditArticelBC(edp:editarticel) {
                    mx = edp;
                    }

                    public function newArticel() {
                    //acess the TextInput
                    var s:String = mx.cArtPriceTI.text;
                    articel = new Articel();
                    .....
                    }
                    }
                    }

                    Of course if you follow this pattern you are very tightly coupled but you can move all your code out of the MXML. I guess exactly like in your proposed case? You have todo more typing ("bc." and "mx.") but therefore you will always know which file defines what, what I like very much.

                    PS.: Something I'd like is a code-formatter for the mxml, which makes sure that the id attributes are always straight after the tag name and a fly-over window which shows the documentation for properties, functions etc. on mouse-over and autocompletiton.

                    There are other strong features of Java-Eclipse (like refactoring, dynamic compilation, code-hints, auto-fixes) which Adobe might one time implement, but those are not absolutely necessary and as ntsii said they also took their time to come to Eclipse. FlexBuilder realy rocks.
                    • 7. Re: Some ideas based on Visual Studio and ASP.NET
                      chrisichris Level 1
                      Sorry I made a mistake in the above code:

                      you have to make the bc var in your mxml bindable.

                      mxml:
                      [Bindable]
                      private var bc:EditArticelBC;
                      • 8. Re: Some ideas based on Visual Studio and ASP.NET
                        njadobe
                        Hi Michiel,

                        Thanks for the suggestions. We definitely want to continue improving the intelligence of our code hinting, and coming up with better patterns for separating code from presentation.

                        On your design view comment, what kinds of things would you find useful on the context menu in design view?

                        Thanks,

                        nj
                        Flex Builder team