Flex 4 + Django: Testing and Release Options

Question

I am creating a django-based site that will serve flash apps that occasionally access data via pyamf. I need to be able to easily test the flash in the context of the django framework, i.e. with all the login cookies and everything available, so that when I make a pyamf call, it has all the user context there. And I need to be able to test and release both the swf's and the wrapper html's in a sane way. However:

1. The html templates in flex are already templates, so if I put template code in there for django, it gets scraped out before the flashapp.html is created.
2. The html's and swf's automatically get released to the same directory, but I want them to go to different directories because the swf's shouldn't be served by django and the html's should be in an area in control of django.

This leads me to believe, at first glance, that I need:

1. A way of having the html and swf files be released to different locations. (I don't know how to do this.)
2. A way of releasing the html's as stubs (no html/body tag) so that I can include them from another location in django. (I guess just strip what I don't want from the index.template.html?)
3. Then I can point flex to go to the django site that in turn includes the generated flashapp.html that in turn references the swf, and it should all work. (By feeding that alternate html to the run/debug settings, I assume.)

So my question comes down to:

1. Is the above the best way of doing this, or is this even the right direction?
2. If so, how do I release the html and swf to different directories? (For debug and release mode, if there are two different methods.)
3. If not, what is proper?

And if there are any other general bits of advice for me on this topic, please feel free to share. :-)

Answer 1

Finally figured this out myself. A combination of this and django get-parameters works. The general take-away:

1. You can put {% tags %} and {{ variables }} in index.template.html without worry, as there is no way to customize the currently-existing macros there like ${title}
2. If you make a foo.template.html and foo-debug.template.html in the html-template directory of your project, then the former will override index.template.html for release builds, and the latter for debug builds (note that the result will be foo-debug.html instead of foo.html though.)
3. You can pass the name of the SWF in a parameter to django, and have it fill in the directory for you

foo-debug.template.html

<object ...
  <param name="movie" value="{{ bin_debug_url }}/${swf}.swf" ...

djangoflash.html

{% block content %}
  {% include flash_template %}
{% endblock %}

views.py

def djangoflashview( request, **kwargs ):
  if not kwargs.has_key('extra_context'):
    kwargs['extra_context'] = {}
  if request.GET.has_key('name'):
    debug = "-debug" if request.GET.has_key('debug') else ""
    bin_debug_dir = '/dir-to-bin-debug/'
    bin_debug_url = 'url-to-bin-debug'
    name = bin_debug_dir + request.GET['name'] + debug + '.html'
    kwargs['extra_context']['flash_template'] = name
    kwargs['extra_context']['bin_debug_url' ] = bin_debug_url
  return direct_to_template( request, **kwargs ) 

urls.py

url( r'^djangoflash/', 'views.djangoflashview', 
     { 'template': 'djangoflash.html' }

foo.mxml's run-debug target:

/url-to-django/djangoflash/?name=foo

When you debug foo.mxml, flex:

1. Adds &debug=true to the url
2. Brings up a browser to /url-to-djangoflash/djangoflash/?name=foo&debug=true
3. Which picks djangoflash/ in urls.py
4. Which passes the request to djangoflashview and {'name':'foo','debug':'true'} to request.GET in views.py
5. Which figures out the name and location of the foo-debug.html location, passing it to the flash_template context variable
6. And the url of the swf to the bin_debug_url context variable
7. And loads up the direct template djangoflash.html
8. Which, in djangoflash.html, includes the foo-debug.html wrapper for flash using the flash_template context variable
9. Which, in turn fills in the bin_debug_url context variable to point the foo.swf reference correctly to the thing you just compiled

Whew. :-P