Brian Leach wrote: >The data based stuff is pretty recent in terms of Flash, and I >guess most of the Flash community hasn't caught onto it yet - >after all, it is primarily a tool for content designers (and >for some pretty good games too) so most of the people using it >are not database minded.
Brian, the Flash and Shockwave people have been working with databases for a few years now, though you're right that by and large most of those developers don't "get" the value of real databases yet. As Craig Bennett says "All the graphic designers in the audience just stared ..." They're approaching it from an artistic view and not an applications view. They see a database as a place to put data, like for game scores, but not as an integral part of an application the way we MV people see it. For years I've seen this gap in perception as being an opportunity for MV people to refit their apps with user-friendly UI's, but MV people don't "get" that either. The Macromedia-type web developers are very interested in data connectivity for zero-install or low-footprint clients. I did a presentation for the Orange County Multimedia Association a couple years ago (when I was Product Manager at Raining Data) which included discussion of the MV model, comparisons with ODBC, using Omnis Studio for cross-platform development and deployment, and FlashCONNECT as a data conduit from "mainstream" graphical tools. The focus was on data connectivity and trying to get them to "get it", not any one product or technology. See the following link for demos I wrote to get from various clients (including Shockwave/Flash) into D3. (That was over 4 years ago now - whoe!) The same techniques can be used with different tools and back-end DBMS environments, so don't let the FlashCONNECT thing scare you. http://flashconnect.rainingdata.com/wuc2000/fcdemos/index.html Note that I did the Shockwave interface as an installable thick-client, though it could have just as easily have been a thin-client browser plug-in. In hind site I probably should have made it thin but my focus was on demonstrating the variety of technologies - making everything a browser interface would make it easier for people to get eye candy but would have limited the scope of the real purpose of the demo. If someone would like to use Macromedia or Adobe GUI products with U2 or other MV applications, I'd enjoy providing the communications interfaces for such a project. >It wouldn't be a simple or cheap solution, particularly at >this stage - writing Flash dialogs is hard work - until >someone does something to capitalize on it. There are already >plenty of (considerably cheaper) tools that produce flash >content without having to use Flash as the actual designer, so >it may only be a question of time before someone with the >money and time realises the potential there and comes up with >a suitable tool. Real Flash work is easier than it used to be and much more feature-rich. As indicated above I think the issue is getting people to see the value in the UI as well as the tools that can drive it. Most people don't understand Flash and think of it as a toy rather than as a tool - just like people look down on CUI business software. Anyone who wants a browser-based GUI, especially cross-platform, should seriously look at Flash and Shockwave, in addition to Java. The big question is "who is your audience?" If the audience is Joe internet user then Flash may be better. If your application is more extranet-oriented then I'd tend toward Java, depending on the features required. Tony -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
