|
There is this blog and a nice looking demo showing how AJAX can happily live together with Flex charting. This vendor's AJAX grid component is populated with the data first, and then using FABridge the data is being passed to the Flex Charting component. Typically blogs demos like this get a number of Wows , and I expect several "Cool, man" comments to this blog within the next day or so.
Since the blog authors have provided the decription of how this demo was made, I've read it and these are some of my questions/concerns.
I understand that these guys need to promote their AJAX grid component, and that's why they've published this blog, but let me ask you this: if I'm planning to pass data to Flex components anyway, why on Earth not just use Flex Data Grid in the first place?
The authors honestly admit: "To ensure that the details grid is still fast, we only render the part of the dataset that the user is looking at rather than rendering all 1000 records say, which can take a long time when you use the DOM innerHTML property." That's right guys, and instead of jumping through various hoops to overcome such issues, just use Flex DataGrid - it would be much faster.
Keep reading...
"All of the sales data is transported from server to the client using Ajax, but subsequently massaged using XSLT and rendered using the FABridge and Flex Charting 2. This approach is particularly attractive since it enables us to preserve the way each tier in our application works as an Ajax application, and simply extend the application to include Flex."
If you'd use just Flex, you would not need to use XSL transformation to pass the grouped data to Flex. After doing your grouping on the server side, and sending the data to Flex collection once, and using data binding, both controls would be populated.
Guys, I really wish you all the best in selling your AJAX grid, bit I'll be honest with you: I won't buy it. And you did not convince me that this demo is the right use of FABridge.
I think maybe part of the difficulty here is the different frame of
reference we each have on this issue of RIA. On the one hand if you were
writing a lot of your app from scratch and Flex was an appropriate choice,
then sure.. use a Flex datagrid. On the other hand, a lot of developers
looking at RIA right now are not in this boat. They're doing incremental
improvements to existing web apps, or they're writing a new web app, and
want to test the waters with Flex before using it for everything. The
Fabridge can be a great way to take a JavaScript datasource or an app that
uses XMLHTTP for data transport, and incrementally improve it with
something like a chart from Flex.
You have to be consistent. If you are showing an example of an AJAX app
working with Flex app, I assume that you've already purchased the Flex
license. If this is the case, what kind of incremental improvements are you
talking about? If you already paid for the Flex license, there is no
reasons to do AJAX.
FABridge is Adobe's marketing trick to show the rest of the world tha it
can work with AJAX, which is enjoing lots of undeserved attention in the
industry this year. If a firm has already AJAX apps in place, you may
suggest them a gradual switch to Flex, but in this case the AJAX part has
to have a bare minimum of functionality, like getting a couple of
primitives generated by another system, and the rest of the processing
should be done in Flex or WPF if this is a Microsoft shop.
Sure, but the cost of a Flex license is miniscule compared to the cost of
development. Having paid for one sure does not mandate we re-do everything
right away in Flex. Also it might be time prohibitive as well. These are
very real adoption concerns that Adobe is dealing with right now, and I
think FAbridge has wider applicability than a mere 'marketing trick' as you
say.. just an opinion.
Is your book - 'The Java tutorial for the real world and RIA Adobe Flex and
Java'- available in India?
Do you know who is marketing them here?