David Ascher wrote:
> Stumbling blocks:
> * figuring out that I had to do "import
> django.contrib.markup.templatetags.markup" to get the markup filters
> registered was harder than it should have been.
Did {% load markup %} not work? Maybe this tag needs to be pointed out
more prominently - it is at "Custom tag and filter libraries" in
http://www.djangoproject.com/documentation/templates/ .
> * understanding that the redirects involved in adding trailing /'s threw
> away POST data took me a while to figure out
Hm, maybe when DEBUG is on, CommonMiddleware should put up an
interstitial page to tell the developer what is happening? It does seem
to bite a lot of people.
> * I was stumped by the fact that I had to setup another web server to serve
> static files. It'd be nice if it was possible to serve static files with the
> development server. I'd consider sending in a patch if someone could throw
> suggestions my way on what approach would work best (or maybe it actually
> _is_ supported, I just didn't find out how!).
I've been thinking about this as well - maybe we should automatically
register /<appname>/media/ to use the static view to load out of
<appdir>/media in the development server.
So we could have a dictionary in settings,
MEDIA_PREFIXES = {
'wiki.apps.pages' : '/pages/media/' ,
'django.contrib.admin': 'http://media.example.com/admin/'
}
To override the default when not running in the dev server.
Then a template tag like {% media_prefix app %} which would rely on an
'app' variable in the context being the dot name of the app :
wiki.apps.pages. Maybe this could be done easily with DjangoContext, not
sure.
This would (I think) work obviously in the runserver, and be easily
extensible to other deployment scenarios.
