Flux de travail AngularJS typique et structure de projet (avec Python Flask)
Je suis assez nouveau dans toute cette frénésie de framework côté client MV*. Il ne doit pas être AngularJS, mais je l'ai choisi parce qu'il me semble plus naturel que Knockout, Ember ou Backbone. Quoi qu'il en soit, à quoi ressemble le flux de travail? Est-ce que les gens commencent par développer une application côté client dans AngularJS et ensuite accrocher le back-end à elle?
Ou l'inverse en construisant d'abord le back-end dans Django, Flask, Rails, puis en y attachant une application AngularJS? Est-il un "droit" façon de le faire, ou est-ce juste une préférence personnelle à la fin?
Je ne suis pas sûr non plus de structurer mon projet en fonction du Flask ou AngularJS? pratiques communautaires.
Par exemple, L'application Minitwit de Flask est structurée comme suit:
minitwit
|-- minitwit.py
|-- static
|-- css, js, images, etc...
`-- templates
|-- html files and base layout
L'application tutoriel AngularJS est structurée comme ceci:
angular-phonecat
|-- app
`-- css
`-- img
`-- js
`-- lib
`-- partials
`-- index.html
|-- scripts
`-- node.js server and test server files
Je pourrais imaginer une application Flask par elle-même, et il est assez facile de voir L'application AngularJS comme ToDo List par elle-même, mais quand il s'agit d'utiliser ces deux technologies, je ne comprends pas comment ils travaillent ensemble. Il semble presque que je n'ai pas besoin d'un web-framework côté serveur lorsque vous avez déjà AngularJS, un simple serveur web Python suffira. Dans L'application AngularJS to-do par exemple, ils utilisent MongoLab pour parler à la base de données en utilisant L'API Restful. Il n'y avait pas besoin d'avoir un framework web sur le back-end.
Peut-être que je suis juste terriblement confus, et AngularJS n'est rien de plus qu'une bibliothèque jQuery de fantaisie, donc je devrais utiliser comme j'utiliserais jQuery dans mon flacon projets (en supposant que je change la syntaxe du modèle AngularJS à quelque chose qui n'est pas en conflit avec Jinja2). J'espère que mes questions auront un sens. Je travaille principalement sur le back-end et ce framework côté client est un territoire inconnu pour moi.
6 réponses
Je commencerais par organiser L'application Flask dans la structure standard comme suit:
app
|-- app.py
|-- static
|-- css
|-- img
|-- js
|-- templates
Et comme btford l'a mentionné, si vous faites une application angulaire, vous voudrez vous concentrer sur l'utilisation de modèles angulaires côté client et rester à l'écart des modèles côté serveur. Utiliser render_template ('index.html') fera en sorte que Flask interprète vos modèles angulaires comme des modèles jinja, de sorte qu'ils ne seront pas rendus correctement. Au lieu de cela, vous voudrez faire ce qui suit:
@app.route("/")
def index():
return send_file('templates/index.html')
Notez que l'utilisation de send_file() signifie que les fichiers seront mis en cache, donc vous pouvez utiliser make_response () à la place, au moins pour le développement:
return make_response(open('templates/index.html').read())
Ensuite, construisez la partie AngularJS de votre application, en modifiant la structure de l'application pour qu'elle ressemble à ceci:
app
|-- app.py
|-- static
|-- css
|-- img
|-- js
|-- app.js, controllers.js, etc.
|-- lib
|-- angular
|-- angular.js, etc.
|-- partials
|-- templates
|-- index.html
Assurez-vous que votre index.html inclut AngularJS, ainsi que tous les autres fichiers:
<script src="static/lib/angular/angular.js"></script>
À ce stade, vous n'avez pas encore construit votre API RESTful, vous pouvez donc demander à vos contrôleurs js de renvoyer des exemples de données prédéfinies (uniquement temporaires configuration). Lorsque vous êtes prêt, implémentez L'API RESTful et connectez-la à votre application angular avec angular-resource.js.
EDIT: j'ai mis en place un modèle d'application qui, bien qu'un peu plus complexe que ce que j'ai décrit ci-dessus, illustre comment on pourrait construire une application avec AngularJS + Flask, avec communication entre AngularJS et une simple API Flask. C'est ici si vous voulez le vérifier: https://github.com/rxl/angular-flask
, Vous pouvez commencer à chaque extrémité.
Vous avez raison de dire que vous n'avez probablement pas besoin d'un framework Côté Serveur complet avec AngularJS. Il est généralement préférable de servir des fichiers HTML/CSS/JavaScript statiques et de fournir une API RESTful pour le back-end que le client peut consommer. Une chose que vous devriez probablement éviter est de mélanger des modèles côté serveur avec des modèles côté client AngularJS.
Si vous souhaitez utiliser le Flacon pour servir vos fichiers (peut-être exagéré, mais vous pouvez l'utiliser néanmoins), vous copier le contenu de "app" de "angulaires-phonecat" en "statique" dossier "minitwit."
AngularJS est plus ciblé sur les applications de type AJAX, tandis que flask vous donne la possibilité de faire à la fois les applications web de style plus ancien et de créer des API RESTful. Il y a des avantages et des inconvénients à chaque approche, donc cela dépend vraiment de ce que vous voulez faire. Si vous me donnez quelques idées, je pourrais être en mesure de faire d'autres recommandations.
Cette Vidéo Officielle Jetbrains PyCharm par John Lindquist (angular.JS et JetBrains guru) est un bon point de départ car il montre l'interaction du webservice, de la base de données et de l'angulaire.js dans le flacon.
Il construit un pinterest clone avec flacon, sqlalchemy, flacon agité et angulaire.js en moins de 25 minutes.
Edit : Le nouveau guide de styleAngular2 suggère une structure similaire, sinon la même, beaucoup plus en détail.
La réponse ci-dessous cible les projets à grande échelle. J'ai passé beaucoup de temps à réfléchir et à expérimenter plusieurs approches afin que je puisse combiner un framework côté serveur (Flask avec App Engine dans mon cas) pour la fonctionnalité back-end avec un framework côté client comme Angular. Les deux réponses sont très bonnes, mais je voudrais suggérer un peu différent approche qui (dans mon esprit au moins) évolue d'une manière plus humaine.
Lorsque vous implémentez un exemple TODO, les choses sont assez simples. Lorsque vous commencez à ajouter des fonctionnalités et de petits détails sympas pour l'amélioration de l'expérience utilisateur, il n'est pas difficile de se perdre dans le chaos des styles, javascript, etc..
Mon application a commencé à se développer assez grand, donc je devais prendre un peu de recul et repenser. Initialement, une approche comme suggéré ci-dessus fonctionnerait, en ayant tous les styles ensemble et tout JavaScript ensemble, mais ce n'est pas modulaire et pas facilement maintenable.
Et si nous organisions le code client par fonctionnalité et non par type de fichier:
app
|-- server
|-- controllers
|-- app.py
|-- models
|-- model.py
|-- templates
|-- index.html
|-- static
|-- img
|-- client
|-- app.js
|-- main_style.css
|-- foo_feature
|-- controller.js
|-- directive.js
|-- service.js
|-- style.css
|-- html_file.tpl.html
|-- bar_feature
|-- controller.js
|-- directive.js
|-- service.js
|-- style.css
|-- html_file.tpl.html
|-- lib
|-- jquery.js
|-- angular.js
|-- ...
Et ainsi de suite.
Si nous le construisons comme ceci, nous pouvons envelopper tous nos répertoires dans un module angulaire. Et nous avons divisé nos fichiers de manière à ne pas avoir à passer par du code non pertinent lorsque nous travaillons avec une fonctionnalité spécifique.
Un coureur de tâches comme Grunt {[5] } correctement configuré, sera en mesure de trouver et concaténer et compiler vos fichiers sans trop de tracas.
Une autre option consiste à séparer complètement les deux.
project |-- server |-- client
Les fichiers liés à flask passent sous le dossier serveur et les fichiers liés à angularjs passent sous le dossier client. De cette façon, il sera plus facile de changer le backend ou front-end. Par exemple, vous voudrez peut-être passer de Flask à Django ou AngularJS à ReactJS à l'avenir.
Je pense qu'il est important de déterminer à quelle fin vous voulez faire la plupart de votre traitement de données - front end ou back end.
Si c'est frontal, alors allez avec le flux de travail angulaire, ce qui signifie que votre application flask fonctionnera comme une api où une extension comme flask-restful se terminera.
Mais si comme moi, vous faites le plus de travail sur le backend, alors allez avec la structure flask et ne branchez que angulaire (ou dans mon cas vue.js) pour construire le frontal (lorsque nécessaire)