The New Flex

As I am going through the latest Flex offering, I see it has retained much of what was loved about it, rectified some annoying points and added some things as well. Unfortunately, it is still a work in progress and I reckon it is going to give grief for some time. It is good that Adobe has opened the SDK to Apache, hopefully somebody will come up with a better IDE, better debugging tools and more stable releases. On the business note, it does exemplify how difficult it can be to absorb an alien technology/company. Adobe bought Macromedia, but was totally lost about how to handle the Flash offering. It made a brilliant opening gambit, but has more or less went from one disaster to other for a long time. Finally now, there does seem to be hope for a brilliant platform that is being criminally sabotaged by Adobe, possibly for want of better Product Managers. The recent changes indicate a welcome fresh thinking. How far this will go? I guess we will have to wait and watch.

Handing Security Error 2148

Nice post detailing how to solve the problem: Resolve Security Error 2148

Joomla Resources

Was just exploring Joomla as a way of creating websites quickly. Just compiling a few links and resources that may be useful

JoomlaArt.com
Rockettheme.com
JoomlaBamboo.com
http://extensions.joomla.org

Flex: A Change for Good

It seems that finally somebody in Adobe is thinking differently. The partnerships that Flex has made with Spring and some aggressive work on Java integration should put back Flex where it rightly belongs. After many wrong steps, finally a sensible product manager who thinks about the ecosystem and not just his product. It doesn't mean that the battle is over, and Adobe has to still work hard to get it going for mobile devices more efficiently. Still, compared to the mess in previous years, good job!

I am putting up my technical review notes in this online doc

Respite for Adobe

Some respite for Adobe as Apple has agreed to ease certain restrictions on the use of Adobe software. Adobe's strength lies in desktop softwares to develop graphic applications and UI. In the rich-internet application (RIA) arena, it still lags behind. Acquisition of Maromedia and Flash has not translated into leadership position that it may have hoped for, though Flash video streaming did turn out to be a winner. Even that may be lost to HTML5 if Adobe is not careful. Its about time that Adobe digested Flash and gets back to the good performance that is expected out of a company of its calibre, failing which it would be only fair for developers to punish it further.

Flash's Final Gambit: Droid 2

After some serious lack of imaginative development, shoddy product management and heavy criticism, it seems that Adobe has decided to play an all or nothing hand with Droid 2. This article in PC World brings out the point very well. I think it would help Adobe either defend Flash for mobile devices or seriously re-think its development strategy for the same.

Going for the Jugular

Double wham! On one hand Steve Jobs comes out with an open letter explaining why he won't support Flash on Apple devices, on other hand Microsoft announced that IE9 will use only the H.264 standard to play HTML 5 video. Bad news for Flash and will definitely affect its reach and power.

In my opinion, it is time for Microsoft to go for the jugular. It has Silverlite coming up as a credible alternative to both Flash Developer 4 and javaScript for developing RIAs. It has the marketing knowledge, distribution network and the good sense to achieve what Flex could not. In the process, it may end up displacing Flash from RIA arena and making good revenues. My free advice would be better start moving on with Silverlite and focus on the obliteration of Flash!

From Flex 3 to Flash Developer 4: Thumbs Down

Flex 4 has turned out to be Flash Developer 4. It seems that Adobe decided that since Flash was a stronger brand it would be perhaps wiser to merge Flex with Flash. Ultimately it was about developing flash media more effectively, and in that sense the merger does make some sense. Nevertheless, I feel that first Adobe neglected the Flex brand, slept on its laurels, saw Flex usage drop down, did not know how to catch-up and decided to roll it all into with Flash. After all that's all it was, wasn't it? I am not totally convinced.

We have lost Datagrid and some other Flex 3 components and compile times will not improve substantially either. I am also not convinced that Adobe will be able to effectively mix two different paradigms: Rich Internet Application development and animation. The result may be an unappealing mix that puts off both type of users. Not all is bleak though, as we are promised better debugging and backend integration. I don't even feel like evaluating the new offering, but will to see how bad it really is (or, I hope, perhaps be surprised to discover the opposite).

I am increasingly confident that Flex/Flash will further loose the RIA market to JS based competitors. Yet again, I am disappointed by Adobe's development strategy. As much as I liked Flex, I am sorry to say I may not like sticking with it if this trend continues. And for all newbies to RIA, I would warn keep clear of Adobe till these guys mend their ways and approach product development keeping in mind their target market.

A Careful "No" to GWT

Well, GWT is alright. But I am convinced that it may not be the way forward, though many of its ideas and approaches are reasonably good.

The primary problem is that I really don't like compiling my code every time to see the smallest of changes. This is one biggest reason that I would prefer a JavaScript-HTML5 based framework and an IDE that makes it easier to develop thus. Secondly, learning and using GWT can be simpler if you are a good programmer or have worked with Java Swing. Otherwise the learning curve for a web developer can be quite steep. Finally, I am not really convinced by its handling of testing, its ability to make maintenance easier and browser compatibility issues.

All-in-all, it is back to exploring other solutions to developing RIA solutions more effectively. Will keep you posted.

Exploring Google Web Toolkit

With YUI, Flex, TIBCO and Ext; somehow I managed to ignore Google Web Toolkit (GWT). It suddenly struck me that by making JavaScript generation Java based, GWT perhaps addresses two extremely important problems with new-generation UI code: maintainability and debugging. Since there are umpteen Java based IDEs, this should be interesting. I will have to explore it a little to assess how powerful and easy it can be compared to other solutions, but I think it does merit a thorough exploration. More when I am through with it!

New Developments in the Market

Simply could not wait to write about this: Ext is coming out with Ext Designer. This would be the first Javascript-focussed RIA building tool outside of Adobe Spry in Dreamweaver and TIBCO General Interface. And it reaffirms my conviction that an IDE to help developers make RIAs more effectively is desperately needed. This step by Ext is in the right direction. It remains to be seen how far they would be willing to take it. I, for one, would be keenly watching them.

Parallel to this development is Salesforce coming up with Chatter Collaboration Cloud to create create collaborative cloud-computing applications. Salesforce, above all, have a strong expertise in making web-based business applications. Yet their venture from CRM into collaborative development, on the face of it, does seem odd. I have no doubt about their technical prowess and their distribution network, but I am curious to understand how they will leverage their CRM experience and brand image to enter this arena. In fact, I feel their strong association with CRM may inhibit them. I understand that they are now promoting the "Force.com platform" with a strong desire to leverage cloud computing, but the CRM shadow may prove a bit hard to loose. For RIA, this development points out at an interesting alternative to desktop based IDEs. Definitely something to ponder upon. The not-so-new RIA by Autodesk and the current venture by Salesforce clearly demonstrates that it may be both technically feasible and perhaps even desirable. Definitely something to ponder about.

Future of Flex Revisited

I remember expressing my doubts about the Future of Flex and dissatisfaction with Adobe's work in RIA. So you can understand that I was intrigued to learn that Apple has decided to continue to not support Flash. In fact, it is alleged that Steve Jobs called Adobe a lazy company. Expectedly, the web was soon full of discussions and arguments between Flash lovers and Flash haters. Myself, I have used Flex for quite some time and now I am keenly following the HTML5 development. I feel that Flash does have a large reach. Even if one could use HTML5 for video streaming and delivering a variety of RIA applications, I will be keen to see how it manages to handle the challenge of drawing vector graphics and animation. Especially in analytics and similar applications, I don't see anybody replacing Flash based charts any time soon. Even most JavaScript based frameworks tap Flash for graphs and other highly interactive visual elements. Hence, with its reach and graphic potential, Flash remains a force to contend with. And Apple is simple not powerful enough to dislodge it, unless somebody can come up with a better alternative and promote it enough.

However, there is some truth to the charge that Adobe has gone a bit lazy. I, for one, will not question Adobe's technical competence. They are simply brilliant when it comes to desktop based graphics and multimedia development applications. In fact they make great IDEs for the same. But when it comes to the web-based application development, as an end user I am totally unhappy and unsatisfied with the way they have screwed up Flex development. They had a clear head-start but lost ground to JavaScript frameworks. This was, mind you, not due to their laziness but lack of closeness to customer needs. No wonder other technologies are fast elbowing it out. Apple may have gone a bit overboard, but it does point out that Adobe needs to change its approach towards RIA development or ultimately face being evicted out of this arena.

TIBCO General Interface

By chance I came across the "TIBCO General Interface". Coupled with its "AJAX Message Service", at first look it seems to be a credible alternative to likes of "Flex" and "Ext". After digging a bit deeper I realized that overall it is not so. Nevertheless, I feel that it is a step in the right direction and is hence important.

The most prominent reason that I am excited about it as it is a proper IDE based approach towards developing JavaScript based RIAs. However, it seems that TIBCO is interested in making products for specialized clients as opposed to web applications for the general public. That is why it has blatantly decided to support only Firefox 1.5/2 and Internet Explorer 6/7. You cannot hope to get away with that if you are making a product for the public. You can get away with it if the product is for a particular company that can enforce a standard browser all across the organization. I guess they have simply chosen their battlefield, and it is not anywhere near Flex or Ext. On the other side is Adobe's Spry framework making its way via the Dreamweaver. It supports more browsers but has less functionalities, aiming at "public" applications I guess. I feel that RIA application development community needs something akin to this, albeit more comprehensive.

I still feel the Flex has the best potential. Sadly, Adobe Engineers seem to be designing from the lab instead of trying to go to the customer's desk and observing competition. Let's see what "Flex 4" brings. Ext, on the other hand, is moving aggressively in terms of feature enhancement and reliability. A good JavaScript plugin for Eclipse, Idea etc. that focuses on RIA development can move the battle decisively in the favor of Ext. Easier debugging would also help. It has already started using flash charts to neutralize one of the most significant advantages of Flex. Combined with Google's data visualization API, one may as well start questioning the existence of Flex. Flex is falling back and Adobe would do itself a favor by waking up to it and taking the fight back to the competition.

The Future of Flex

After having a look at the current RIA technologies in the market, I have to say that Adobe RIAs are falling back wrt the JavaScript based ones. Did I hear somebody talk about Microsoft's Silverlight? I feel there is nothing special about it absolutely; I guess web applications is not exactly Microsoft's forte, so I would not consider it very seriously for now. An interesting addition in the foray has been Google with its smart data visualization API.

I think that there are a few weaknesses of JavaScript based RIAs. Firstly, JavaScript itself is not a very ordered language. It is easy to copy and using it to build a competitive advantage is difficult, if not down-right impossible. What adds to this difficulty is the absence of any tool that tries to make this development comprehensive. Adobe is trying to move towards it with a combination of its Dreamweaver and Spry framework, but there is still a long way to go. A little discipline in coding can make the JavaScript code manageable, as demonstrated by products like YUI and ext.

Secondly, JavaScript's charting capabilities are pretty limited. For serious dashboards demanded by analytics, this is a handicap. Interestingly, JavaScript developers have attempted to cover this gap by using, guess what, flash. With a better integration between swf files and javascript, this has become increasingly possible. While ext has just started on the path, Google's data visualization API and charting widgets are something to watch for. Buying charts from Fusion Charts can give you some headstart as well.

On the other end of the spectrum lies the flash/flex based RIAs. A few years ago they held a distinct advantage over their JavaScript counterparts in terms of possibilities. The Flex based projects are especially easier to maintain and develop when compared to JavaScript. However, the apparent growth has more or less stagnated. For example, the Datagrid and even the Advanced Datagrid lack the basic pagination feature available in most JavaScript based tables. With very competitive graphing options available in form of Google APIs and Fusion Charts, the case for using Flex becomes weaker. The debugging and testing ability has not improved much over time either. If this continues, in the next two-three years JavaScript based RIA's can play hardball to firmly displace Flex, leaving Adobe to play the catch-up game. It seems Adobe has the right ideas, but its willingness and ability to put these ideas into action will decide the final outcome. With the flex SDK out in the open and javascript using flash to plugin its charting gap, Adobe can win this war by promising to increase the developer's productivity by doing what it does best: developing a desktop IDE for helping RIA developers to become more effective.

Using Flex Within an Ext Panel

Here is an interesting one: integrating ext with flex :p. We built a dashboard application using ext, but realized that for certain visualization needs flex is better equipped. So now, we wanted one panel in the ext tabbed layout to have a flex chart. A brief step-by-step guide to achieve it:

1. Generate the swf file for your flex project. This will, normally, generate the following in the bin-debug folder:

• An HTML rendering of the whole thing and the main swf file, which will have the same name as your project
• playerProductInstall.swf, a swf file to help install latest version of flash player if need be
• AC_OETags.js, a javascript file that takes care of the actual writing of the swf object to the html dom
• a history folder with three files to help the swf maintain history

2. Copy all the files generated above EXCEPT the HTML rendering into an appropriate location in your webapp. For example, to a folder /resources/flex/graphs/

3. In the ext tab panel add another tab. Set the content to be an ext Panel:

var visualizationPanel = new Ext.Panel({

id:'graphPanel',

title:'Analysis Graphs',

bodyStyle:'margin:0;padding:0;',

height:400,

width:'100%',

contentEl:'graphDiv'

});

Note that we are using the "contentEl" property that will try to find an HTML div by this name in the DOM to render to this panel

4. In you main HTML where you have the ext tab panel, add this to your <head> (lifted and modified from the rendered HTML. Get your paths right)

5. To your <body> add this script and a <noscript> tag. The main changes to be noticed have been made bold.

6. Now, open AC_OETags.js and add a statement in the switch inside AC_GetArgs function :

case "content_el":

ret.params["content_el"] = args[i+1];

break;

7. In the same file, change the AC_Generateobj function.

Here is the full AC_OETags.js file

Cool, now you are ready to go. Your very own flex graph in an ext tab.

Challenging Adobe: Possibilities

Dreamweaver can be a handy website development tool as it can double up as your content management system as well. For PHP websites not looking for too much of RIA, Joomla and Drupal should suffice. For RIA, Joomla and Dreamweaver both can be seriously inadequate. Which brings us back to our friend Flex. As things are at this moment, Flex rules.

Pure JavaScript based RIA can be serious challengers to Flex. However, in absence of an IDE seriously focused on developing RIAs using JavaScript AND manage the content effectively, Flex holds an almost unassailable position. In fact, it seems that by slowly (but steadily) developing Spry and integrating the same with Dreamweaver, Adobe may already be working in that direction. That way Adobe would be ultimately able to hold two winners - whichever way people turn.

Nevertheless, that may not be Adobe's intentions. It certainly doesn't look like the way it is promoting Flex. I think it would make fabulous business sense to make an IDE at par with Flex that exclusively focuses on making an RIA using JavaScript et al. This would not only break Adobe's impending monopoly but may also benefit the developer community in general.

A Skeleton Tabbed Layout in ext

Using ext for UI is not a pleasant task after experiencing Flex. Nevertheless, we do what we need to do :).

I needed to build a tabbed layout and in a series of article I will explain my experience with the same. The first thing to do (after downloading ext) is place a basic skeleton in place - the jsp/html and the javascript.

Skeleton html for guidance

The basic tab manager javascript guidance

Ext or Flex?

For the past few months I have been evaluating another claimant to the realm of RIA:Ext. Ext looks good. In fact it can be quite formidable if combined with Google Charts and Google Visualization. So, given a choice, what should one pick? A brief comparison before I give my views:

Flex

• Cost per license: $699


• Technology: Flash and ActionScript


• USP:
  
  • More developer friendly and reliable than JavaScript any day
  
  
  • Hides your UI code
  
  
  • Produces very maintainable and testable code for complex dashboards
  
  
  • Very well tested and reasonably predictable
  
  
  • Strong user community and support, thanks to Flash and ActionScript legacy
  
  
  • From Flex 3, communication between JavaScript and Flex has become easier.BlazeDS is now available as open-source and facilitates integration with various backends


• Weaknesses:
  
  • Cost
  
  
  • Learning curve
  
  
  • Flex can prove to be a hammer to kill a fly for most web applications.

Ext

• Cost per license: $289


• Technology: javaScript


• USP:
  
  • If you don't have a reasonably complex dashboard that needs significant data visualization,it is a good alternative
  
  
  • Hides your UI code
  
  
  • Lesser cost
  
  
  • Less complicated than Flex


• Weaknesses:
  
  • Can be difficult to debug
  
  
  • JavaScript
  
  
  • Not that strong user community yet
  
  

I feel, Ext is impressive but not as good enough as Flex due to the inherent evil nature of JavaScript :). I could not find too much help on the web either to address the countless bugs I face when I use Ext. The fact that I expose some part of my business logic when I use a JS based RIA still holds true for Ext. In its attempt to prevent its precious JS code from being nicked away, Ext has taken great pains to obfuscate its files. Even with it debug javascripts, it can get very frustrating and difficult to debug any issues. This brings in my concern for a maintainable and testable code if my UI is reasonably complex.

Nevertheless, it builds significantly on top of other available RIA options and tries to integrate with JQuery, Protoype, YUI and even AIR. It is definitely an upcoming force that will mature in 2-3 years. It also holds the cost advantage against Flex. All-in-all one may think of using it if one's UI is not as complicated.

But if I have a UI to build that has to be complex, extremely reliable, maintainable and testable, my vote goes to Flex any day.

Removing and Adding Options Dynamically

Using DHTML is beautiful because you can play with the DOM as you please. However JavaScript is not that consistent. Of all sources I find the one by W3C: W3 Schools the most comprehensive and technically correct.

If you are looking to add or remove options from a select box dynamically, using add and remove methods on select element is the most reliable way. For gory details have a look here:

Select Object Reference

Flex Data Services(FDS): FMS

FDS enables you to access and synchronize data across one or more applications built with Flex framework. FDS itself is a server-side java app designed to work with most Java app servers. FDS consists of four parts:

• Flex Message Service (FMS)
  
• Flex Data Management Service (FDMS)
  
• Flex Proxy Service (FPS)
  
• Remoting Service
  

FMS helps to build apps that support real-time chat and collaboration. Idea is to update app whenever server side data changes. In this article let us see how we can use FMS Java API (MessageBroker, AsyncMessage) to receive message in Flex.

1. Take the FDS blank application as your starting point

2. Open WEB-INF/flex/messaging-config.xml and add this destination node below default-adapter node:Destination Node Code

3. Define message consumer in MXML

<mx:Consumer id="consumer" destination="feed" message="messageHandler(event.message)"/>

4. Subscribe/Unsubscribe to message at desired part of the flex code as:

consumer.subscribe();
consumer.unsubscribe();

5. Whenever there is a message generated at the backend, now your flex application will hear it. A very simple sample java file that generates message will look like this:

Sample Java Message Generator