As someone who codes Actionscript for a living, I can understand where
you are coming from.
Post by SamFeltus
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
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
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
Post by SamFeltus
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:
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.
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
You received this message because you are subscribed to the Google Groups "Django users" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to email@example.com
For more options, visit this group at http://groups.google.com/group/django-users?hl=en