{"issue":{"created_at":"2011-12-13T02:02:14Z","state":"open","updated_at":"2011-12-13T22:10:33Z","comments":1,"user":{"gravatar_id":"7a81f54a7d8275fa8a04db65bed04d0e","id":717852,"url":"https://api.github.com/users/bluecamel","login":"bluecamel","avatar_url":"https://secure.gravatar.com/avatar/7a81f54a7d8275fa8a04db65bed04d0e?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"body":"Importing staff_member_required for this caused an import error for me.  I modified cloud_browser.views.settings_view_decorator to allow CLOUD_BROWSER_VIEW_DECORATOR to be set to either a callable or a string.  If a string, it assumes that it is the full path to the decorator, which it imports.","assignee":null,"id":2531885,"number":2,"labels":[],"pull_request":{"patch_url":"https://github.com/ryan-roemer/django-cloud-browser/pull/2.patch","html_url":"https://github.com/ryan-roemer/django-cloud-browser/pull/2","diff_url":"https://github.com/ryan-roemer/django-cloud-browser/pull/2.diff"},"title":"More flexible CLOUD_BROWSER_VIEW_DECORATOR","html_url":"https://github.com/ryan-roemer/django-cloud-browser/issues/2","closed_at":null,"url":"https://api.github.com/repos/ryan-roemer/django-cloud-browser/issues/2","milestone":null},"action":"created","comment":{"created_at":"2011-12-13T22:10:33Z","updated_at":"2011-12-13T22:10:33Z","user":{"gravatar_id":"bac1934aec2a98a77832526a14eefbfc","id":445557,"url":"https://api.github.com/users/ryan-roemer","login":"ryan-roemer","avatar_url":"https://secure.gravatar.com/avatar/bac1934aec2a98a77832526a14eefbfc?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png"},"body":"\r\nHi Branton,\r\n\r\nThanks for taking the time to diagnose and wrap this up. The real problem here is the order of imports when loading settings.py. I've separately found that importing ``django.contrib.admin.views.decorators`` does cause havoc in some settings files. (And apologies for not documenting this better earlier).\r\n\r\nThe real solution is to delay importing of the decorator until **after** the settings has finished loading. Your pull request in effect does this by delaying the import evaluation for string module paths into the ``settings_view_decorator`` call, which is after settings load.\r\n\r\nThe proper way to do this is to formally prevent the settings-time loading with a wrapper like so in \"settings.py\":\r\n\r\n```python\r\ndef lazy_staff_member_required(view_func):\r\n    \"\"\"Restrict all cloud browser views to staff users.\r\n\r\n    .. note:: Importing certain decorators into settings.py can have weird\r\n        ordering conflicts. Using this wrapping decorator, we can defer all\r\n        imports until **after** settings have been loaded.\r\n    \"\"\"\r\n    from django.contrib.admin.views.decorators import staff_member_required\r\n    return staff_member_required(view_func)\r\n\r\nCLOUD_BROWSER_VIEW_DECORATOR = lazy_staff_member_required\r\n```\r\n\r\nI'm not a real proponent of mucking with ``__import__`` and pushing raw string imports, especially here because it's a loading time issue and not a \"need variably-named module\"-type issue that is the usual reason for allowing raw ``__import__``.\r\n\r\nIf I updated the documentation with the example above, would that seem to work for you to resolve the issue? (And, does the above actually work for your current use case?)\r\n\r\nThanks!,\r\nRyan\r\n\r\n","id":3131423,"url":"https://api.github.com/repos/ryan-roemer/django-cloud-browser/issues/comments/3131423"}}