Kullanmanıza engel olan nedir myproduct.myproduct? Bunu başarmak için ihtiyacınız olan şey kabaca bunu yapmaktan ibarettir:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
ve bunun gibi. Söylediğim takdirde yardım eder misiniz views.pyçağrılacak zorunda değildir views.py? Python yolunda, bir işlevi (genellikle package.package.views.function_name) isimlendirebilmeniz koşuluyla, ele alınacaktır. Bu kadar basit. Tüm bu "proje" / "uygulama" şeyler sadece python paketleri.
Şimdi, bunu nasıl yapman gerekiyor? Ya da daha doğrusu nasıl yapabilirim? Eğer yeniden işlevsellik önemli parçasını oluşturmak buysa, böyle bir "üst düzey app" oluştururken içeriyor olabilir olduğunu, bir biçimlendirme editörü demek widgets.py, fields.py, context_processors.pyher şeyi İçe isteyebilirsiniz - vb.
Benzer şekilde, yüklemeler arasında oldukça genel bir biçimde bir blog gibi bir şey oluşturabilirseniz, bunu kendi şablonu, statik içerik klasörü vb.İle bir uygulamada tamamlayabilir ve bunu kullanmak için bir django projesinin örneğini yapılandırabilirsiniz. uygulamanın içeriği.
Bunu yapmanız gerektiğini söyleyen zor ve hızlı kurallar yoktur, ancak çerçevenin amaçlarından biridir. Şablonların dahil olduğu her şeyin, bazı ortak tabanlardan dahil etmenize izin vermesi, blogunuzun sadece kendi kısmına bakarak diğer herhangi bir düzene tam olarak sığması gerektiği anlamına gelir.
Ancak, asıl endişenizi gidermek için, evet, hiçbir şey en üst düzey proje klasörüyle çalışamayacağınızı söylemez. Uygulamaların yaptığı budur ve gerçekten isterseniz bunu yapabilirsiniz. Bununla birlikte, birkaç nedenden dolayı:
- Django'nun varsayılan kurulumu bunu yapmaz.
- Genellikle, ana bir uygulama oluşturmak istiyorum, bu yüzden genellikle denilen bir uygulama oluşturuyorum
website. Ancak, daha sonraki bir tarihte yalnızca bu site için özgün işlevler geliştirmek isteyebilirim. Çıkarılabilir hale getirmek için (hiç yapsam da yapmasam da) ayrı bir dizin oluşturma eğilimindeyim. Bu ayrıca, genel bir urls.py klasöründen doğru URL'leri karmaşık bir silmek yerine, bu paketin yapılandırma ile bağlantısını kesip klasörü kaldırarak söz konusu işlevselliği bırakabileceğim anlamına gelir.
- Çok sık, bağımsız bir şey yapmak istesem bile, bakarken / bağımsız kılmak için yaşamak için bir yere ihtiyacı vardır. Temelde yukarıdaki durum, ama şeyler için genel yapmak niyetinde.
- Üst düzey klasörüm genellikle wsgi komut dosyaları, sql komut dosyaları vb. Dahil ancak bunlarla sınırlı olmamak üzere birkaç şey daha içerir.
- django'nun yönetim uzantıları alt dizinlere dayanır. Bu nedenle paketleri uygun şekilde adlandırmak mantıklıdır.
Kısacası, bir sözleşmenin nedeni diğer sözleşmelerle aynıdır - projenizle çalışan başkalarına gelince yardımcı olur. Ben görürseniz fields.pyhemen ben görürsem oysa, Django alanını alt sınıfı diye içeri kodu bekliyoruz inputtypes.pybunu bakmadan 'ne anlama geldiğini bu konuda çok net olmayabilir.