[s5prin]

Bir süredir PHP tarafından resmen desteklenen Smarty şablon motorunu araştırıyorum. Bilmeyenler için genel amacı kısaca web projelerinde tasarımsal / HTML şablonlarını kodsal ve veri sorgulama dosyalarından ayırmaya, farklı template dosyalarını daha sade ve temiz tutmaya yaramakta.

Ancak asıl öğrenmeye çalıştığım nokta bu işin teknik yönünden çok MVC yapılarda gerçekten fayda sağlayıp sağlamadığına ilişkin. Bu noktada hali hazırda MVC sistemlerini kullanan arkadaşlara ve Smarty ile çalışmış arabirim / HTML tasarımcılarına sormak istediğim soru aslında çok net:

Zend, CakePHP gibi frameworkler ile MVC'nin View'ini Smarty kadar fonksiyonel olmasa da kendi View nesneleriyle yönetebiliyorken, HTML içine smarty if-else komutlarını yerleştirmek ile PHP if-else kodlarını yerleştirmenin ne farkı var?

[aynı konu, ceviz forum]

[BYK]

Açıkçası bir çok taslak ve çalışma sistemine yaklaştığım gibi MVC'ye de şüpheyle yaklaştım başta ancak ayrıntılarını ve yapılan her şeyin bir amaca yönelik ve oldukça mantıklı bir şekilde yapıldığını gördükten sonra gerçekten takdir ettim MVC sistemini.

Smarty ile çok bir tecrübem yok ancak bahsettiğiniz durumda HTML içine smarty if-else leri yazmak PHP'de yazmaktan daha kolay ve anlaşılır olabilir belki de. Amaç tasarımcıyla programcıyı farklı dosyalarla çalıştırmayı başarmaksa Smarty'nin bu konuda tasarımcıya yönelik, daha basit ama kullanımı kolay bir sistemle gelmesini beklerim.

Bu açıdan baktığınızda siz nasıl bir değerlendirme yapıyorsunuz?

[mow]

Çok zor ve sürekli tartışılan sorular bunlar kendimce yanıtlayayım;

Neden <?PHP if/else ?> değilde {if/else}?
Hangi "V"yi kullanırsak kullanalım, sunum katmanında mutlaka değişken olmak zorunda olduğunu kabul ediyorsak ve tasarımcıların minimum efor sarfederek bunları algılamasını sağlamak istiyorsak elimizde bulunması gereken şey basit sözdizimi olan bir template sistemidir. Tasarımcılarımızdan PHP yi öğrenmelerini istememiz her ne kadar daha mantıklı gözüksede bunun olamayacağını biliyoruz, böyle bir şey yerine herhangi bir tasarımcının ilk gördüğünde çatpat anlayabileceği, üçüncü gün sonunda hakim olabileceği basit sözdizimlerini öğrenmelerini istememiz çok daha mantıklı.

Neden template Sistemi?
Tasarımcının yaptığı herhangi bir sözdizimi hatasında kendi başına çözemeyeceği bir sorun meydana gelmemesi ve sunumların taşınabilir ve tekrar kullanılabilir olması gerekir. Yazılımcı ve tasarımcıdan başka üçüncü kişilerinde belli şartlar altında sunuma müdahale etmesini gerektiren durumlar da olabilir. Tasarımcıların gözlerini kamaştıracak, onları ağlatabilecek ve sinir katsayılarını yükseltebilecek sözdizimlerinin olmadığı ve üzerinde çalıştığı sayfada kesinlikle HTML nin PHP den çok daha öncelikli olduğunu hissettirebilecek bir şeyler olması gerekir. Ayrıca sunum katmanının illaki bir dosyanın içinde olması gerekmez, bir veritabanında da olabilir başka aklıma gelmeyen bir kaynaktada. Önbellek, filtreler ve benzeri şeyler de çoğu zaman hayat kurtarır.


Neden ve Nerelerde Smarty Kullanıyorum?
Yukarıda yazdığım özelliklerin hepsine ve daha fazlasına sahip olduğu için "smarty"yi tercih ediyorum, bir yüzdeye vurmam gerekirse MVC yapısı ile yaptığım işlerin %50 sinde, yapmadıklarımın tamamına yakınında smarty kullandım.

[uzaytek]

Aslında soruyu anlamadım, mvc yapısının kendi view katmanını çıkartıp bunu smarty ile yaparsak farki ne olur diye mi soruyorsunuz? yoksa smarty kullanmayıp PHP/HTML karısık kodlar yazarsak ne olur mu konu?

1. durumu pek tavsiye etmem, o frameworklerin kendi yapılarını kullanmalısınız, çünkü bu yapıları adamlar birbirine bağlı kuruyor, yani view katmanı ile etkileşime geçecek başka katmanlardan mahrum kalabilirsiniz.
form validasyonları, cache, vs gibi. Evet smarty de bunlara sahip fakat ortaya karışık ve biribiri ile uyumsuz bir sistem çıkacaktır.

2. durum, baştan beri benim çok güldüğüm bir konu, şimdiye kadar çok büyük şirketlerde çalışmadım, çalıştığım şirketler çoğunlukla 1 tasarımcı ile 1/2 kod yazarı olan ekiplerdi. Yaptığım siteler ise dinamik olarak birden fazla tasarım kullanmayacak veya çok sık tasarım değiştirmeyecek klasik veritabanı programları idi. Neyse lafı uzatıyorum, getireceğim nokta şu. Tasarımı ben kesicem, kodlari ben yerleştireceğim zaten tasarımcı grafik dosyasini bana verdikten sonra bir daha arkasına bakmayacak, bu tip projelerde ne diye smarty template kullanıcam ki

Aslında zaman içinde tecrübe ile herkes kendi template yapısını kuruyor zaten. Bu durumda smarty nerelerde kullanılmalı sorusu daha onemli oluyor.

- Tasarımcılar basit düzeyde koda bulaşacak kadar bolsa, kaldı ki smarty kodlaması hiç te öyle basit değil. Sürükle bırak yapar tasarımcılar, onun kod kısımları üzerinde. Editi aklınıza bile getirmeyin. Yani koder ile tasarımcı arasında, kodlamaya yakın 1 adam varsa diyelim.
- Tasarımlar sitede dinamik olarak değişiyor ise
- Sitenin 1 den fazla alt sayfa tasarımı var veya kullanıcılar tasarımları kendileri özelleştirebiliyorlar gibi karmaşık kod kısımları varsa.
- site zırt/pırt tasarım değiştirecek ise.
- Farklı ortamlara(mobil, farklı tarayıcılar) aynı kod üzerinden yayın yapalım derseniz.
- Proje uzun sürecek, çok kod yazılacak ise

Aksi hallerde bırakın smarty, mvc'yi, kendi yapınızı kurun daha çabuk ve güzel sonuç alırsınız.

Son projemde pear+smarty kullandım, bazı şeyleri smarty ile otomatiğe bağlayabildim. listelemeler, form validasyonlari gibi. web kullanıcısı ve yönetimdeki kullanıcılar aynı HTML formları, farklı prosesslerden, validasyonlardan geçerek kullanıyorlar. Ayrıntılar...

Uzun lafın kısası, view katmanını ayırmak güzeldir ama buna değecek ise.

[s5prin]

Geç kalmış teşekkür ve yorumum için özür dilerim ancak biraz olsun smarty'yi MVC yapılarla birlikte tecrübe etmek istedim.

@uzaytek
1. Smarty frameworklerde, en azından Zend Framework'ün view katmanıyla birleştirilerek (neredeyse sorunsuzca) her iki objenin metodları da tek objede kullanılabiliyor.
2. Gayet tabi bu sizin çalışma tarzınız. İki günde bitmesi gereken ve belki bir daha açılmayacak mini projede ben de stratejik yapılarla uğraşmazdım.

@mow nokta atışı yapan yorumun için teşekkürler.

Şu ana kadar tecrübe ettiğim kadarıyla Smarty kullanılmasının sadece ve sadece 2 nedeni var:

1. Sizin de belirttiğiniz gibi bir arabirim tasarımcısının kod kısmına bulaşmasını kimse istemez. Bu hem basit kontrolleri yapmaması ve onun rahatı açısından hem de daha temiz bir view katmanı için kullanışlı.
Örnek;

“if (isset($array)) and is_array($array)) { foreach ($array as $key => $value) { …} } else { …}”

yerine

{foreach from=$array item=item key=key}…{foreachelse}…{/foreach}

daha anlaşılır ve temiz gibi.

2. Eğer view katmanı müşterilere ve / veya kurum dışı arabirim geliştiricilere açılacaksa (örnek ücretsiz blog servisinin tema düzenlemesi gibi) hem güvenlik açısından hem de tecrübesiz tasarımcıların PHP kodlarını alt üst edip gelen verileri dağıtmaması açısından gerekli.

Ancak benim çıkardığım sonuç 1. madde, yani PHP kodundan uzak durma kısmı pratikte pek de gerçekleşmiyor. Temiz HTML/CSS şablonunu üretim ortamına eklemek her zaman programcıların üzerine kalıyor. Bunun en büyük nedeni deadline'ların konuştuğu proje takip paketlerinin kullanıldığı çalışma ortamında HTML/CSS tasarımcısının PHP kodlamayı az çok bilse de gelen değişkenin adını bilmemesi, array boyutlarını tanımaması gibi zamansızlıktan kaynaklanıyor.

Ancak 2. madde kabul edilebilir düzeyde. İlgilenenlerin şu yazılara ve yorumlara göz atmasını tavsiye ediyorum;
http://gigaom.com/2007/11/26/wordpre...rity-problems/
http://hasin.wordpress.com/2008/01/0...re-was-smarty/