- Change Summary:
-
So it turns out that just saying: templatetags_modules = [] isn't enough to wipe out the list in the django.template module. del(templatetags_modules[:]) ought to do the trick. The only reason it seemed to work for me was because my browser had cached an earlier successful request. I've also abstracted out the INSTALLED_APPS.append/remove into their own functions, which protects against accidental re-adds.
Fix Djblets extension template loader, and fix templatetags caching problem
Review Request #1678 — Created June 22, 2010 and submitted
Originally, it looked like the extension template loader was working just fine. I was wrong - for some reason, attempting to load an extension template from an extension that had *just* been enabled (and had been disabled at server boot) caused an exception (a "NoneType" was being called - eventually, I tracked this down to the get_provider function in pkg_resources... importing resource_string from pkg_resources didn't seem to do the job of initializing that function). Importing the _manager directly seems to fix this. I also realized there was a templatetag caching problem occurring. I've solved this by clearing the templatetag cache upon extension enable/disable.
Manual.
-
-
Invert the logic, like: if extension.info.app_name not in settings.INSTALLED_APPS: settings.INSTALLED_APPS.append(extension.info.app_name) -
-
This seems a little iffy to me.. If we can't import the manager, aren't we in trouble? At the least, the reason for this and the potential problems if we can't import this should be documented
- Change Summary:
-
Inverted logic as requested. Instead of checking to see if _manager is available, we just let the Exception fly though - because if we can't get to _manager, we're pretty buggered.
