Adobe has published an article that Ryan Knight and myself wrote up a few months ago. It gives a very quick overview of securing the server side of Flex applications that using Spring BlazeDS Integration, and then it introduces using our Chimp project to secure the client by doing things like role based filter of UI components. You can check out the article at: http://www.adobe.com/devnet/flex/articles/flex_enterprise_security.html

Additional Resources:

• Component for Role Based Permissions in Flex
• Flex Security Component Updates
• Project Home

In this episode we catch up with the guys from Universal Mind (Tom Link, Brandon Purcell, and Doug McCune) to chat about their SpatialKey product and geek out on software.

Resources:

• Universal Mind
• SpatialKey
• Brandon Purcell’s Blog
• Doug McCune’s Blog
• Audio / MP3 Version

In another exciting installment of Jon Rose and James Ward’s Drunk On Software, they chat with FlexMonkey project founder Stu Stern in celebration of the first production release of FlexMonkey. The  conversation may lack a bit of focus, but does have some good info if you stick with it.

FlexMonkey Resources:

• FlexMonkey Project Page
• FlexMonkey project blog
• Adobe Dev Center Article: Testing Flex applications with FlexMonkey 1.0

You can find the original post here: http://www.drunkonsoftware.com/2009/07/14/episode-14-flexmonkey/

In another exciting installment of Drunk On Software, we chat with Gorilla Logic’s Stu Stern in celebration of the first production release of FlexMonkey. Our conversation may lack a bit of focus, but does have some good info if you stick with us. We hope you enjoy watching as much as we enjoyed filming it.

FlexMonkey Resources:

• FlexMonkey Project Page
• FlexMonkey project blog
• Adobe Dev Center Article: Testing Flex applications with FlexMonkey 1.0

You can find the original post here: http://www.drunkonsoftware.com/2009/07/14/episode-14-flexmonkey/

In Stu Stern’s recent InfoQ.com article on UI testing and FlexMonkey, he explains the code-a-little-test-a-little (CALTAL) approach to test driven development with user interface development and walks you through using FlexMonkey to support the theory.

The practice of maintaining automated unit test suites has gained widespread acceptance over the past decade to the point where most developers today either engage in some amount of test writing or at least feel bad for not doing it. This rise in automated unit testing has led to some confusion about who should be testing what. Should developers strive for 100% code coverage with their unit tests, and if so, does that mean we no longer need dedicated QA testers? Many development teams draw the line at the user interface, reasoning that since user interfaces can be exercised with little or no programming they can be tested more economically by dedicated testers, either manually or with specialized testing tools. This division of labor has led many to divide the world of testing into “unit testing” and “functional testing”, with developers providing the former and QA testers providing the latter. In this article we’ll explore how Gorilla Logic’s new, open source Flex user interface automation testing tool, FlexMonkey, can enhance the productivity of both developers and QA testers. FlexMonkey allows developers to incorporate user interface testing into unit test suites and continuous integration environments, and allows QA testers to expand those unit tests to create and maintain comprehensive quality tests.

Enjoy the full article at: http://www.infoq.com/articles/flexmonkey-ui-unit-testing

Looking closer to home, Jon Rose at Gorilla Logic has just released Flex Monkey, a free tool to automatically test your Flex UIs. I've known Jon through various events so decided to look at the site. As with many sites, it contains a fair amount of cleverness but no clear statement of what they are about. However, among the slogans I found one that I thought had promise: "The answer is not more monkeys." It's succinct, catchy, and on the right track, because it's suggesting that more things should be automated (and Flex Monkey is an example of that kind of automation). Alas, the rest of the site doesn't give me a clear idea of what they do.

Before

After

In all seriousness, we do appreciate any and all feedback on the site (and we do really like Bruce).

In Part 1, I covered the basic setup of LiveCycle Data Services 3 Beta sitting on a MySQL database. Now, I’ll get into the Flash Builder side of things, and talk about the Modeler plugin and model driven development.

Setup Modeler Plugin

1. Get Flash Builder 4 Beta (download)
2. Get the LCDS Modeler plugin (download)
3. Install the Modeler plugin:
   • Unzip to a temp folder, which will create a plugins folder
   • Copy the plugins folder’s contents directly into Flash Builder’s plugins folder (typically located in /Applications/Adobe Flash Builder Beta/plugins if you are on a Mac)
   • Restart Flash Builder

Model Driven Development

1. Create a new Flex project
   • In Flash Builder, right-click and say New > Flex Project
     
     enlarge
   • Choose J2EE for Application Server Type, and select LCDS
   • Click Next to configure your server
     
     enlarge
   • Uncheck Use Default Location, and fill in your root folder, url, and context (see screenshot)
   • Click Validate Configuration (this will fail if LCDS is not running), and then Finish
2. Create a new data model
   • Select the Data/Services tab in the bottom window
   • Click the Edit Active Data Model icon in the tab’s menubar (see screenshot)
     
     enlarge
   • This will create a new data model for your project, and bring up MyApp.fml in the Modeler’s design view (see screenshot)
   • To see the file in the Package Explorer, click the Filters icon (see screenshot), then uncheck .* and .model
3. Connect to the server
   • Switch to the Adobe Data Model perspective
   • In the RDS Dataview window, click the RDS Configuration icon
     
     enlarge
   • Set the Context Root to myapp (because our server is running at http://localhost:8080/myapp/)
   • Click Test Connection, and then OK
4. Verify the server’s connection to MySQL
   • In the RDS Dataview window, expand until we can see our tables
     
     enlarge
   • Right-click on a table, and select Show Table Contents
     
     enlarge
5. Edit the model
   • Just drag tables from the RDS Dataview to add them to the model
     
     enlarge
6. Browse the generated services and code
   • Once the model is updated, the builder automatically generates standard CRUD services. Switch back to the Flash Builder perspective, and you can view them in the Data/Services tab
     
     enlarge
   • The generated code is available in the Package Explorer. Files you don’t want to touch are prefixed with an underscore. The other files, like Player.as and PlayerService.as are available for you to customize.
     
     enlarge

More Docs

1. LCDS Modeler Guide (zip)

Conclusion

Once again, that’s it. I’ll have to learn something new about LCDS before I write more.