Flux de travail et structure de projet AngularJS typiques (avec Python Flask)
Je suis assez nouveau dans toute cette frénésie de framework côté client MV *. Ce n'est pas obligatoirement AngularJS, mais je l'ai choisi parce que ça me semble plus naturel que Knockout, Ember ou Backbone. Quoi qu'il en soit, quel est le flux de travail? Est-ce que les gens commencent par développer une application côté client dans AngularJS, puis en y connectant le back-end?
Ou l'inverse en construisant d'abord le back-end dans Django, Flask, Rails et en y attachant une application AngularJS? Existe-t-il une "bonne" façon de procéder ou s'agit-il simplement d'une préférence personnelle?
Je ne sais pas non plus s'il faut structurer mon projet en fonction de Flask ou AngularJS? pratiques communautaires.
Par exemple, l'application minitwit de Flask est structurée de la manière suivante:
minitwit
|-- minitwit.py
|-- static
|-- css, js, images, etc...
`-- templates
|-- html files and base layout
Le tutoriel de l'application AngularJS est structuré comme suit:
angular-phonecat
|-- app
`-- css
`-- img
`-- js
`-- lib
`-- partials
`-- index.html
|-- scripts
`-- node.js server and test server files
Je pouvais imaginer une application Flask seule, et il est assez facile de voir une application AngularJS comme ToDo List en tant que telle, mais pour ce qui est d'utiliser ces deux technologies, je ne comprends pas comment elles fonctionnent ensemble. Il semble presque que je n'ai pas besoin d'un framework web côté serveur lorsque vous avez déjà AngularJS, un simple serveur web Python suffira. Dans l'application de tâche AngularJS, par exemple, ils utilisent MongoLab pour communiquer avec la base de données à l'aide de l'API Restful. Il n'était pas nécessaire d'avoir un framework Web sur le back-end.
Peut-être que je suis terriblement confus, et AngularJS n’est rien de plus qu’une bibliothèque jQuery sophistiquée, donc je devrais utiliser comme j’utiliserais jQuery dans mes projets Flask (en supposant que je change la syntaxe du modèle AngularJS en quelque chose qui n’entre pas en conflit avec Jinja2). J'espère que mes questions ont un sens. Je travaille principalement sur le back-end et ce framework côté client est un territoire inconnu pour moi.
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 utilisez une application Angular, vous voudrez vous concentrer sur l’utilisation de modèles angulaires côté client et éviter les modèles côté serveur. Si vous utilisez render_template ('index.html'), Flask interprétera vos modèles angulaires comme des modèles jinja, de sorte qu'ils ne seront pas restitués 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. Vous voudrez peut-être 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 afin 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 tout autre fichier:
<script src="static/lib/angular/angular.js"></script>
À ce stade, vous n'avez pas encore construit votre API RESTful. Vous pouvez donc faire en sorte que vos contrôleurs js renvoient des exemples de données prédéfinis (uniquement une configuration temporaire). Lorsque vous êtes prêt, implémentez l'API RESTful et connectez-la à votre application angular avec angular-resource.js.
EDIT: J'ai créé un modèle d'application qui, bien qu'un peu plus complexe que ce que j'ai décrit ci-dessus, montre comment créer une application avec AngularJS + Flask, intégrant une communication entre AngularJS et une simple API Flask. La voici si vous voulez la vérifier: https://github.com/rxl/angular-flask
Vous pouvez commencer de chaque côté.
Vous avez raison, vous n'avez probablement pas besoin d'un framework complet côté serveur avec AngularJS. Il est généralement préférable de servir des fichiers HTML/CSS/JavaScript statiques et de fournir une API RESTful au client pour le back-end. 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 Flask pour servir vos fichiers (il peut être excessif, mais vous pouvez néanmoins l'utiliser), copiez le contenu de "app" de "angular-phonecat" dans le dossier "statique" de "minitwit".
AngularJS est plus ciblé sur les applications de type AJAX, tandis que flask vous permet de créer à la fois des applications Web de style plus ancien et de créer des API RESTful. Chaque approche présente des avantages et des inconvénients. Cela dépend donc vraiment de ce que vous voulez faire. Si vous me donnez un aperçu, je pourrais peut-être faire d'autres recommandations.
Cette vidéo officielle de Jetbrains PyCharm de John Lindquist (angular.js et jetbrains guru) est un bon point de départ car elle montre l’interaction entre webservice, base de données et angular.js dans la bouteille.
Il construit un clone pinterest avec ballon, sqlalchemy, ballon-agité et angulaire.js en moins de 25 minutes.
Profitez de: http://www.youtube.com/watch?v=2geC50roans
edit: le nouveau guide de style Angular2 suggère une structure similaire, voire identique, avec beaucoup plus de détails.
La réponse ci-dessous cible les projets à grande échelle . J'ai passé pas mal de temps à réfléchir et à expérimenter plusieurs approches afin de pouvoir combiner un framework côté serveur (Flask avec App Engine dans mon cas) pour des fonctionnalités back-end avec un côté client. cadre comme angulaire. Les deux réponses sont très bonnes, mais je voudrais suggérer une approche légèrement différente qui (dans mon esprit du moins) évolue de 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 Nice pour améliorer l'expérience utilisateur, il n'est pas difficile de se perdre dans le chaos de styles, de javascript, etc.
Mon application a commencé à devenir assez grosse, alors j'ai dû prendre du recul et repenser. Initialement, une approche telle que suggérée ci-dessus fonctionnerait, en regroupant tous les styles et JavaScript, mais elle n’est ni modulaire ni facile à gérer.
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
|-- ...
etc.
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 agréable, de sorte que nous n'ayons pas à passer par un code non pertinent lorsque nous travaillons avec une fonctionnalité spécifique.
Un gestionnaire de tâches tel que Grunt correctement configuré, sera capable de trouver, concaténer et compiler vos fichiers sans trop de tracas.
Une autre option consiste à séparer complètement les deux.
projet | - serveur | - client
Les fichiers liés à flask se placent sous le dossier du serveur et les fichiers associés à angularjs sous le dossier client. De cette façon, il sera plus facile de changer le backend ou le front-end. Par exemple, vous souhaiterez peut-être passer ultérieurement de Flask à Django ou AngularJS à ReactJS.
Je pense qu'il est important de déterminer à quelle fin vous voulez effectuer la majeure partie de votre traitement de données - front-end ou back-end.
Si c'est frontal, choisissez le flux de travail angulaire, ce qui signifie que votre application de flacon fonctionnera davantage comme une API, où une extension comme un flacon reposant se terminera.
Mais si, comme moi, vous faites le plus de travail sur le backend, optez pour la structure du ballon et ne branchez que de manière angulaire (ou dans mon cas, vue.js) pour construire l’avant (si nécessaire)