From: Enver ALTIN (enver.altin@frontsite.com.tr)
Date: Wed 11 Feb 2004 - 04:52:55 EST
Merhaba,
On Wed, 2004-02-11 at 01:20, R. Tolga KORKUNCKAYA wrote:
> http://skyblue.gen.tr/lotr-rework/?p=ef adresinde sol kolona adresleri
> koymussun sag tarafa aciklamayi. aciklama zaman icerisinde uzayip gitmez
> ama sola koymus oldugun liste uzayip gider...
> http://skyblue.gen.tr/lotr-rework/?p=df adresinde de ayni sorun mevcut.
Şehirlere göre kategorize etmek belki faydalı olabilir.
> Kitaplik bolumunun tasarimi da hic ic acici degil, o sayfada bir tablo
> yerine kitaplarin sol tarafta listesi, veya sadece o sayfada goruncek
> bir sag blok modulu, kitaplarin tanitildigi birer sayfa bu sayfada birer
> kiap kapak resmi, kitaplarin kisa birer tanitimi vs olmasi daha iyi
> olur.
Bu konuda elimde içerik yok gibi birşey, bulabildiklerimle yetinip
kötünün iyisini yapmaktansa, düz bir liste koymayı tercih ettim. Belki
bunları da veritabanına gönderebiliriz ve kategorize edebiliriz.
> O R N E G I N;
Öneri için teşekkürler, umarım fazla gecikmemişizdir, derhal birşeyler
döktüreyim:
> - Mumkun olan her alanda PEAR kullanilacak,
Bu konuda daha önce bir karar almıştık sanırım, ama net sonucu
anımsayamadım. Liste arşivlerinde olacak. Barış?
> - Haberler, seminerler vb. dinamik ve sik guncellenen ve cross-site
> kullanilacak bolumlerde XML veya RSS bir end hazirlanacak,
Bu gibi diğer LKD siteleri ile ilgili çalışmaları da etkileyebilecek
konularda yalnızca bir öneri sunmak ve bu listede ayrı bir thread
oluşturmakla yetiniyorum.
Örneğin seminer sayfasını tasarlayan ekibe bir onca yükün arasında bir
de "XML feed lazım" demeye yüzüm yok bireysel olarak :) Devrim bir öneri
getirmişti (hızlı çözüm), her iki sitenin de aynı sunucuda yeraldığını
belirtti; buna ulaşıp veriyi almak şeklinde. Benim için sorun yok, genel
eğilime uyarım.
> - kodlamada kullanilacak degiskenler adlari soyle verilecek,
> - tasarim grubu su temeller uzerinde calisacak, onlara yardimci olmak
> amaci ile php dosyalarindan gonderilmis olan degiskenler su sekilde
> isimlendirilecek
http://www.gnu.org/prep/standards_toc.html
http://developer.gnome.org/doc/guides/programming-guidelines/book1.html
Bu ve benzeri konularda yazılmış onlarca belge var, bir yenisini de ben
yazmak istemiyorum. Bunlara uyalım yeterli bence.
Ayrıca bu değişken adları vs. konusunda belirlenen kurallar projelerin
çoğunda geri teper. Tasarımcı != programcı, düşünce tarzında bile.
XML/HTML/CSS tasarımcı işi değildir, bunların hepsi kodlanası
bölümlerdir ve ciddiye alınmalıdır ve bu konuda da bir coding-style
belirlenmeli.
CSS için genellikle tag bağımsız property definition (.asd{asdf:efgh}
biçimi) kullanmayalım, bunlarla dolunca hangisinin nerede kullanıldığını
anlamak güçleşiyor. Bunun yerine <tag class=asd> ve tag.asd{asdf: asdf}
kullanımı daha okunaklı.
HTML kodu okunaklı olmalı, buna ihtiyacımız olacak:
<tag1 def1=123>
<tag2>
<tag3>Content</tag3>
<tag3>Content</tag3>
</tag2>
</tag>
gibi. CSS uyumlu olmayan browser kalmadı artık lynx dışında, HTML
4.01'da deprecated olarak belirtilen ve görsel davranış değişikliğine
neden olan tag property'lerin (<b>, <u>, <i> ve <br> dışında, bunlar
hayli pratik ve geçerli) kullanılmamasına özen gösterelim, bu işi CSS'e
bırakalım. Örnek _yanlış_ kullanımlar:
<table align=right width=100%>
<td background=#cde>
<font name="..." size=...>
CSS coding style önerisi için de:
tag.class { property1: value1; property2: value2 }
tag2.class { property3: value3; property4: value4 }
sanırım uygun. CSS içerisinde aynı tag için olan class tanımlarını HTML
içerisindeki kullanım sıralarına ve kendi aralarında alfabetik olarak
dizelim (bunu içgüdüsel olarak yapıyorum).
PHP coding style konusunda:
<?php
/*
* This function does some blah blah stuff and returns a
* TSOMEVAL type for use with someotherfunc()
*
* $param1: blah
* $param2: blah
* $param3: blah
* $param4: optional parameter.
* $param5: optional parameter.
*/
function somefunc($param1, $param2, $param3="defaultvalue", $param4="defval2") {
$someval=somecode($param1);
$someval=someothercode($someval);
// Send it back.
return $someval;
}
// ------------------
switch ($something) {
case "a":
asdf();
break;
default:
dfhg();
break;
}
// ------------------
if ($sdfg && $ghfgh==$uret) {
bvbnmbn();
} else
sdjfkhjkfgs();
// ------------------
foreach($array as $i)
asdfasdf($i);
// ------------------
$val=somefunc("a", "b", "c");
?>
gibi bir önerim olabilir.
Bu proje için genel çerçeveyi neye benzetmemiz gerektiği konusunda bu
akşam bir öneri ile döneceğim.
> - tum form alanlarinda, veritabani update insertlerinde su sekilde bir
> 'kontroller dizisi' kullanilacak,
Bu konuda yıllardır kullandığım ve sağlamlığını kendimce ispatlamış
olduğunu düşündüğüm bir metod/yerleşim var. Bu güne kadar LKD için
yazdığım PHP kodlarından herhangi birine bakarsanız görebilirsiniz.
Böyle bir kontroller dizisinin kullanılmasını öneriyorum.
Türkiye'deki web uygulaması geliştirme konusunda genel eğilim sanırım
muhtelif PHP dosyalarının "baslik.php", "alt.php", "sagtaraf.php" gibi
ek ıvırzıvıratı include() etmesi yönünde. Ben naçizane programlama
bilgimle bunu mantıklı bulmuyorum. Projenin çerçevesini sabitler
oluşturur mantığından yola çıkarak, içeriğin sayfadaki sabitleri
oluşturan bir script tarafından include() edilmesi metodunu yıllardır
kullanırım. Tüm denetim de birkaç temel değişkene bakılarak bu script
içerisinde, benzer bir düzende yapılır.
Eğer herhangi bir SQL deyimi en az 2 noktada aynen kullanılıyorsa bunun
için bir fonksiyon tanımlanır ve gerektiğinde bu fonksiyon kullanılır;
ama ben genellikle tüm SQL deyimlerini functions.php altında toplanan
fonksiyonlara `yığarım` ve bunları da utils.php altında kullanıcı
arabirimi oluşturmak için kullandığım fonksiyonlar içerisinde çağırırım.
utils.php içerisindeki fonksiyonlar index.php içerisinden p, m, f gibi
tek harfli değişkenlerin değerlerine göre çağrılır.
Tam olarak ne demek istediğimi bu akşam göndereceğim taslak tasarım ile
daha iyi ifade edebileceğimi düşünüyorum.
> - kod ile html katmanlari SMARTY ile birbirinden ayrilacak,
Bu iş için PEAR::IntegratedTemplates diye bir class var (varlığını Berk
Demir'den öğrendiğim, her PEAR::IT dediğimde anarım kendisini), belki
SMARTY'den biraz farklı ama PHP4 içerisinde de geldiği için mümkün olan
her yerde PEAR kullanacağız dediğimiz anda SMARTY gidiyor sanırım. Ek
paketlere bağımlılık genellikle olumlu birşey değildir.
Şimdi burada yazdıklarım C/Pascal gibi yapısal dillerle biraz kod
yazmış, genel programlama mantığını kavramış (yeterince sıyırmış? :)
herhangi bir programcının yazacakları kadar aslında.
-HAND
-- __________ | | | | Enver ALTIN (a.k.a. skyblue) | | Software developer, IT consultant | FRONT | |==========| FrontSITE Bilgi Teknolojisi A.Ş. |_____SITE_| http://www.frontsite.com.tr/