thank you for reply
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Wed, May 13, 2020 at 10:14 PM Christian González < christian.gonza...@nerdocs.at> wrote: > Hi all, > > I didn't find anything about that in the archive here, so I'd like to come > to you with an idea which is either very dumb (please tell me) or I don't > know why anyone hasn't thought about it... > > I'm starting a bigger project with a self-created plugin system (GDAPS, > alrady mentioned). Working nicely, but I came across a few Django > shortcomings which are sometimes easy to workaround, but could be done > better: the django project name. > > TL;DR: Django has no (builtin/explicit) settings variable like > PROJECT_NAME. Should have. > > Long version: > > If you have (like in my case) an application which is more than a single > django app, and could have various 3rd party additions/plugins, there is no > common sense of retrieving the overall "name" of the application. If you > create a project using django-admin startproject myproject - the name > says it, you name the project. It is written into various places, mostly > comments etc.: > > foo/asgi.py:ASGI config for foo project. > foo/asgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings') > foo/settings.py:Django settings for foo project. > foo/settings.py:ROOT_URLCONF = 'foo.urls' > foo/settings.py:WSGI_APPLICATION = 'foo.wsgi.application' > foo/urls.py:"""foo URL Configuration > foo/wsgi.py:WSGI config for foo project. > foo/wsgi.py:os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'foo.settings') > manage.py: os.environ.setdefault('DJANGO_SETTINGS_MODULE', > 'foo.settings') > > But foo is no variable. Needers of this inofficial project name use > workarounds like settings.ROOT_URLCONF[0] to get that name. But that's > always a bit of a whacky feeling when I do it - doesn't seem like - "I'm > sure this will be supported for the next 20 years". > > When it comes to frontends, it's worse. In my case, my GDAPS module > enables a Vue.js frontend, which needs a index.html which loads Vue. This > file is (in SPA apps) the only file which is rendered using Django > templates. No problem, put in gdaps' templates directory and go. Works > fine, as long as the user of GDAPS is fine with my shipped index.html and > the corresponding pre-defined url path that renders that index file using > TemplateView. > > If he wants to override that file using his own template (with maybe > another font loaded etc.) I first thought I just change GDAPS to > dynamically load the template in GDAPS' urls.py - but therefore it should > know the name of the project it is a part of. > > I can do that using a setting named PROJECT_NAME and place a url > definition like > > path("", > TemplateView.as_view(template_name=os.path.join(settings.ROOT_URLCONF[0],"index.html")), > name="app") > > into urls.py. So the user can place an index.html into foo/templates/foo/ and > it should work. > > But as said, this seems to me as - hey, ROOT_URLCONF[0] - really, this is the > project name? > path("", > TemplateView.as_view(template_name=os.path.join(settings.PROJECT_NAME,"index.html")), > name="app") > > seems better to me. > I first thought that Django could provide that as "builtin" setting, but > OTOH, explicit is better than implicit, > so why not > a) create a setting (which is created by django-admin createproject along > with the other parsed templates) named > PROJECT_NAME o DJANGO_PROJECT_NAME > or > b) (because settings are not used in wsgi.py, manage.py etc.) create it > earlier in the process - or does it have to be written at more than one > places? > This would violate DRY. > > Please tell me what you think about that. > > Yours, > Christian > > -- > Dr. Christian Gonzálezhttps://nerdocs.at > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/37527e26-4e21-2684-5766-145441c6ae50%40nerdocs.at > <https://groups.google.com/d/msgid/django-developers/37527e26-4e21-2684-5766-145441c6ae50%40nerdocs.at?utm_medium=email&utm_source=footer> > . > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAKS_%2Ba0JFiBp4z8rbCWWyzjMKJoqEOaKSi3KRdU%2Bpa8LXxsbOQ%40mail.gmail.com.
