The Flex Toolkit for Apex means that both Flex and Apex become first class citizens in each other’s frameworks. You can write a front end to Apex by invoking the toolkit rather than having to write low level code, and conversely, Apex’s stored procedures capability means that you could store Flex rich client code inside the Salesforce environment.

That means that Flex clients could be more readily reused or mashed up between Apex-based apps run through Salesforce or any of its App Exchange partners. So now you can readily prepackage goodies like drag and drop charting within the Salesforce Apex environment. Before, you could have done this more crudely with Ajax. Now you can do it in the flashier (no pun intended, as Flex is a superset of Adobe’s Flash runtime) Flex client.

It was jointly built by Salesforce and Adobe by writing a series of low level calls to perform tasks such as XML parsing and managing communications between the Flex framework and the Salesforce Apex web services API.

“Although it uses our web services API that was publicly available, the services themselves would have been difficult and time-consuming for developers to construct,” said Adam Gross, vice president of developer marketing at Salesforce.

With the rationale that the enemy of thy enemy is thy friend, it's not surprising that Salesforce would choose to provide deeper support for Adobe’s Flex client, which is battling Microsoft’s Windows Presentation Framework (WPF) for the hearts and minds of developers of the richest of rich web apps (for which Ajax would run out of gas). In turn, Salesforce’s “No Software” branding is aimed just as squarely at Microsoft (which has responded with Windows Live) as it is against Oracle and SAP.

But when we asked Salesforce developer marketing VP Adam Gross whether they might build a similar bridge to WPF in the future, he didn't rule it out. “We’ll leave that to developers,” he responded.

---