Hi Sam. As someone who codes Actionscript for a living, I can understand where you are coming from. > > That is the point, when HTML is the lowest common denominator, a web > application is limited. HTML is evolving at a snail's pace, whereas > Flash has steadily evolved into something far more sophisticated than > HTML. HTML has it's place, of course. Depends of what you mean by "more sophisticated". Flash content can't be indexed by search engines for example. How many websites do you think can afford to be excluded from search engines? Flash content requires more processing, besides a proprietary plugin. This means that for example, people on a 64 bit linux can't read flash content. iPhone can't either. As the number of people accessing the web through different devices grow this will be more and more of an issue . (don't even get me started on flash lite) Flash content can't be cut and paste normally (browser menus or browser shortcuts). Flash content, out of the box, will break the browser's back button. Flash content, out of the box, will not allow deep linking.
If you take these into consideration you'll see that one of this issues excludes flash from a lot of projects. When you add them up, you realize that very, very few sites can rely heavily on flash at all. Flash is great for "entertainment sites", or "advertainment". Site where the wow factor is more important than actual content. Otherwise flash is great as small pieces: a video player (youtube), a photo slideshow (flickr)... etc. Relying in flash to deliver "hard" content (text, navigation... etc) immediately excluded your content from a lot of technologies and a lot of users. > > But Flash now has a free command line compiler, so it is easy to > manufacture SWF's from scratch in a Python program. A " free command line compiler" means free as in beer, it still is proprietary. If adobe decides to change it's mind on the next release, or change licensing, it can. The mxmcl compiler, for example, loads the jvm every-time. This means that if you wish to compile swf files dynamically you'll be dealing with a couple of seconds of wait, plus a large memory overhead for each request. Also, note that your post is too vague. Django "generating flash content" can mean, among other things: a) django generates dynamic data, such as the description for a slideshow. this can be done in xml or JSON, which django has excellent support for, and it's very straight forward to extend for you specific use (I've done quite a few of those) b) django serializing data with AMF. For this check: http://djangoamf.sourceforge.jp/index.php?DjangoAMF_en and http://cheeseshop.python.org/pypi/flashticle c) django acting as Flash Comm. This involves reverse engeniering protocols, flv compression and more. (I'd love to use one of these though, specially live video enconding) d) django acting as a xml socket server, such as unit (from moock) The point is, flash has a lot of limitations. Papervision is cool, but it's not meant at all to replace html. Their weblog for example is html , and so is the mailing list. Before people realize javascript could make web apps much more dynamic, flash seemed like the only option for making apps more responsive. Today, ajax has killed a lot of reasons to use flash (page reloading, progress indicator etc). Besides for specific use of rich media (again video, audio.. etc) and visual effects (papervision and genereal BitmapData voodo) there's no reason to use flash, and most hackers doing dynamic websites don't need those things at all. Also notice than having django acting as a magic backend solution for issues b), c) and d) is kind of moot. The largest, by far , effort would be to reverse engineer and implement protocols, codecs and file formats . Once that was accomplished, having django views hook those up would be trivial. I've done a few all flash websites with django in the back end. I'm pretty happy using JSON to send data in and out (I hope to try amf soon). I did wish there was something like Flash Communication Server open source and written in python but I am not holding my breath for it. If you think most data send to flash can easily be xml, JSON on html (variables to the embed tag) django is well suited for feeding flash content. Cheers Arthur --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
