Il existe des moyens d'alimenter vos modèles côté client à partir de modèles Django pour des optimisations intéressantes ; cependant, étant donné les similitudes entre les langages de modèles de Django et d'AngularJS, cela ne vaut presque jamais la peine ici. J'associerai le service statique d'AngularJS à l'outil Cadre REST de Django pour la plupart des projets de ce type.
Mon urls.py
L'ordre des opérations est presque toujours le suivant : d'abord les URL du cadre REST de Django (écrites de la manière la plus stricte possible), puis un modèle générique qui dirige tout le reste vers mon modèle d'application AngularJS de base dans mon fichier STATIC_ROOT
dir pour les scénarios de test/développement locaux :
if settings.DEBUG:
urlpatterns += patterns('django.contrib.staticfiles.views',
url(r'', 'serve', {
'document_root': settings.STATIC_ROOT,
'path': '/base.html'}
),
)
En faisant pointer toutes les demandes non appariées vers la même application/le même modèle, vous pouvez commencer à utiliser la méthode de l'historique des URL et du routage si vous préférez cela aux hashtags. Si vous prévoyez de vous en tenir aux hashtags, votre correspondance finale d'URL peut être plus stricte (par exemple, la correspondance de /
(URL Root) avec r'^$'
).
En production, j'utiliserai un proxy inverse ou un serveur HTTP à clients lents comme nginx pour servir le contenu AngularJS (statique), en envoyant les demandes de services REST à l'application Django WSGI.
Pour communiquer avec le cadre Django REST, je préfère avoir des objets JS de type classe pour transporter les données entre l'application AngularJS et le cadre Django REST. Pour cela, j'utilise angular-django-rest-resource pour générer des classes qui représentent les classes du modèle Django que j'expose dans les vues du cadre REST.
Pour un maximum de flexibilité dans les requêtes qu'angular-django-rest-resource peut faire pour les ressources, j'aurai l'option django-filtre backend installé pour le REST Framework comme décrit aquí . Cela permet aux ressources JS de demander les objets Django en étant limitées par des paramètres (par ex. /polls/?author=345&finished=1
).
Si vous déployez les opérations Django et REST sur un domaine distinct de serveurs à partir desquels le modèle principal AngularJS est servi (par exemple, si vous utilisez un CDN tiers sur un domaine Internet différent pour le HTML), il est important d'autoriser les requêtes inter-domaines vers ces ressources. Pour cela, je recommande l'option django-cors-headers intergiciel.
J'espère que cela vous sera utile. Ce n'est pas le site Il ne s'agit pas d'un ensemble de meilleures pratiques, mais c'est celui qui a fonctionné pour moi.