Django-fr

Forum

#1 11-04-2014 13:53:24

frankynov
Membre
Inscription : 11-04-2014
Messages : 6

Conseils pour bien commencer

Bonjour à tous,

Dans le cadre de mon stage de fin d'études, on m'a demandé de réaliser un site internet en Django.
Le but de ce site est de gérer des services qui constituent une architecture de type 'pipe-line'.

561733pipeline.png

Mon rôle est le suivant :
Je dois pouvoir, à travers le site web, envoyer et recevoir des commandes sur l'architecture afin de :
* Récupérer la liste des services avec leurs états
* Récupérer des listes de séquences d'exécution
* Envoyer des commandes (stop, start, ... ) à ces services/séquences

J'aimerais rester le plus simple possible, aussi il n'y aura pas de base de données liée au site web. Donc à chaque fois que j'ai besoin d'une liste de services par exemple, j'envoie la requête quelque part et j'attends en retour la liste des services.

Auriez-vous quelques conseils à me donner ?
J'ai suivi les quelques tutos sur les sondages mais je n'ai aucune idée de comment adapter les exemples à mon projet. C'est l'organisation de Django qui me perturbe beaucoup (sans parler que je n'utiliserai pas de DB et que tous les tutos en utilisent une)
Déjà juste afficher dans un tableau la liste des services en utilisant Django me semble être tiré par les cheveux. Comment pourrais-je m'y prendre ?

Merci ! smile

Hors ligne

#2 11-04-2014 19:13:26

Djok
Membre
Inscription : 12-07-2012
Messages : 26

Re : Conseils pour bien commencer

Bonjour,

Pourrais-tu s'il te plait expliquer ce qu'est une architecture pipeline et ton schéma ? ça à l'air super intéressant.

Tu dis qu'il n'y aura pas de base de données liée au site web pourtant dans le schéma on en voit bien une ?

Que sont censé faire tes services ?

Bon courage pour ton projet.

Hors ligne

#3 12-04-2014 07:49:24

Xavier Ordoquy
Administrateur
Lieu : Puteaux, France
Inscription : 12-10-2011
Messages : 312
Site Web

Re : Conseils pour bien commencer

Il est tout à fait possible de ne pas avoir de base de données. En revanche, cela demande un peu de recul que tu n'as pas encore. Par conséquent, utilises-en une simple pour commencer même si ton code n'y fait pas appel.
Pour ne pas utiliser la base, il te faudra probablement utiliser des classes de base (FormView au lieu de Create/Update/DeleteForm, forms.Form au lieu de forms.ModelForm etc etc). Prend le temps de lire la documentation Django sans rechercher un point précis et tu auras tout ce qu'il te faut pour avancer.

Hors ligne

#4 14-04-2014 09:07:50

frankynov
Membre
Inscription : 11-04-2014
Messages : 6

Re : Conseils pour bien commencer

Bonjour,
Désolé de ne répondre que maintenant, ce fut un week-end un peu chargé ! smile

Alors pour répondre à Djok, je ne peux pas te révéler tout le fonctionnement interne du projet (confidentialité oblige).
Mais dans les grandes lignes :
Le "cerveau" du système est l'organizer. C'est lui qui gère les services connectés. Un service, tu peux le voir comme une "machine" qui réalise une ou plusieurs tâches. C'est en fait un programme (python ou même en autre langage) qui reçoit des ordres (ex: "calcule la dérive stellaire") et qui renvoie le résultat.
Chaque succession de tâche est donc gérée par l'organizer pour former en tout une "séquence d'exécution".

Les résultats des tâches sont envoyés via réseau avec une API que j'ai développée en Python pendant la première partie de mon stage. En ce moment ça utilise ZMQ, pas facile à comprendre au début mais ça marche plutôt bien.
Ces résultats transitent donc sur 3 "bus" (forwarders). Ce sont un peu les "câbles réseau" du système, chaque service y est connecté et envoie/reçoit des informations. Cette partie de création de protocole de communication est donc déjà opérationnelle, mais aucun service n'existe pour le moment.

Tu dis qu'il n'y aura pas de base de données liée au site web pourtant dans le schéma on en voit bien une ?

Oui, le schéma n'est peut-être pas vraiment récent. Il a été réalisé avant de faire l'analyse UML et les scénarios d'utilisation. Mais je n'aurai pas besoin de base de données.

Concernant le serveur web :

On peut le voir comme un service connecté au système. Il ne reçoit aucun ordre de la part de l'organizer et ne sera utilisé que pour la consultation des données du système et envoyer quelques commandes d'exécution à l'organizer.
Encore une fois à préciser : je dois uniquement envoyer des commandes à l'organizer. Pour la gestion de séquences ou services, les commandes d'action ne demanderont pas un élément de retour et ce ne sera que du texte ("calcule la dérive stellaire", "relance la séquence numéro 42", "donne-moi la liste des séquences") qui sera envoyé. C'est à l'organizer de se débrouiller pour interpréter les ordres reçus, et ça c'est pas mon boulot wink

Je vois mon système en 3 pages principales (on exclut celle de login par exemple) :

Page de gestion de séquences
* Une liste déroulante (ou un tableau ?) avec la liste des séquences d'exécution + leur statut (en cours, arrêté, ... ), le tout récupéré de l'organizer (qui aura sûrement une BDD pour fournir ces infos)
* On clique sur une séquence dans la liste, on obtient la liste des tâches de cette séquence + leur statut
* On peut contrôler la séquence (la redémarrer, l'arrêter, ...)

Je le vois comme ceci :

913618Capturedcran20140414094401.jpg

Page de gestion des services
* Liste déroulante avec les services connectés au système + statut
* On clique sur un service et on peut voir les tâches qui leur sont attribuées.
* On peut contrôler le service (démarrer, arrêter, ... )

Donc grosso modo la même page, mais avec les services.

Page de visualisation des données
Chaque séquence contient des données générées par leurs tâches.
* Liste déroulante des séquences
* On clique sur une séquence et on voit toute la liste des données associées (toujours fournies via l'organizer)
* On clique sur une donnée dans cette liste et on peut la consulter (image 2D, graphe avec jqplot, grandeurs scalaires)

Il y aura également une autre page qui permet de visualiser la liste des messages qui circulent sur le bus, mais c'est ultra basique.

Vous l'aurez sans doute compris, ce site n'est en soi pas très très compliqué. En témoigne mon diagramme de séquence 'générique' :

781819Capturedcran20140414095331.jpg

Le plus dur pour moi va être de comprendre le fonctionnement de Django et comment l'architecturer à mon projet. Je n'ai malheureusement quasi jamais touché au développement web (à part une fois en cours mais ça s'est résumé à du copier/coller de code dégueulasse du prof, sans comprendre), et la programmation même tout court n'est pas vraiment dans ma formation.
On va se débrouiller smile J'ai quand même réussi à apprendre le python sans cours et c'est une petite fierté personnelle big_smile

@Xavier, merci pour les pistes des formview, je vais regarder ça attentivement. Donc forms.Form par rapport à forms.ModelForm, c'est à privilégier quand on n'utilise pas de BDD ? ModelForm, c'est ce qui est généré automatiquement avec les BDD ?

Je pense que je vais essayer un exemple simple : afficher la liste de mes séquences avec leur statut.
Pour cela, vous me conseillez de travailler avec un dictionnaire python ? Quelle est votre opinion sur la meilleure manière d'afficher des éléments ne provenant pas d'une BDD dans un tableau ?

Merci de m'avoir lu smile

Hors ligne

#5 14-04-2014 17:55:41

Djok
Membre
Inscription : 12-07-2012
Messages : 26

Re : Conseils pour bien commencer

C'est moi qui te remercie d'avoir pris le temps d'expliquer ton projet.

Au risque de fâcher les Django Addicts je crois que vu que ton site n'est qu'une interface à un système complexe tu devrais utiliser quelque chose de plus léger (Cherrypy, Flask, Bottle) tu perdras moins de temps en apprentissage et ça te permettra de réaliser facilement ce que tu veux faire. Si tu utilise déjà Python pour communiquer avec tes services ce devrait être facile d'intégrer un client pour récupérer les résultats et un autre pour communiquer avec l'organiseur. La difficulté c'est que tu passe des commandes à une machine mais tu reçois le résultat de machines différentes. Je ne sais pas comment tu gère ça. A moins que tu récupère tout de l'organiseur c'est encore un peu floue mais je vais relire attentivement.

Est-ce que ton API fonctionne dessus TCP/IP ? Je pense que oui puisque tu parle de "le réseau" mais bon sait-on jamais...

Effectivement si ton organiseur a une base de données tu n'as rien besoin de stocker.

Bon courage.

Dernière modification par Djok (14-04-2014 17:56:03)

Hors ligne

#6 16-04-2014 16:01:11

frankynov
Membre
Inscription : 11-04-2014
Messages : 6

Re : Conseils pour bien commencer

Salut Djok,

Alors j'ai tâté un peu CherryPy... Et ça m'a vraiment, mais vraiment moins parlé que Django... Je suis tout à fait d'accord que mon projet peut être simplifié, mais étant débutant dans la programmation web je cherchais un framework qui puisse avoir de la documentation et soit utilisé à grande échelle (instagram par exemple smile )
Et puis j'ai l'impression qu'avec cherrypy il faut écrire le code HTML dans les fichiers python et de ce que j'ai lu, cherrypy ne gère pas vraiment l'orienté objet.
De plus, Pycharm gère django à la perfection. Il connait son fonctionnement et peut donc anticiper mes erreurs, chose qu'il ne sait malheureusement pas faire avec cherrypy.

La difficulté c'est que tu passe des commandes à une machine mais tu reçois le résultat de machines différentes. Je ne sais pas comment tu gère ça.

L'idée c'est que mon serveur web a 2 sockets : un pour envoyer, un pour recevoir (je parle niveau commandes, pas HTTP). Dans sa configuration, on lui dit à quelle adresse envoyer les commandes (l'adresse et port de l'organizer). Et c'est l'organizer qui renvoie toutes les informations de tous les services connectés, le serveur web ne communique donc qu'avec lui en fait.

Est-ce que ton API fonctionne dessus TCP/IP ? Je pense que oui puisque tu parle de "le réseau" mais bon sait-on jamais...

Oui ! Mais en utilisant ZMQ, qui fait un peu fi de toutes les "lois" des sockets. Comme je n'ai jamais touché à ça avant (et encore moins en python), ça m'a permis d'avoir rapidement de la communication à travers un réseau ethernet. Il faut bien évidemment que chaque service du pipeline utilise ZMQ sinon ça ne marche pas wink

Bon sinon, j'ai touché un peu à Bootstrap, c'est génial ! Et je découvre la possibilité de changer certains composants en utilisant du CSS, ça m'a lair bien puissant !
Voici où en est ma page d'accueil pour le moment : (clic pour agrandir)
mini_406684Capturedcran20140416163500.jpg

J'ai galéré grave pour que les fichiers du dossier static soient visibles partout dans chaque page ! C'est en ce moment le gros point noir de django que je puisse faire d'un point de vue de débutant.

D'ailleurs, je n'ai pas totalement résolu le problème car si pour les images/css/js cela fonctionne, j'ai un même souci avec mes templates. Voici la structure du projet, je suis le guide d'openclassrooms (anciennement site du zéro) :

194735Capturedcran20140416162103.jpg

Mon application courante est blog, les dossier static et templates sont situés au même niveau.
Pour accéder aux images, pas de problème, je fais ceci dans mon HTML :

<img src="{% static 'img/soiree-choucroute.jpg' %}" class="img-responsive"><br>

avec ces paramètres définis dans settings.py :

BASE_DIR = os.path.dirname(os.path.dirname(__file__))
#.......#
STATIC_ROOT = ''
STATIC_URL = '/static/'
STATICFILES_DIRS = (
    BASE_DIR+'/static/',
)

J'accède à ma page via

http://127.0.0.1:8000/blog/

Par contre, dans un fichier "header.html" qui contient ma navbar, je veux qu'en permanence le bouton séquence pointe vers mon fichier sequence.html. Et cela ne marche pas vraiment.

Quand j'essaye d'accéder à

http://127.0.0.1:8000/blog/articles/2013/12/

, ma page s'affiche mais je ne parviens pas à faire fonctionner mon lien (404).
Si je définis une vue et que j'encore à la main en "dur" l'url ça semble marcher mais je ne pense pas que ce soit propre (en témoigne Pycharm) :

144560Capturedcran20140416165142.jpg

Une idée ? sad

Voici mon fichier urls.py (appli blog) :

urlpatterns = patterns('blog.views',
    url(r'^accueil/$', 'home'),
    url(r'^$', 'tpl'),
    url(r'^article/(?P<id_article>\d+)/$', 'view_article', name="afficher_article"), # Vue d'un article
    url(r'^articles/(?P<year>\d{4})/(?P<month>\d{2})/$', 'list_articles'), # Vue des articles d'un mois précis
    #OLD VERSION url(r'^article/(\d{4})/(\d{2})/$', 'list_articles'),
    url(r'^redirection/$', 'view_redirection', name="redirect"),
    url(r'^sequence/$', 'sequence'),
)

et ma vue sequence(request) fait un simple return render(request, "sequence.html")

Merci ! smile

Hors ligne

#7 16-04-2014 19:58:50

Djok
Membre
Inscription : 12-07-2012
Messages : 26

Re : Conseils pour bien commencer

Salut,

Je vois que tu as bien avancé ce serait dommage de changer de framework en effet. Par contre c'est faux de dire que Cherrypy n'est pas documenté, il l'est autant mais il y a moins de composants (voir le guide de référence sur le site officiel). Il est totalement orienté objet, je ne vois pas ce qu'il te fait dire ça. Et il n'oblige pas à écrire l'HTML dans les sources mais supporte plusieurs langages de templates sans les fournir, c'est sûrement pour cette raison que les exemples fournis par la littérature code HTML directement dans le code source.

Mais bon ce n'est pas la question, l'idée était de passer moins de temps sur l'apprentissage de Django en utilisant quelque chose de moins fournis. Mais tu peux aussi faire ce que tu veux faire avec Django sans problème.

Il va falloir je pense passer par du pur python pour la communication avec l'organiseur, car je ne pense pas que Django propose quelque chose pour ça. Mais bon je pense que ce n'est pas un problème pour toi vu que tu l'as déjà fait. Tu peux utiliser des composant qui ne sont pas Django dans une application Django. Donc si tu as un module pour 0MQ il suffit de l'utiliser depuis les vues ça devrait le faire. Le fait que tu ne communique qu'avec l'organiseur va rendre les choses plus faciles. A la lecture du schéma je pensais plus à un truc genre "j'envoie le calcul sur un service et je récupère les résultats quand ils sont disponibles auprès du service".

Pour Bootstrap je l'utilise aussi et c'est vrai que ça fait gagner beaucoup de temps en permettant d'avoir une jolie interface avec quelques règles CSS. Bien pratique...

Venons-en aux statics... C'est vrai que ce n'est pas facile au début, d'autant que cette gestion ne semble pas être la même d'un Django à un autre. Avec la 1.6 je n'ai pas trop été embêter avec ça. Pour le serveur de développement normalement tout doit être transparent, si tu as DEBUG à True le serveur est capable de prendre tes statics dans chaque dossier de chaque application.

C'est la fonctionnement pour toutes les versions de Django que j'ai essayées (1.4 et 1.6). Normalement tu n'as pas à faire ce que tu as fait avec le serveur de dev.

En production c'est un peu plus compliqué, il faut d'abord collecter les statics dans un dossier à la racine (c'est en fait ce que tu as fait). Django propose une commande qui te fait ça automatiquement :

python manage.py collectstatic

Mais il faut avoir spécifier un nom de dossier STATIC_ROOT pour recueillir les fichiers, rien ne doit être mis dans ce dossier c'est seulement lors du passage en prod qu'on les rassemble ici pour que ton serveur de static puisse les trouver.

Avec la 1.6 j'utilise dj-static et gunicorn et ça a fonctionné nikel après avoir passé la commande sur le serveur de prod.

Par contre dj-static ne fonctionne pas avec la 1.4, il existe un patch mais impossible ensuite de faire fonctionner collectstatic et j'ai été obligé d'indiquer le dossier des statics dans le dossier du projet. C'est le seul endroit ou il les trouve.

Du coup seul les urls précédés de static renvoient les statics mais celle de l'administration impossible car collectstatic les place dans un dossier admin dans static et l'url appelé par l'admin utilise que admin/base.css non static/admin/base.css. Même si je déplace le dossier admin dans static c'est pareil.

Du coup j'ai bien les CSS de mon projet mais pas ceux de l'admin. Je pense qu'il y a un bug dans dj-static, j'ai lu des choses en anglais sur le web, ou c'est peut-être moi enfin je sais pas. Donc moralité si tu utilise heroku utilise django 1.6 c'est beaucoup plus facile. Par contre j'ai essayé Apache/Debian avec Django1.4 et ça marche super bien on rassemble les statics dans un dossier et on dit à Apache de les servir. Nikel

Pour les templates avec django 1.6 j'ai le même problème que toi obligé de les mettre à la racine. Mais je pense qu'il faut utiliser TEMPLATES_DIR. à voir...

Pour ta dernière erreur le message renvoyé par ton erreur doit être relativement explicite, à moins que tu ne sois pas en mode DEBUG, ce qui pourrait expliquer tes soucis avec les statics. Est-ce que tu utilises le serveur de développement ? Est ce que DEBUG=True ? Le cas échéant que dit le traceback ?


@+ et bon courage

Dernière modification par Djok (16-04-2014 20:00:56)

Hors ligne

#8 16-04-2014 20:52:00

Djok
Membre
Inscription : 12-07-2012
Messages : 26

Re : Conseils pour bien commencer

MERCI!!

En fait pour ton problème de templates j'ai compris ton erreur et la mienne.

Dans ton settings.py :

BASE_DIR = os.path.abspath(os.path.dirname(__file__))

et non :

BASE_DIR = os.path.dirname(os.path.dirname(__file__))

Sinon tu dis à Django d'aller chercher dans le dossier qui contient le dossier de ton projet, donc du coup il ne cherche que là.

A+

Hors ligne

Pied de page des forums