Play Framework Architecture

Merhaba arakadaslar, bu yazımızda Play’in mimarisina değinmeye çalışacağız.

Play Framework Architecture

Öncelikle Play’in mimarisine bakıldığında temel bir HTTP isteğinin ilk başlangıç noktası Play’ın routes’indan geçer.

conf dizini altındaki tanımlı routes’lardan birine gelen herhangi bir request action denen ve aslında bir methoddan ibaret olan kısma yönlendirilir.

Burada MVC’deki Controller devreye girecektir. Play Controller’da bir java sınıfından farksız degillerdir, birazdan detaylandıracagız. Request action’a yönlendirildikten sonra model ile etkilesime gecerek view render edilir ve response dönülür.

Aşağıdaki şema’ya dikkat ediniz;

Screenshot from 2016-03-12 11:08:38

Request/Response aşamaları aşağıdaki gibidir;

  1. Client istekte bulunur.
  2. Play Router isteği handle eder ve nereye yönlendirecegine karar verir.
  3. Controller içerisindeki action, isteği alır ve işler.
  4. View’ı günceller yada render eder ve http response dönülür.

 

Routes

Play dizin yapısı Rails ile hemen hemen aynıdır. Routes, gelen isteklerin nereye yönlendirilecegini ve bir takım url tanımı yapılmasını sağlayan, conf dizini altında olan bir dosyadır. Routes configürasyonu içerisinde ki bir satır 3 kısımdan oluşur;

  1. HTTP method type
  2. URL
  3. Action

Örnek bir konfigürasyonuna bakalım;

Application Context name’den sonra gelen url (localhost:9000/MyApps/ gibi) HomeController’da ki index actionuna yönlendirilir.

index action’un bir methoddan farksız olmadıgını belirtelim. Örnek olması açısından index action’a bakalım;

index action gelen isteğe ok objesi ile HTTP 200 dönmektedir.

Not : index.render kısmı index.scala.html template’ine işaret eder, bir önceki yazıda kısmen deginmistim, detaylı olarak da bakacağız.

Screenshot from 2016-03-12 11:27:18

Routingi şöyle yapalım ve index() methodumuza ellemeyelim;

Bu durumda compile error alıyor olacaksınız.

Screenshot from 2016-03-12 11:33:33

Routes’a daha sonra detaylı olarak deginecegim.

Controller

MVConttoller olarak görev alır. Gelen HTTP isteğini action’lara iletir, action’ları içerisinde barındırır. Bir Java class’ından farksız degildir. Bir class’ın Controller görevi görebilmesi için play.mvc.Controller sınıfını extends etmesi gerekmektedir. HomeController sınıfına bakalım;

Sonraki yazılarda Controller’ın yapısına detaylı olarak bakacagız. Burada belki index.render’a değinilebilir.

import views.html ifadesindeki gercek tanım şudur : import views.html.index;

Bu kısım views altındaki index.scala.html template’ine işaret eder. Views altındaki main template için import ifadesi ise import views.html.main; şeklinde olacaktır.

index() methodu static olarak da tanımlanabilir. Burada thread safe olmadıgını düsünebilirsiniz ancak play bytecode seviyesinde thead safe olarak çağıracaktır, bu yüzden thread safe gibi bir endişenizin olmasına gerek yoktur.

Not : Yönlendirmeleri annotation ile de yapabilirsiniz, belki onlara da deginiriz ilerde.

Configuration

Play uygulamanızda configürasyon dosyası conf dizini altında default olarak application.conf olarak yer alır. Bu dosya adından da anlasılacagı gibi bazı configuration bilgilerini içerir. application.conf dosyası HOCON(Human-Optimized Config Object Notation) formatında name=value tipinde bir dosyadan ibarettir.

Dosya içerisinde http ayarları, netty ayarları, database bilgileri gibi veriler yer almaktadır. Yeri geldikce değinecegiz.

Model

ModelVC kısmını oluşturur. app/models dizini altında modeller yer almak zorundadır. Default implementasyon JPA ile yapılmıştır. Bunun için play.db.jpa.Model class’ından ihneritance edilmesi gerekir. Örnek bir user’a bakalım;

@Entity ile jpa entity tanımı yapılır. Class member’larda bazı tanımlamlar, kısıtlamalar yapılabilir. Play MVC yazısında bunlara detaylıca değineceğiz insaAllah.

Views

MViewC kısmını oluşturur. Play kendi içerisinde default olarak twirl template engine içermektedir, ek bir dependency tanımına gerek yoktur. Play dışında da kullanabilirsiniz bunun için sbt dosyanızda birkaç degisiklik yapmalısınız.

Views’da @ magic karekter bulunur. Template’in aldıgı parametreler, tanımlamalar vs gibi işlemler @ üzerinden yapılır. Örneğin main template’imize bakalım;

views.main.scala.html

@(title: String) ile template’in parametre aldıgını content ile beraber görebiliyoruz. Parametre hiç de almayabilir. Bir template içerisinde diğer bir template çağrılabilir, import ifadelerini içerebilir vs.

Play MVC yazısında detaylandıracağız.

Logging

Play default olarak logback kullanarak loglamaları yapar. Uygulama dizini altındaki logs dizinine default olarak application.log olarak logları yazar. Xml configurasyon dosyası conf dizini altındaki logback.xml dosyasında alır. Default konfigürasyon asagıdaki gibidir;

  • Default olarak iki appender ile console’a ve file’a log yazılmaktadır.

Public

Bu dizin direk olarak erişilebilen, image, css vb gibi dosyaları tutabilecegimiz public alandır. routes konfigürasyonunda şu mapping ile tüm public dizini içerisindeki dosyalara erişebiliriz;

Örneğin;

Screenshot from 2016-03-12 12:22:01

/assets gibi bir url vermek anlasılabilirligi artıracaktır.

Test

Projedeki herhangi bir modülü, methodu vs test etmek için uygulama dizininde test classları yazabilirsiniz. Test etmek icin play konsoldan activatoru test modunda açmak gerekiyor;

Screenshot from 2016-03-12 12:37:03

JUnit testlerinden basarıyla gectik

Yazımızın sonuna geldik arkadaslar, bir sonraki yazıda görüsmek dilegiyle, sağlıcakla kalın.

~ A.Akkus

684 Total Views 2 Views Today