Tipik AngularJS iş akışı ve proje yapısı (Python Flask ile)


226

Ben tüm bu MV * istemci tarafı çerçeve çılgınlığı için oldukça yeniyim. AngularJS olmak zorunda değil, ama onu seçtim çünkü Nakavt, Ember veya Omurgadan daha doğal geliyor. Neyse iş akışı nasıldır? İnsanlar AngularJS'de bir istemci tarafı uygulaması geliştirmek ve ardından bunun arka ucunu bağlamakla mı başlıyor?

Ya da önce Django, Flask, Rails'te arka ucu inşa edip bir AngularJS uygulaması ekleyerek? Bunu yapmanın "doğru" bir yolu var mı, yoksa yalnızca kişisel bir tercih mi?

Projemi Flask veya AngularJS'ye göre yapılandırıp yapılandırmayacağından da emin değilim? topluluk uygulamaları.

Örneğin, Flask'ın minitwit uygulaması şu şekilde yapılandırılmıştır:

minitwit
|-- minitwit.py
|-- static
   |-- css, js, images, etc...
`-- templates
   |-- html files and base layout

AngularJS öğretici uygulaması şu şekilde yapılandırılmıştır:

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

Bir Flask uygulamasını tek başına resmedebilirim ve ToDo List gibi AngularJS uygulamasını tek başına görmek oldukça kolaydır, ancak bu teknolojilerin her ikisini de kullanmaya gelince birlikte nasıl çalıştıklarını anlamıyorum. AngularJS'ye sahip olduğunuzda neredeyse bir sunucu tarafı web çerçevesine ihtiyacım yok gibi görünüyor, basit bir Python web sunucusu yeterli olacaktır. Örneğin AngularJS yapılacak uygulama uygulamasında, Restful API kullanarak veritabanıyla konuşmak için MongoLab kullanıyorlar. Arka uçta bir web çerçevesine gerek yoktu.

Belki de sadece kafam karıştı ve AngularJS, süslü bir jQuery kütüphanesinden başka bir şey değil, bu yüzden Flask projelerimde jQuery kullanacağım gibi kullanmalıyım (Jingular2 ile çakışmayan bir şeye AngularJS şablon sözdizimini değiştirdiğimi varsayarak). Umarım sorularım bir anlam ifade eder. Esas olarak arka uç üzerinde çalışıyorum ve bu müşteri tarafı çerçevesi benim için bilinmeyen bir bölge.

Yanıtlar:


171

Flask uygulamasını aşağıdaki gibi standart yapıda düzenleyerek başlıyorum:

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

Ve btford'un belirttiği gibi, bir Açısal uygulama yapıyorsanız, Açısal istemci tarafı şablonlarını kullanmaya odaklanmak ve sunucu tarafı şablonlarından uzak durmak istersiniz. Render_template ('index.html') kullanılması, Flask'ın açısal şablonlarınızı jinja şablonları olarak yorumlamasına neden olur, böylece doğru şekilde oluşturulmazlar. Bunun yerine, aşağıdakileri yapmak istersiniz:

@app.route("/")
def index():
    return send_file('templates/index.html')

Send_file () kullanmanın dosyaların önbelleğe alınacağı anlamına geldiğini, bu nedenle en azından geliştirme için make_response () yöntemini kullanmak isteyebilirsiniz:

    return make_response(open('templates/index.html').read())

Daha sonra, uygulamanızın AngularJS bölümünü oluşturun, uygulama yapısını şöyle görünecek şekilde değiştirin:

app
|-- app.py
|-- static
    |-- css
    |-- img
    |-- js
        |-- app.js, controllers.js, etc.
    |-- lib
        |-- angular
            |-- angular.js, etc.
    |-- partials
|-- templates
    |-- index.html

İndex.html dosyasında AngularJS ve diğer dosyaların bulunduğundan emin olun:

<script src="static/lib/angular/angular.js"></script>

Bu noktada, RESTful API'nizi henüz oluşturmadınız, bu nedenle js denetleyicilerinizin önceden tanımlanmış örnek verileri (yalnızca geçici bir kurulum) döndürmesini sağlayabilirsiniz. Hazır olduğunuzda, RESTful API'sini uygulayın ve açısal uygulamanıza angular-resource.js ile bağlayın.

EDIT: Yukarıda tarif ettiğimden biraz daha karmaşık olsa da, AngularJS ve basit bir Flask API arasındaki iletişim ile birlikte AngularJS + Flask ile bir uygulamanın nasıl oluşturulacağını gösteren bir uygulama şablonu bir araya getirdim. İşte kontrol etmek istiyorsanız: https://github.com/rxl/angular-flask


1
Bu sorunla karşılaştım: index.html statik olarak sunmaya çalıştığımda dosyanın içeriği korunmadı. Statik dosyamı ekleyerek bu sorunu çözdüm app.root_path. Aksi takdirde, bu oldukça yerinde.
Makoto

"Send_file () kullanmanın dosyaların önbelleğe alınacağı anlamına geldiğini, bunun yerine en azından geliştirme için make_response () yöntemini kullanmak isteyebilirsiniz" hakkında daha fazla bilgi verebilir misiniz? Teşekkürler
nam

Bu yaklaşımla homurdanma gibi yapıları nasıl yönetiyorsunuz?
Saad Farooq

1
@nam, bunun ne anlama geldiğini düşünüyorum, hata ayıklama sırasında js vb küçük değişiklikler yapıyorsanız, send_file bir zaman aşımı = SEND_FILE_MAX_AGE_DEFAULT ile sunulan dosyaları önbelleğe çünkü tarayıcıda etkisi görmezsiniz olduğunu düşünüyorum. bunu geçersiz kılmanın yolları vardır, ancak dağıtım için hazır olana kadar make_response kullanmak çok daha kolaydır.
ars-longa-vita-brevis

@SaadFarooq Burada biraz homurdanmıyorum çünkü işleri biraz zorlaştırıyor. Grunt gibi bir şey kullanmaya hazırsanız, ön uç kodu için ayrı bir repo sahip olmak mantıklıdır, ardından her şeyi bir araya toplayın, Flask deposuna kopyalayıp yapıştırın veya bir CDN'ye itin ve referans verin index.html'den.
Ryan

38

Her iki uçtan da başlayabilirsiniz.

Muhtemelen AngularJS ile tam bir sunucu tarafı çerçevesine ihtiyaç duymuyorsunuz. Statik HTML / CSS / JavaScript dosyaları sunmak ve istemcinin tüketmesi için arka uç için RESTful API sağlamak genellikle daha iyidir. Muhtemelen kaçınmanız gereken bir şey, sunucu tarafı şablonlarını AngularJS istemci tarafı şablonlarıyla karıştırmaktır.

Eğer dosyalarınızı sunmak için Flask kullanmak istiyorsanız (aşırı olabilir, ancak yine de kullanabilirsiniz) "app" içeriğini "angular-phonecat" den "minitwit" in "statik" klasörüne kopyalarsınız.

AngularJS, AJAX benzeri uygulamaları daha fazla hedeflerken, flask size hem eski stil web uygulamalarını yapma hem de RESTful API'ler oluşturma olanağı sağlar. Her yaklaşımın avantajları ve dezavantajları vardır, bu yüzden gerçekten ne yapmak istediğinize bağlıdır. Bana bazı bilgiler verirseniz, başka önerilerde bulunabilirim.


26
+1 - ancak Flask'ın eski stil web uygulamalarını hedeflediğini söyleyemem - bir web API arka ucu olarak da kullanmanız gereken tüm yardımcıları sağlar ;-) Ayrıca isterseniz Flask-Restless var Flask-SQLAlchemy'yi kullanarak web uygulamanız için bir JSON sunma API'si oluşturabiliyor - sadece FYI :-)
Sean Vieira

İyi bir nokta! Flask'a özellikle aşina değilim; konuyla ilgili uzmanlık sağladığınız için teşekkür ederiz.
btford

3
ayrıca açısal ve sağladığımız tüm araçlarla
Igor Minar

2
Bana göre, "app" klasörünü "angular-phonecat" den statik klasöre koymak adil görünüyor. Ancak index.html dosyasının minitwit templates klasörüne konması gerektiğini düşünüyorum. Css ve img klasörleri "statik" e taşınmalıdır.
Nezo

22

John Lindquist'in bu resmi Jetbrains PyCharm videosu (angular.js ve jetbrains guru), flask içindeki webservice, database ve angular.js'nin etkileşimini gösterdiği için güzel bir başlangıç ​​noktasıdır.

25 dakikadan daha kısa bir sürede balon, sqlalchemy, balon-huzursuz ve angular.js ile ilgi çekici bir klon oluşturur .

Keyfini çıkarın: http://www.youtube.com/watch?v=2geC50roans


17

edit : Yeni Angular2 stil kılavuzu , benzer bir yapıda olmasa da, çok daha detaylı bir şekilde önerir.

Aşağıdaki cevap büyük ölçekli projeleri hedeflemektedir. Angular gibi bir istemci tarafı çerçevesi ile birlikte arka uç işlevselliği için bazı sunucu tarafı çerçevesini (benim durumumda App Engine ile Flask) birleştirebilmem için birkaç yaklaşımla düşünme ve deneme yapıyorum. Her iki cevap da çok iyi, ama (en azından aklımda) daha insani bir şekilde ölçeklenen biraz farklı bir yaklaşım önermek istiyorum.

Bir TODO örneği uygularken, işler oldukça basittir. Yine de, kullanıcı deneyimini iyileştirmek için işlevsellik ve küçük güzel ayrıntılar eklemeye başladığınızda, stillerin, javascript vb.

Uygulamam oldukça büyümeye başladı, bu yüzden geri adım atmak ve yeniden düşünmek zorunda kaldım. Başlangıçta, yukarıda önerildiği gibi bir yaklaşım, tüm stilleri ve tüm JavaScript'i bir araya getirerek işe yarayacaktır, ancak modüler değildir ve kolayca bakımı mümkün değildir.

İstemci kodunu dosya türü başına değil, özellik başına düzenlediysek:

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
        |-- ...

ve bunun gibi.

Bunu böyle yaparsak, her dizinimizi bir açısal modül içine sarabiliriz. Belirli bir özellik ile çalışırken, alakasız kodlardan geçmemiz gerekmediği için dosyalarımızı güzel bir şekilde böldük.

Grunt gibi bir görev koşucusu düzgün yapılandırılmış, dosyalarınızı çok zorlanmadan bulabilir ve birleştirebilir ve derleyebilir.


1

Başka bir seçenek de ikisini tamamen ayırmaktır.

proje
| - sunucu
| - istemci

Şişeyle ilgili dosyalar sunucu klasörünün altına, angularjs ile ilgili dosyalar ise istemci klasörünün altına gider. Bu şekilde, arka ucu veya ön ucu değiştirmek daha kolay olacaktır. Örneğin, gelecekte Flask'tan Django veya AngularJS'ye ReactJS'ye geçmek isteyebilirsiniz.


Kevin: Bağlantıyı facebook oturum açma sayfasına yönlendirmek için incelemek isteyebilirsiniz.
RussellB

0

Veri işleminizin çoğunu hangi tarafta yapmak istediğinizi belirlemenin önemli olduğunu düşünüyorum - ön uç veya arka uç.
Ön uçsa, açısal iş akışı ile devam edin, bu da şişe uygulamanızın şişe dinlendirici gibi bir uzantının sona ereceği bir api olarak işlev göreceği anlamına gelir.

Ama benim gibi, arka tarafta en çok iş yapıyorsunuz, daha sonra şişe yapısı ile devam edin ve ön ucu oluşturmak için (gerektiğinde) sadece açısal (veya benim durumumda vue.js) takın

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.