4 Replies Latest reply on Jul 6, 2009 1:01 AM by Jason Villmer


    Jason Villmer

      Since I made the decision to explore Flex as a development tool, I've been continually astounded by the sheer power of the application. In the beginning, the migration from the Flash IDE to Flex seemed daunting. The further I went, however, the more incredible it revealed itself to be. Ideas could now be realized quickly and easily, allowing more time to be creative instead of being wrapped entirely in technical puzzles. Then, on top of that, we could include other technologies such as Papervision, Ribbit and so forth. Combine all this with the additional ability to skin our application and you've got nothing short of great.


      Now, I still consider myself a novice in Flex, despite putting in a lot of hours learning and working with the application. That is why it is becoming somewhat frustrating to see that with Flash Builder, or a new SDK (in Flex Builder) things begin to break apart. This is to be expected and I understand this, however.. I won't give a lengthy explanation of the obstacles I've had to overcome to migrate (or fix) my application to Flash Builder 4, or a newer SDK, but I believe, after all has been said and done, Adobe should consider including a Migration Assistant/Wizard into the Flash Builder 4 application. This would be for developers who have worked exclusively with Flex Builder 3.3 (and perhaps a lower SDK such as version and are attempting to import that project, CSS styles and all, into Flash Builder 4. Just something that would 'update all necessary elements' necessary to just 'make it work'. There could be prompts to ask if the user wants to update various aspects of the application and formally turn it into an exclusive Flash Builder 4 project.


      Just a thought.

        • 1. Re: FORMAL REQUEST
          andre49 Level 1

          Hi Jason,


          Completely  agree that Adobe should consider including a Migration Assistant/Wizard into the Flash Builder 4 application.


          Howevver, as an Action Script 3 apprentice guru, I am very disappointed with FlashBuilder 4.


          Based on my past observation, I rather consider it simply a RAID Action Script 3 development environment.


          Full scripting maturity and flexibility can only be accomplished through 100% Action Script scripting as every mature guru programmer fully knows.


          Sorry guys, stop showing your belly and start rolling up your sleeves and come back to basic programming concepts if you want to surpass Silverlight coders.





          • 2. Re: FORMAL REQUEST
            Jason Villmer Level 1

            For me, Flex Builder has been an exceptional tool for development.

            Through its AS3 and MXML formats, in addition to its rich component

            set, I've been able to realize extremely complex ideas in a very short

            time. So, in regards to Flex, I'm very happy.


            Now, what I don't understand is why the migration of a modern Flex 3 

            project would need to go through so much pain to look and work the

            same. I would think that, despite the new features provided in Flash

            Builder 4, that a Flex 3 project would (should) open and operate

            EXACTLY the same. Alas no.


            I have, however, seen these differences outside of Flash Builder 4.

            I'm experiencing aesthetic and functionality breaks in my application

            nearly every time I update the Flex 4 SDK in Flex Builder 3. First,

            when migrating from the SDK to version I had to

            change the namespaces to get my .css style to look the same. (still

            doesn't quite look perfect). Now,  after fixing all that I updated

            from version to and everything broke again. Man.

            Very frustrating to say the least.


            I digress.


            Regardless, I consider Flex 3 to be a powerful, flexible

            and overall astounding application for realizing ideas. I was so very,

            very excited prior to Flash Builder 4. I couldn't wait to get my

            project in there and take advantage of the new things the Flex (Flash

            Builder) team had thought of. Alas, however, it has been quite painful

            and disappointing from the start.


            Again, for all those Flex 3 developers who aren't fully fluent in the

            myriad of elements involved with Flash Builder 4 (such as namespaces and

            so forth) a simple migration assistant would be a great thing indeed. Just a few

            clicks of a button and all would be changed, updated, altered and fixed to ensure

            those loyal Flex 3 developers will have nothing to worry about. This would

            probably be the BIGGEST thing Flash Builder 4 could offer - seamless migration!


            Jason Villmer



            • 3. Re: FORMAL REQUEST
              David_F57 Level 5

              I see  a few issues with migration wizards, but the biggest concern is they introduce laziness(lack of due care by the developer once a conversion has taken place). The true coder's IDE is still fairly new to Adobe so we should expect the unexpected.


              Borland/Codegear and Microsoft have been developing IDE's for the better part of 2 decades, both have had conversion wizards thru the years and these wizards tended to cuase more issues than they were worth especially when there was a major version change and lets face it this is the scenario where someone would more likely want a wizard.


              Flex 4 sdk is a major shift from Flex 3, Where as 2-3 was an upgrade I don't see the same for 3-4, As soon as I started using the Flex 4 sdk my first thought was to start labeling FB3 code as legacy.


              The experience gained moving legacy code into a current/evolving environment is something you can't buy.


              Adobe does have reference material documenting FB3 to FB4 changes but it needs to be more concise, updated more frequently (in-line with 'stable' sdk builds).


              A well documented migration giudeline with examples would be invaluable and far more effective than wizards.


              Some of the guys at Adobe mention a couple of weeks ago that the changes to the SDK should be fairly moderate from now on which also means the issues experienced when updating the  SDK should start to stabilize(mind you it seems the progress of the sdk went dark(code freeze) a week ago which could be an indication of some more heavy duty changes coming.)


              At the end of the day wizards may work reasonably well on code that doesn't deviate from expected coding practises but you can't beat manual conversion changes for knowing how, where and why code has changed, this becomes rather handy if the behaviour of your masterpiece suddenly changes after a conversion.


              One way of keeping in the loop with the SDK is to use svn versions rather than the builds and follow the versioning logs that comes with it. I update a couple of times a week(its only 6-7 minutes to compile and test the SDK) then look at compare changes in the code if the updates are more than bug fixes. Sifting through the code changes is a big part of my own way of familiarisation with the SDK.

              • 4. Re: FORMAL REQUEST
                Jason Villmer Level 1

                In my opinion the answer is to have a MIgration Assistant / Wizard 

                that provides you a list of precise changes made to your code either 

                during or after the migration. That way, you can monitor (and approve) 

                any changes before they happen and have the ability to go line by line 

                through each change made to FB3 code.


                Jason Villmer