Geoff Bowers wrote:
Scott Barnes wrote:
People do compare SWF's to EXE and the moment it doesn't add-up, its considered a "toy" and if you look at it through there eyes (which is a fair call) it does come off looking like a toy and minime JVM.
I don't buy that argument at all. Certainly doesn't wash with anyone whos ever tried to deploy an application on the web. Flash's real achilles heel is the pervasiveness of bad Flash experiences (which is a similar issue with CF development for that matter).
I'm not asking you too, i'm simply stating what I have read and seen both from a development perspective and from a "dilbert" style management situation. I have had heaps of chats with people that aren't immerced in the Web Development world and they have echoed what i have said, its just a simple fact that people do look at flash applications as a replacement for desktop EXE, and soon realise its not as powerful and is then labeled as a "toy".
Hell read most of the blog comments and posts on the web about flash, and you see the wording "flash is a toy" come up heaps from so called "enterprise level folks".
Perhaps Flash is piss poor when its handling large amounts of data when it shouldn't be. I found this recent Flex post on handling large data sets pretty straightforward:
http://www.markme.com/mchotin/archives/004610.cfm
Yes and No, What matts shown is the basics of how to think outside the square in breaking data up into chunks for consuming, thats all good and works well. Except, when you have an occasionally connected client situation, then you have to get a little more trickier as you don't have the benefit of a RemoteObject, and are then forced to go the XML path (ie our sales staff through-out the world, don't always have internet connectivity).
Occaisionally connected computing just doesn't work with Flash in the browser so that's not a great argument -- hence the emergence of Windows wrappers for Flash Player and Macromedia Central. Certainly there are better options than simply downloading a massive XML packet. You could start by building a more optimised storage mechanism within the local shared object. But we're off topic.. offline/online isn't Flex's market just yet at any rate.
No offense, but bullshit it doesn't work. It can and has worked for us, especially in regards to Phone Lookup systems for one example. Ability to take your phone database with you wherever you may go, and resych it back to a main db (hell look at FLEX samples directory, and you will see an actual FLEX example of this). The windows wrappers and Central are a whole new ball game onto themselves, they allow access to the hard drive for one, and other programs within your computer. Centrals point is more towards the fact that it can sit as an idle desktop application and push information to the end user, plus allow for an easier point of sale of the actual product. The two aren't exactly an upgrade to flashs existing limitations, they are more of a feature-add.
XML is more to the point a data file that is accessible, in the end you still have to bind that data to a structure style approach. How you end up storing the data is both irrelevant and relevant. Personally, the only reason we choose to use XML as a data holding tank, is because keeping that locked away in a Shared Object, isn't as elegant as XML furthermore you can update data without having to execute methods within a SWF informing the RIA that its got to update. Thats all i was saying, but you can go into the SO approach sure, but be very careful.
Flash can hardly be considered a toy for the construction of RIA's. If it is, what is the "real deal"?
i never said it was a toy for RIA approach, i said it was a TOY in the eyes of attempting to use it like a desktop EXE. Hence "i wouldn't try and write a 3D Animation program in Flash"
Again we're kind of off topic.. this has little if anything to do with Flex development.
Agreed, it is off topic. I was just answering your question.
People considering Flex undoubtedly understand the differentiation between desktop and RIA -- and if they don't the price of Flex is the least of their worries.
I never stated it was, i was stating that "Flash" has and will continue to be considered a minor replacement for the desktop EXE, and thats a good/bad thing. Not sure how you leaped into FLEX being the replacement?
My general point is that Flex really is *not* all that expensive in comparison to other products in the space Macromedia are shooting for. Furthermore, Flex represents good ROI when applied to a project of relevant scope.
I'd say your in a minority of thinking that its "not" all that expensive. So far majority of people that have *actually* used FLEX have indicated that 12k is too much $ for it, we are one of these people and we LOVE the product.
It is expensive, lets not kid our selves.
The more pointed question might be: is there a place for these sorts of large scale RIA apps at all?
I'd say yes, as FLASH at the end of the day can allow remote access with a smaller payload then its Java Applet / DHTML counterparts. Plus its accessible on both MAC and PC platforms and UI is consistent accross all (linux maybe).
And is the only reason we don't see more of them because the tools to develop them haven't been around?
Yerp, i think too many companies have been sold on the RIA dream, sit down to develop it and either have a bad exp with a FLash Developer or get frustrated that its so slow to develop. RIA is expensive approach via the Flash IDE method, plus its still really new and not many companies are pushing the sale of an RIA solution. Maybe this is more to do with Skills available in the HR side of things? too many factors are in the way of an RIA approach to a project.
It will be very interesting to see the sorts of apps people can build given the ability to apply more traditional development processes to what has historically been a very eclectic development environment.
I agree, thats why i'm so passionate about reducing FLEX's price model, as i can see it being a very sexy technology to allow more of an RIA market, furthermore it can create more work for FLASH Developers (ie someone has to create charting components or specific components in general - which then opens up more of an actuall sellable product(s) for the 'Flash' exechange instead of selling SWC to flash developers)
FLEX is the sleeping giant, and combination of FCS / CFMX well you could do whole lot more for less time, but that initial price is so hard to overcome.
Furthermore, how many corporations have 12k lying around doing nothing? budgets have been forcasted already, and anything over 5k in govt is considered capital expense, thus having to ask for funding for it. If you are able to buy it for say less then 5k, you can hide that cost far easier then 12k. If you outlay 12k in one hit, you have to then show justification on how much of an investment you have recieved in return etc.
In summary FLEX could ease the development burden in a Flash only approach to a project. Argue what you will, thats the only selling point it has atm :) and in many ways i guess you can shift focus from desktop EXE with FLEX, as far as i know and last read, you can still deploy your SWF without having it locked into the FLEX server to run it (ie portable).
--
Regards, Scott Barnes - http://www.mossyblog.com http://www.bestrates.com.au
--- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
