227 votes

Flux de travail et structure de projet typiques d'Angular.js (avec Python Flask)

Je suis assez novice dans cette frénésie de frameworks MV* côté client. Il n'est pas nécessaire que ce soit Angular.js, mais je l'ai choisi parce qu'il me semble plus naturel que Knockout, Ember ou Backbone. Bref, comment se déroule le travail ? Les gens commencent-ils par développer une application côté client en Angular.js, puis y connectent-ils le back-end ? Ou l'inverse, en construisant d'abord le back-end en Django, Flask ou Rails, puis en y rattachant une application Angular.js ? Existe-t-il une "bonne" façon de procéder, ou s'agit-il simplement d'une préférence personnelle en fin de compte ?

Je ne sais pas non plus si je dois structurer mon projet en fonction des pratiques de la communauté Flask ou Angular.js ?

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 du tutoriel Angular.js est structurée comme suit :

angular-phonecat
|-- app
    `-- css
    `-- img
    `-- js
    `-- lib
    `-- partials
    `-- index.html
|-- scripts
 `-- node.js server and test server files

Je peux m'imaginer une application Flask toute seule, et il est assez facile de voir une application Angular.js comme ToDo List toute seule, mais lorsqu'il s'agit d'utiliser ces deux technologies, je ne comprends pas comment elles fonctionnent ensemble. On dirait presque que je n'ai pas besoin d'un framework web côté serveur alors que vous avez déjà Angular.js, un simple serveur web Python suffira. Dans l'application Angular to-do, par exemple, MongoLab est utilisé pour communiquer avec la base de données à l'aide de Restful API. Il n'était pas nécessaire d'avoir un framework web en back-end.

Peut-être que je suis juste terriblement confus et qu'Angular.js n'est rien de plus qu'une bibliothèque jQuery fantaisiste que je devrais utiliser comme j'utiliserais jQuery dans mes projets Flask (en supposant que je modifie la syntaxe des modèles d'Angular pour 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.

170voto

Ryan Points 1718

Je commencerais par organiser l'application Flask selon la structure standard suivante :

app
|-- app.py
|-- static
    |-- css
    |-- img
    |-- js
|-- templates

Et comme l'a mentionné btford, si vous réalisez une application Angular, vous voudrez vous concentrer sur l'utilisation des modèles Angular côté client et rester à l'écart des modèles côté serveur. En utilisant render_template('index.html'), Flask interprétera vos templates Angular comme des templates Jinja, et le rendu ne sera pas correct. A la place, 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 pourriez vouloir 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 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 échantillons de données prédéfinis (il ne s'agit que d'une configuration temporaire). Lorsque vous êtes prêt, implémentez l'API RESTful et connectez-la à votre application angulaire 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, illustre comment on peut construire une application avec AngularJS + Flask, avec une communication entre AngularJS et une simple API Flask. Le voici si vous voulez le consulter : https://github.com/rxl/angular-flask

38voto

btford Points 4373

Vous pouvez commencer par l'une ou l'autre extrémité.

Vous avez raison de dire que 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 pour le back-end que le client pourra utiliser. Une chose que vous devriez probablement éviter est de mélanger les modèles côté serveur avec les modèles côté client d'AngularJS.

Si vous voulez utiliser Flask pour servir vos fichiers (c'est peut-être un peu exagéré, mais vous pouvez néanmoins l'utiliser), vous devez copier le contenu de "app" de "angular-phonecat" dans le dossier "static" de "minitwit".

AngularJS est davantage axé sur les applications de type AJAX, tandis que Flask vous permet de réaliser des applications Web de type 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 indications, je pourrais être en mesure de faire d'autres recommandations.

22voto

tschundeee Points 9241

Cette vidéo officielle de Jetbrains PyCharm par John Lindquist (gourou d'angular.js et de jetbrains) est un bon point de départ car elle montre l'interaction entre le webservice, la base de données et angular.js dans flask.

Il construit un clone d'intérêt avec flask, sqlalchemy, flask-restless et angular.js en moins de 25 minutes.

Profitez-en : http://www.youtube.com/watch?v=2geC50roans

17voto

topless Points 2962

La réponse ci-dessous vise les projets à grande échelle. J'ai passé un certain 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 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 une approche légèrement différente qui (dans mon esprit du moins) s'adapte d'une manière plus humaine.

Lorsque vous mettez en œuvre un exemple de TODO, les choses sont assez simples. Mais lorsque vous commencez à ajouter des fonctionnalités et des petits détails pour améliorer l'expérience utilisateur, il n'est pas difficile de se perdre dans le chaos des styles, du javascript, etc.

Mon application a commencé à prendre de l'ampleur, j'ai donc dû prendre du recul et réfléchir à nouveau. Au départ, une approche comme celle suggérée ci-dessus aurait pu fonctionner, en regroupant tous les styles et tout le JavaScript, mais elle n'est pas modulaire et n'est pas facile à maintenir.

Et si nous organisions le code client par fonction 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 ça, nous pouvons envelopper chacun de nos répertoires dans un module angulaire. Et nous avons divisé nos fichiers d'une manière agréable qui nous évite d'avoir à parcourir du code non pertinent lorsque nous travaillons avec une fonctionnalité spécifique.

Un gestionnaire de tâches comme Grunt correctement configuré, sera capable de trouver, concaténer et compiler vos fichiers sans trop de difficultés.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X