Django Öğrenmek-2: Temel yapı taşları, URL, Template, Django App
Bu seride, Django öğrenirken kendi yaşadığım zorlukları ve internette okuduklarımı referans alarak Django öğrenmeye yeni başlayanlara destek olmaya çalışacağım.
Bu yazıda Django’nun temel yapı taşlarından bahsedip, onları nasıl kullandığımızı örneklerle açıklayacağım.
Seriye ait tüm yazılara ulaşmak için:
Django Öğrenmek-1: Django öğrenmek neden zor?
Django Öğrenmek-2: Temel yapı taşları, URL, Template, Django App
Django Öğrenmek-3: Django Kurulumu, izole geliştirme ortamı “virtualenv”, Örnek Proje “Hello World”
Django Öğrenmek-4: Farklı Çalışma Ortamları İçin Farklı “settings.py” Kullanmak
Django, Batteries Included -Piller Dahil- olarak tanımlanan bir framework. Bu, web geliştirmede yaygın olarak kullanılan birçok konseptin hazır kodlanmış olarak gelmesi demek. Örnek olarak kullanıcı giriş ve kullanıcı/grup bazlı yetkinliklerin ayarlanması ihtiyacını ya da oturum yönetimi ile ilgili ihtiyaçların hali hazırda kendiliğinden gideriliyor olmasını düşünebilirsiniz. Burada ilk aşamada bize düşen, zaten kodlanmış olan ihtiyaçları yönetmek ve nasıl kullanacağımızı öğrenmek. Bu doğrultuda “Django Öğrenmek” serisinde farklı projeler yapacağız, projelerle birlikte “Battery”’leri ve çevresinde dönen olayları öğreneceğiz.
Bu yazının hedefi, Django’nun temel yapı taşları hakkında fikir sahibi olup aralarındaki bağlantıyı görmek.
Temel yapı taşları
Django Model View Controller (https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) mimarisine uygun çalışacak şekilde tasarlanmıştır. Yani veri ile ilgilenen yapı, verinin kullanıcı ile etkileşimi ile ilgilenen yapı ve bu ikisinin arasındaki bağlantıyı kuran yapı arasındaki ilişki mümkün derecede birbirinden bağımsızdır ve MVC benzeri modern mimarileri rahatlıkla kurgulayabilirsiniz.
Django basitçe 3 temel yapının etkileşimi ile çalışır:
-Django Application
-Template
-URL
Bu 3 temel yapının ne işe yaradığını ve Django’daki basit bir iş akışını nasıl oluşturduklarını ‘G-1’de görselinde görebilirsiniz. Kısaca özetleyecek olursak:
1- Kullanıcı bir HTTP isteği yapıyor. Bu istek browser’a url yazarak atılmış bir GET ya da herhangi bir diğer HTTP method’u olabilir.
2- Bu istek, isteğin geldiği URL’in Django’da istenildiği şekilde Django App’imize yönlendirilerek manipule edilebileceği/kullanılabileceği gibi direkt static bir kaynağa da yönlendirilebilir. Bunun sonucunda bir HTTP yanıtı ile isteği yapan kullanıcıya cevap dönülmüş olur.
3- İş mantığımız sürekli sabit bir değer döndürmemizi değil de gerekli bazı işlemler yapmamızı istiyorsa Django App katmanı sayesinde kullanıcıdan girdi almak, bu girdiyi işlemek, veritabanı işlemleri yapmak gibi işleri yerine getirebiliriz.
4- Kullanıcının isteği, sabit bir kaynak yardımıyla -static files- verilebilecek bir yanıtı işaret ediyorsa, örneğin şirketin logosunu almak için bir HTTP isteği yapılıyorsa Django Application katmanına hiç başvurmadan bu işi gerçekleştirebiliriz.
Bu dört adım sayesinde çok basit bir Django Projesinin nasıl bir akış izlediğini kafamızda canlandırabiliriz. Biraz daha derine giderek bu temel yapı taşlarını örneklerle açıklayalım ve Django iş akışının neye benzediğini daha iyi anlamaya çalışalım.
Django Application
Günlük hayatta kullandığımız Application kavramından farklı olarak, Django Application’ları “Tak-Çalıştır” şeklinde kullanabileceğimiz modüler bir yapı oluşturmamızı sağlayan, aynı zamanda farklı görevleri olan parçaları gruplamamıza olanak sağlayan bir olgudur. Bu Tak-Çalıştır durumu sayesinde genel ihtiyaçlar için başka yazılımcıların hazırladığı Django App’leri kullanabilirsiniz. Bunun yanında fonksiyonel açıdan bakacak olursak; projenizde kullanıcıdan girdi almak, bu girdiyi işlemek, veritabanı işlemleri yapmak gibi işler için Django Application’ları yaratmanız ve kullanmanız gerekiyor.
Bir Django App oluşturmak için, ilk kurulumu yapılmış bir Django Projesi’nde bulunan manage.py scriptini “startapp” komutu ve istediğimiz application adı ile birlikte kullanıyoruz:
#python manage.py startapp <app name>
Bu komutun ardından, aşağıdaki görselde bulabileceğiniz, örnek bir Django App olan “contacts” api için kendiliğinden oluşan contacts klasörünün altında duran “migrations” klasörü hariç tüm python dosyaları kendiliğinden oluşuyor ve içlerini doldurmamızı bekliyor.
Kendi projelerimden birinden aldığım ‘Örnek-1’ görselinin sağ tarafında:
-Kırmızı karenin içinde kalan kısım, Django projenizi oluşturduğunuzda varsayılan olarak hazır gelmiş Django App’leri gösteriyor. Bu app’leri kaldırmamanız Django’nun çekirdek ögelerinin doğru çalışması için tavsiye edilse de profesyonel kullanıcılar ne yaptığını bildiği sürece varsayılan app’leri kaldırabilir.
-En üstte mavi karenin içinde kalan app’ler ise 3rd party bir framework olan Django REST Framework’ün kullanıcı yönetimi ve REST API işlemleri için kullandığım app’leri gösteriyor.
-En altta kalan yeşil kare ise kendi oluşturduğum “events”, “contacts” ve “users” app’lerini gösteriyor. User application’ı içerisinde kullanıcı profilimi tuttuğum, güncellediğim ve sildiği API’ları yönetiyorum. Contacts ve Events app’lerinde de kullanıcının bağlantılarını ve olayları/bildirimleri yönetiyorum.
Template
Genelde, iyi bir web framework’ünün HTML dosyaları üretme ve manipüle etme yeteneği vardır. Ayrıca bu işleri yaparken, kopyala-yapıştır içerikleri/kod tekrarlarını ortadan kaldırması veya olabildiğince azaltmaya yardımcı olması gerekir.
Django’nun kendine ait özel bir template dili vardır: Django Template Language (DTL). Buna ek olarak Django 1.8'den sonra kullanılabilir hale gelmiş “Jinja2” ile daha yüksek performans gerektiren (ve şu an üzerinde durmayacağımız artıları ve eksileri olan) işler yapmamız mümkün.
Template’leri kullanmaya başlamadan önce “Örnek-2”de kırmızı karede görüldüğü gibi klasör konumunu Django’ya belirtmemiz gerekiyor. Kırmızı kare içerisinde yapılan işlemin sonucu basitçe “/proje_klasörü_tam_konumu/templates” şeklinde solda görebileceğiniz “templates” klasörünün yerini belirtmek. “TEMPLATES_DIR” ise settings.py dosyası içindeki kodun daha üst kısımlarında TEMPLATES_DIR = “templates" olarak tanımlanmış bir değişkenden ibaret.
Gördüğünüz üzere templates klasörü 2 adet html uzantılı dosya içeriyor. Bu projede yapmaya çalıştığım şey, daha önceden veritabanına yazdığım blog gönderilerini çekip alt alta sıralayacak bir kod yazmaktı. Bu bağlamda html dosyalarını inceleyelim:
Bu html kod parçasında dikkat edeceğimiz kesit:
{% for post in posts %}
<hr>
<h2> {{ post.title }} </h2>
<p> {{ post.description }} </p>
{% endfor %}Bu html dosyası Posts isimli Django Application’ı tarafından kullanılıyor. Django’nun URL yapısı aracılığıyla HTTP GET ile başlayan kullanıcı isteği, Posts Application’ının list_posts() methodu ile bağlanıyor.
def list_posts(request):
posts = Post.objects.all()
return render(request, "posts.html", {'posts': posts})Ardından bu istek, application’ımızın list_posts methodu tarafından manipüle ediliyor. Yapılan işlem, veritabanındaki tüm post’ların alınması ve “posts.html” template’i ile işleme sokularak kullanıcıya döndürülmesi. Ardından posts.html içerisinde bulunan ve yukarıda ayırdığımız özel “for” yapısına giren dict türündeki posts verimiz işleniyor ve kullanıcımız bu işlem sonucunda yaratılan yeni html sayfasını aşağıdaki gibi görüyor:
URL
Django iş akışı diyagramında konuştuğumuz üzere, bir kullanıcının Django ile etkileşiminin ilk noktası URL. Kullanıcı, belirlenen HTTP method’u ile Django’da ayarlanmış olan uygun bir URL kullanarak istek yapar.
Aşağıdaki örnek ItsMeBlog adlı Django Projesi’nin klasör yapısını ve proje seviyesinde oluşturulan urls.py dosyasının içeriğini gösteriyor. Yukarıda, Template başlığı altında, gönderileri listelemek için kullandığımız url’in <host>/blog/posts/ şeklinde yapılandırıldığına dikkat çekmek istiyorum. Bunu takip edersek proje seviyesi urls.py dosyasında “/blog” konumunun, blog Django App’inin altında yer alan app seviyesi urls.py dosyasını işaret ettiğini görebiliriz.
Blog Django App’inin altında yer alan urls.py dosyasında da “/blog/” konumunun ardından gidilecek konumlarla ilgili bilgiler yer alıyor. Örneğin “/blog/posts/” konumu kullanıcıya “views.list_posts” method’unu döndürüyor.
Takibimize, blog Django App’inin altında bulunan views.py dosyasından devam ediyoruz. Orada “list_posts()” adlı method’a baktığımızda veritabanındaki tüm post’ların alınıp “posts.html” template’i ile işleme sokularak kullanıcıya döndürüldüğünü görüyoruz.
Bu işlemleri yukarıdan aşağıya takip ettiğinizde, yazının en başında çizilen diyagramı elde ediyoruz:
1- Kullanıcı HTTP Request atar
2- URL, eşleştiği yere gider. Bu yer bir Django App ya da static veri döndüren bir template olabilir.
3- URL aracılığıyla gidilen yer yer Django App ise bir dizi işlem sonucu HTTP Response sağlanır. Bir template ya da sabit bir veri ise yine HTTP Response olarak kullanıcıya ilgili veri döner.
Serinin sonraki bölümünde, öğrendiklerimizi kullanarak bir “Hello World” projesi ile kodlama tarafına giriş yapacağız.
Serinin, yorumlarınızdan yardım alarak gelişeceğini belirtmek istiyorum. Bu bağlamda yukarıda bahsedilen sorunları yaşadığınızı düşünüyorsanız ya da bu sorunlar dışında yaygın olarak karşılaşılan farklı sorunlar olduğunu görüyorsanız lütfen yorum bırakarak bana ve diğer kullanıcılara tavsiye ve görüşlerinizi sunmaktan çekinmeyin.
Takip etmeyi, beğenerek ve paylaşarak destek olmayı unutmayın! :)
