Cosa ti impedisce di usare myproduct.myproduct? Ciò di cui hai bisogno per raggiungere questo obiettivo consiste essenzialmente nel fare questo:
django-admin.py startproject myproduct
cd myproduct
mkdir myproduct
touch myproduct/__init__.py
touch myproduct/models.py
touch myproduct/views.py
e così via. Aiuterebbe se dicessi views.pyche non deve essere chiamato views.py? A condizione che tu possa nominare, sul percorso python, una funzione (di solito package.package.views.function_name) che verrà gestita. Semplice come quella. Tutta questa roba "progetto" / "app" è solo pacchetti python.
Ora, come dovresti farlo? O meglio, come potrei farlo? Bene, se crei una significativa funzionalità riutilizzabile, come ad esempio un editor di markup, è quando crei una "app di livello superiore" che potrebbe contenerewidgets.py , fields.py, context_processors.pyecc - tutte le cose che si potrebbe desiderare di importazione.
Allo stesso modo, se riesci a creare qualcosa di simile a un blog in un formato piuttosto generico tra le installazioni, puoi racchiuderlo in un'app, con il suo modello, cartella di contenuti statici ecc. E configurare un'istanza di un progetto django per usarlo contenuto dell'app.
Non ci sono regole rigide e veloci che dicono che devi farlo, ma è uno degli obiettivi del framework. Il fatto che tutto, inclusi i modelli, ti consenta di includere da una base comune significa che il tuo blog dovrebbe adattarsi perfettamente a qualsiasi altra configurazione, semplicemente occupandosi della propria parte.
Tuttavia, per rispondere alle tue attuali preoccupazioni, sì, nulla dice che non puoi lavorare con la cartella di progetto di livello superiore. Questo è ciò che fanno le app e puoi farlo se lo desideri davvero. Tendo a non, tuttavia, per diversi motivi:
- L'impostazione predefinita di Django non lo fa.
- Spesso, voglio creare un'app principale, quindi ne creo una, di solito chiamata
website . Tuttavia, in un secondo momento potrei voler sviluppare funzionalità originali solo per questo sito. Al fine di renderlo rimovibile (anche se non lo faccio mai) tendo a creare una directory separata. Questo significa anche che posso eliminare tale funzionalità semplicemente scollegando quel pacchetto dalla configurazione e rimuovendo la cartella, piuttosto che una complessa cancellazione degli URL corretti da una cartella globale urls.py.
- Molto spesso, anche quando voglio rendere qualcosa indipendente, ha bisogno di un posto in cui vivere mentre lo prendo cura / lo faccio indipendente. Fondamentalmente il caso sopra, ma per cose che intendo fare generico.
- La mia cartella di livello superiore contiene spesso alcune altre cose, inclusi ma non limitati a script wsgi, script sql ecc.
- Le estensioni di gestione di django si basano su sottodirectory. Quindi ha senso nominare i pacchetti in modo appropriato.
In breve, la ragione per cui esiste una convenzione è la stessa di qualsiasi altra convenzione: aiuta quando si tratta di altri che lavorano con il tuo progetto. Se vedo, fields.pymi aspetto immediatamente che il codice in esso sia una sottoclasse del campo di Django, mentre se vedo inputtypes.pypotrei non essere così chiaro su cosa significhi senza guardarlo.