Feature proposal: djangoStatic service

[jkosir]

After the introduction of djangoUrl service we've seen that the current approach might not be best in all cases, but instead 301 MOVED PERMANENTLY would be prefered.

As that doesn't really work with POST we basically have to keep the current approach to ensure all kinds of requests work.

I remember an issue when someone wanted to use djangoUrl for loading of a angular template.html file, somewhere in route configuration. djangoUrl isn't meant for that, rather we would need something like the {% static %} template tag.

So a djangoStatic service, behaving like the {% static %} template tag, this time with 301 MOVED PERMANENTLY responses (the djangoUrl approach wouldn't make do, since static files can be hosted on other servers, say amazon s3).

I think this would make a nice addition, any feedback?

[jrief]

Originally I implemented this alternative, but after I've seen that we can't use it for POST requests, I dropped the idea. Probably there is still some code around, just dig though my commits. However I don't the wording "static", rather I'd prefer something such as "redirect" or "moved to/permanenty/temporarily" or "location" to be more concise with the wording used by HTTP.

Since you will use HTTP code 301 or 302 in my opinion we should use the same wording as they do.

But anyway, yes I like the idea and please proceed with it.

[jkosir]

I'm pretty sure this should be called djangoStatic as it's a replacement for {% static %} tag and not a redirect version of djangoUrl.reverse().

While we are at that, maybe we could add a redirect version of reverse to djangoUrl, e.g. djangoUrl.reverseRedirect(). On the client side all the code can be reused with only a bit different url.

But it would require developers to make a not-really-necessary choice on which one to use. I'd suggest we put docs about this only as a note at the end of current djangoUrl documentation, if we go for it.

[adrienbrunet]

Any update @jkosir?