Alors, sorte d'une situation étrange ici. J'ai un projet Django à l'aide de TASTYPIE pour alimenter son API et certaines vues / modèles qui seront utilisés pour alimenter des plugins pour différents sites. Plutôt que de construire ces plugins en tant que modèles de Django standard, on m'a demandé d'utiliser notre API pour traiter les demandes des plugins, ce qui signifie que j'appelle une vue sur mon serveur depuis une autre vue et pour une raison quelconque qui ne fonctionne pas. avec n'importe lequel de mes points de vue. Pour référence: et les URLS correspondantes (dans une application différente): one idée sur la façon de résoudre ce problème? Je ne trouve aucun écriture sur le sujet. Edit: Plus précisément, qu'est-ce qui se passe est que lorsque je charge l'une de ces vues, ils accrochent en essayant de lire la page API. En outre, mon serveur ne montre aucune indication de demandes de traitement. (Bien que je puisse charger directement les pages de l'API.)
5 Réponses :
D'accord, donc j'ai déjà dit qu'avoir des vues faisant des points de vue sur d'autres points de vue, c'est une sorte de stupide, mais je vois ce que votre problème est actuellement. Vous appelez json.loads (URLLIB.URLOPEN (SITE_NAMELOPEN (SITE_NAME + URI)) , mais URLLIB.URLOPEN renvoie un objet de type fichier, pas une chaîne, donc il devrait réellement Soyez JSON.LOAD (URLLIB.URLOPEN (SITE_NAME + URI)) .
Apparemment pas, bien que cela puisse être un problème plus tard, j'ai réussi à l'isoler jusqu'à "Urllib.urlopen (URL)". En outre, je remarque dans mon terminal qu'aucune demande ne se retrouve sur le serveur pour une raison quelconque (ce qui n'est pas le cas pour d'autres pages).
Y a-t-il une raison pour laquelle vous utilisez urllib2.build_opener (). Ouvrez (URL) au lieu de urllib.urlopen (URL) dans certains endroits?
Maintenant, votre commentaire a clarifié la situation, je peux supposer que le problème est. C'est que vous utilisez le serveur de développement intégré, qui est à filetage unique. Donc, alors qu'il s'agit de traiter la demande initiale, il n'est pas en mesure de traiter la demande interne d'une autre URL - de sorte qu'il se bloque indéfiniment.
La solution, comme le souligne Mao, est de penser à une meilleure architecture. Si vous ne pouvez pas faire cela, vous pouvez avoir une chance avec quelque chose comme Gunicorn au lieu du serveur intégré.
particulier à la tastypie Vous pouvez utiliser vos ressources sous des vues, si vous en avez besoin, accéder directement aux objets et appeler les méthodes d'obtention et la construction du paquet.
Vous pouvez découvrir comment: http: //django-tasypie.readthedocs. Org / fr / Dernier / recokook.html
Aller à la section intitulée - Utilisation de votre ressource dans des vues régulières
convenu, votre serveur de développement n'a probablement qu'une seule instance. Lancer un autre sur un autre port. c'est à dire/ Site_Name = "http: // localhost: 8001 /"
Je viens de rencontrer le même problème, c'est-à-dire appeler une API du même serveur qu'il est hébergé. Comme le suggéra Daniel, j'ai pu résoudre ceci en utilisant plusieurs threads à Gunicorn:
À moins que vous utilisiez Ajax, je ne vois aucun avantage à la construction du site Web de cette manière. Je pense que votre problème est de parler à votre patron et de lui dire que son plan n'a pas beaucoup de sens (pas dans ces mots exacts bien sûr).
Honnêtement, je m'appuyais aussi vers cette solution, même si j'ai l'impression que cela devrait être possible de toute façon.
Plus précisément, ce qui se passe est que lorsque je charge l'un de ces points de vue, ils sont accrochés à la lecture de la page API. En outre, mon serveur ne montre aucune indication de demandes de traitement. (Bien que je puisse charger directement les pages de l'API.)