Buzzing about Adobe Flex
I’ve heard a lot of rumours and buzzing around Adobe Flex … so what’s the catch ;o)
For one of my projects I need to get acquanted with Adobe Flex to see what it has to offer and how fast you can learn and implement a real-time application (small test case). I’ve already created a small test case in ADF and now I need to have a look at Adobe Flex .
With my Oracle Fusion Middleware background, ADF for example, I can make a comparison with Flex, how intuitive is the IDE (it’s based on Eclipse), what about J2EE-requirements such as bindings between the different tiers, …
One major drawback of Flex is that it’s again another proprietary code you have to learn, using basic xml tagging but yet another format, another language. If I have a look at ADF it’s much more standardized and if you have a J2EE background it’s comprehensive and you just use the existing knowledge and experience to build on.
But that’s enough talking wright … let’s create a Flex playground =>
First I’ve installed a trial version of flex builder 3 and then I went to search the internet for some sort of a ‘Adobe Flex for dummies’-guide ;o)
I’m using the quickstart guide, which you can find on http://www.adobe.com/devnet/flex/quickstart/coding_with_mxml_and_actionscript/ to get started with Adobe Flex.
The first impressions are … sexy and vivid applications with the same look & feel as flashplayer applications. Let’s try and create one myself:
- The first section in the Quickstart-guide : Coding with MXML and ActionScript works very well, and if you want to use the TIP
Tip: To see the intermediary ActionScript files that Flex generates, add the
–keep-generated-actionscript option to your mxmlc command.
Just use this command in the developer-prompt of adobe flex:
C:\adobe_flex\QuickStart>mxmlc –strict=true –keep-generated-actionscript MyFirstExample.mxml
After you’ve done the first chapter you were able to define and compile a flex application using the Adobe Flex 3 SDK Command Prompt.
In the second chapter : Creating your first application , you perform almost the same exercise but now you’ll use the Flex Development Environment which uses the Eclipse IDE. So J2EE Developers which are used to Eclipse should recognize this immediatly, it’s the same IDE you’re working with, only the needed plug-ins for Flex are added/used.
Steps you need to perform to build a ‘hello world’ (sounds familiair) application:
- Create a new Flex Project (accept all the defaults)
- Copy/paste the code from chapter 2 and choose to run the application
- Start playing around yourself
Let’s compare the IDE I’m used to, which is JDeveloper, with Adobe Flex Builder 3 using the sample application from the 2nd chapter.
- 😦 => I can’t re-organise my components in the outline-view which can be compared to the structure-view in JDeveloper. I have to use the design-or source-view in Flex to re-organize the components, let’s say for instance I want to move my components (textarea, panel and label) from the tile into a VDividedBox, I need to do this in the source-or design-view and can’t rearrange using the outline-view.
- 😦 => I don’t have a look-up of the existing functions that are defined in the mx:
Script tag. To avoid erroneous referring of functions in the CDATA-part you could have a drop-down or look-up of the existing functions in the properties that can use these, e.g. the onclick-event could have such a drop-down. This is usefull code insight when working with the ‘Flex Properties’-panel in the IDE.
- 🙂 => The code-insight on each component (each component you’ve defined an ID for, such as myText or myLabel) is very helpfull to have a look at the available methods on these objects.
- 🙂 => different ways of specifying eventHandlers which gives each developer the choice between different approaches and if you’re referring to a non-existant label/field/method a compile time error will be shown.
- 🙂 => when you’ve messed up the mxml file, meaning the tags aren’t constructed properly anymore for a mx:application, the design-tab won’t work anymore. This is a very handy feature because it will point you to the code that produces the exception. You have the possibility to check what’s wrong with your source code without having to search inside your mx:application for tags that aren’t closed properly etc. In the following screen-shot you can see the behaviour:
That’s it for playground time today, I have to get back to business with JDeveloper but untill now I’m still curious.