Daha başka yolunu bilmiyorum. Ancak bir daha dene.

ssh eklenmeden github kullanılıyor mu bilmiyorum?
Giti bilen biri yanıt yazar.

Konuya dönersek.

setCookie ayarlamak için iki tane "\n" yazdırıyorduk ya. Bu nedenle bende iki kere \n basmak yerine tek kere basıyorum. setCookie işlemlerini bitirdikten sonra registerCookie() işlevini yazdırmasını istiyorum. Sizce nasıl tasarım? Birde clearCookie işlevini sildim. Gerek yok.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı:

>

setCookie ayarlamak için iki tane "\n" yazdırıyorduk ya. Bu nedenle bende iki kere \n basmak yerine tek kere basıyorum. setCookie işlemlerini bitirdikten sonra registerCookie() işlevini yazdırmasını istiyorum. Sizce nasıl tasarım? Birde clearCookie işlevini sildim. Gerek yok.

Dediğim gibi setCookie işevinde iki tane satır başı karakteri bastırdığım için birden fazla cookie tanımlanamıyordu. Bende satır başı karakterlerini bire indirdim ve ayrıca registerCookie diye bir işlev tanımladım. Bunun nedeni cookie işlevinin tanımlanmasını bitirmek. Sadece çıkışa yeni satır karekteri gönderiyor.

clearCookie işlevinide yorum satırları arasında gönderdim. Gerçekten gerekli mi emin olmadığım için.

Bakmak isteyenler olabilir diye : https://github.com/canalpay/turna/blob/master/library/cookie.d

fixedStringForCookie adında işlev yazdım. post ve get methodu için yazdığım fixedString(yeni adı şu olabilir: fixedStringForGetAndPost) işlevinin hemen hemen aynısı. Kod tekrarı sayılabilir ancak bunu yapmamın nedeni ilerde cookie'ye özgü veya get ve post'a özgü sorunlar yaşarsak kod değişikliği yapmamızın kolay olması için.

Bakmak isteyenler olabilir diye : https://github.com/canalpay/turna/blob/master/library/fixedString.d

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Ben görevimi alabilir miyim? :D

Ben ne yapayım proje için?Giti çözdüm.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

canalpay;
Az olsa da her şey kendi modülünde olsun.Daha düzenli olur.

Göreve başlıyorum,komutanım. :D

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı:

>

• yanılmıyorsam boş satır bütün başlığın sonuna geliyor, çerez'in değil. O yüzden işlevin ismi endHeader() gibi de olabilir

Header ile ilgili zaten öyle yapacaktım ancak header ile ilgili pek bilgim olmadığından yapmadım. Header modülü yazdığımda yapacağım diye not almıştım ancak header'ı pek iyi bilmediğimden ve birden fazla çerez tanımlamak için geçici çözüm olarak koydum.

Alıntı:

>

(Bu arada "end", "bitir" olarak anlaşılıyor; senin endCookie değişkeninin ismi "sonuç" anlamına gelen "result" veya "cookieValue" gibi olabilir.)

Get modülünü yazarken fixedString modülünüde yazmıştım. Orada çok fazla değişken tanımladığımdan hatta bir sıra abartıp değişkenlerin önüne one two... diye getirdiğimden artık bu tanımladığım son değişken diye ayrıca get modülünün tanımının sonu diye end adını koymuştum. result olarak düzeltmek gerekiyor tabiki.

Alıntı:

>

Projeye daha geniş olarak bakmadan setCookie'nin tasarımında bir noktaya dikkat çekmek istiyorum: parametrelerinin hepsi birden bir çerez tanımlıyorlar. O zaman Cookie isminde bir tür tanımlamak ve parametre olarak onu kullanmak yararlı olabilir:

void setCookie(Cookie cookie)

Ama o söylediğim aşağıda hatırlattığım YAGNI ile çelişiyor. Onun için Cookie türünü gerçekten gerekirse yazarsın.

Php'de benim yaptığım gibi yapılmış ve oldukça rahat kullanılıyor. Genelde 2 parametre kullanılacağına göre gerçekten gerekmiyor.

Ancak Tango kütüphanesine baktım orada da cookie diye tür tanımlanmış. İleride gerekirse yaparız.

Alıntı:

>

Burada bağlı gelinmesi gereken YAGNI ilkesini hatırlatayım: "You ain't gonna need it". Kodun gerektiği zaman yazılmasını önerir. O ilkenin bir söylediği, ileride gerekir diye yazılmış olan işlevlerin çoğu ileride gerekmiyor.

İleride gerekeceği kesin. Ben yinede emin olamamıştım çünkü çok basit bir kod olduğundan kullanıcıda koyar diye düşündüm ayrıca php'de böyle bir işlev bulamamıştım. Ancak koymaya karar verdim.

Alıntı:

>

Herhalde yanlış anlıyorum ama "fixed" onların immutable olduklarını mı söylüyor.

Yok ingilizcem o kadar da kötü değil :-P Şu diziyi :
hayvan=at&derece=Orta&sevilen+hayvan=ğüşçü&ikinci+d%C3%BC%C4%9Fme=Ba%C5%9Fka+D%C3%BC%C4%9Fme

İstediğim biçime getiriyor. Bana göre düzeltiyor.

Alıntı:

>

ForCookie ve ...ForGetAndPost farkları da ikincisinden yalnızca değerinin alınıyor olması mı? Belki de bu gerçeği yansıtmak daha iyi olabilir: ikincisinin ismini readCookieValue() gibi yapabiliriz.

yeni isimleri forCookie ve forGetAndPost.

İki işlevin farkı düzenlediği karakterler:
forCookie işlevinin düzenlediği karakterler: "; " ve "=".
forGetAndPost işlevinin düzenledği karakterler: "+", "=", "&"

Alıntı:

>

O zaman bütün içtenliğimle ve tabii ki şaka olarak "başına gelsin de gör!" diyorum. :-p

Yok zaten dkv'de uyarmıştınız son anda yırttım :-) Ancak bunda kodlar tamamen aynı değil. Birinde ekstra iş yapılıyor.
Mesajın yazımı bittikten sonra eklenen not:
Bir daha düşündüm aynı. :-) Ancak takma ad ile yine o adları kullanacağım :-) Okunabilirlik için :-)

Alıntı:

>

Onların kodlarını gözden kaçırmışım; şimdi baktım. Tekrarlanan bölümlerindeki bir fark kullanılan ayraç, değil mi? O zaman o bölümü başka bir işleve yaptırmak gerekiyor. Bu ikisi onu farklı ayraç değeriyle çağırırlar.

Bir farkta birinde + değeri değişecek diğerinde değişmeyecek. Onun içinde bool türünde bir parametre daha koyarız. Bol parametreli işlevleri ben çok severim ancak bu bir yanlışmış.(3 parametre fazla değil ama :-))

Şimdi aklıma geldi. Takma isim veririz. false true için if gerekecek. Buda herhalde programı mikro saniye bazında yavaşlatır.(Webte bunu önemseyenler var :-P ).

Alıntı:

>

Ayrıca ";" ayracı yalnızca cookie için değil: HTML belgelerinin bütün başlık değişkenleri için geçerli. Şimdilik cookie'den başka şeyle ilgilenmiyoruz ama akılda tutmakta yarar var.

Ad önerisi? Belki aynı biçimde hepsi için ayrıca takma ad kullanmak daha iyi olur.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı:

>

Bu konuda Can'ın fikrini bekleyelim ama ben senin için anladıklarımı şurada yazmıştım:

http://ddili.org/forum/post/3373

Evet.(Oradaki mesajları okursan ne yapacağını anlamış olursun) Kodlar ingilizce olacak. Değişken adları düzgün olmazsa Ali Bey düzeltir :-)

Yazacağın modül system/helpers dizininin içinde olacak.

Bu arada ben get post gibi modülleri tek modülde mi toplayayım? Bir modülde bir işlev çok az olmuyor mu? Olursa modül adı için bir fikir?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı:

>

"Corrected" anlamında kullanıyorsun yani. Hiç aklıma gelmemişti. :) Aslında bir bozukluk olmadığına göre başka yerde de duyduğumuz gibi "decoded" denebilir.

Evet düzeltilmiş anlamında kullanıyorum. decode olabilir o ne bileyim sanki daha karmaşık bir şeyi çözüyormuş gibi geliyor. Birde bunun tersi encode işlevide olması gerekiyor diye düşünüyorum. O yüzden belki corrected adını kullanabiliriz. Gerektiği gibi değiştirin lütfen!
Alıntı:

>

O tür parametreler işlevin çağrıldığı noktaların anlaşılmalarını güçleştiriyorlar. Abartarak:

birİşlev("merhaba", 42, true, false, true);

O true ve false'ların ne anlama geldiklerini hatırlamak çok güç. O yüzden ben ve başka arkadaşlar enum kullanılmasını öneririz. İsimlerinin uzun olduklarını bilerek:

Phobosta filan görüyorum. Kesinlikle olmalı.

Library dizininde herhangi bir modülde ben sınıf düşünmüyorum. Hepsi işlev olacak ve basit basit kullanılacak.

Header işlevini Ali Bey siz yazar mısınız?(Sadece işlevler olursa sınıf olmazsa iyi olur.)

Alıntı:

>

canalpay;
Az olsa da her şey kendi modülünde olsun.Daha düzenli olur.

Gereksizce her modülü çağırmaya gerek yok. İllaki bir modülde toplayacağız. Ya sınıf yazıp yapacağız ki ben öyle istemiyorum, ya takma ad kullanacağız ya da tek modülde toplayacağız. Sonuncusu bana en mantıklısı geliyor.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Daha bütün projeyi indirip bakmadığım için özür dilerim. Ama gördüğüm kadarıyla çok iyi gidiyor. :)

Alıntı (canalpay):

>

Dediğim gibi setCookie işevinde iki tane satır başı karakteri bastırdığım için birden fazla cookie tanımlanamıyordu. Bende satır başı karakterlerini bire indirdim

Şu söylediğim yanlışmış:

Yani "Set-Cookie" başlık değişkeninin değerinin tek satırda bulunması gerekiyordu. Mantıklı. Boşlukları HTML'in başlık bölümünde D'de yapabildiğimiz gibi serbestçe kullanamıyoruz. Öte yandan HTML'in bölümündeki satır başlarının ve birden fazla boşluğun önemi olmuyor. Biraz garip... :)

Başında boşluk (veya tab) karakteri bulunan satırlar önceki satıra ait oluyormuş:
'
Set-Cookie: bir-şey;
başka-şey'

Projeye daha geniş olarak bakmadan setCookie'nin tasarımında bir noktaya dikkat çekmek istiyorum: parametrelerinin hepsi birden bir çerez tanımlıyorlar. O zaman Cookie isminde bir tür tanımlamak ve parametre olarak onu kullanmak yararlı olabilir:

void setCookie(Cookie cookie)

Ama o söylediğim aşağıda hatırlattığım YAGNI ile çelişiyor. Onun için Cookie türünü gerçekten gerekirse yazarsın.

Alıntı:

>

registerCookie diye bir işlev tanımladım. Bunun nedeni cookie işlevinin tanımlanmasını bitirmek. Sadece çıkışa yeni satır karekteri gönderiyor.

İyi bir fikir. Ne kadar kısa olurlarsa olsunlar, kavramsal olarak farklı anlama sahipseler ayrı işlevler yazmak yararlıdır.

Ama burada iki yorumum var:

• yanılmıyorsam boş satır bütün başlığın sonuna geliyor, çerez'in değil. O yüzden işlevin ismi endHeader() gibi de olabilir (Bu arada "end", "bitir" olarak anlaşılıyor; senin endCookie değişkeninin ismi "sonuç" anlamına gelen "result" veya "cookieValue" gibi olabilir)

• eğer HtmlHeader diye bir tür de olursa, o boş satır o türün kendisini yazdıran üye işlevi tarafından da halledilebilir

Alıntı:

>

clearCookie işlevinide yorum satırları arasında gönderdim. Gerçekten gerekli mi emin olmadığım için.

Burada bağlı gelinmesi gereken YAGNI ilkesini hatırlatayım: "You ain't gonna need it". Kodun gerektiği zaman yazılmasını önerir. O ilkenin bir söylediği, ileride gerekir diye yazılmış olan işlevlerin çoğu ileride gerekmiyor.

Ayrıca açıklama satırları halinde kod eklenmesine de iyi gözle bakılmaz. Benim başıma da çok gelen bir olay, toptan yapılan bazı değişikliklerin öyle ölü satırlarda bile çalışma gerektirmesidir. Bazı işlevlerin açıklama satırı olduğu farkedilmez ve onda da değişiklik yapılır.

Tabii bunlar kullanılmıyor diye geride de bırakılamazlar çünkü birisi onları canlı koda dönüştürdüğü an hata oluşabilir. O yüzden clearCookie gibi işlevler belki de hiç kullanılmayacak olsalar da geliştirme aşamasında bile yük olmaya devam ederler.b

Alıntı:

>

fixedStringForCookie adında işlev yazdım. post ve get methodu için yazdığım fixedString(yeni adı şu olabilir: fixedStringForGetAndPost) işlevinin hemen hemen aynısı.

Herhalde yanlış anlıyorum ama "fixed" onların immutable olduklarını mı söylüyor. Öyleyse gerekmemeli çünkü zaten dönüş türünden anlayabiliriz. ...ForCookie ve ...ForGetAndPost farkları da ikincisinden yalnızca değerinin alınıyor olması mı? Belki de bu gerçeği yansıtmak daha iyi olabilir: ikincisinin ismini readCookieValue() gibi yapabiliriz.

Alıntı:

>

Kod tekrarı sayılabilir ancak bunu yapmamın nedeni ilerde cookie'ye özgü veya get ve post'a özgü sorunlar yaşarsak kod değişikliği yapmamızın kolay olması için.

O şekilde düşünmemeni öneririm. Gerektiğinde kod serbestçe değiştirilmelidir. Bunun en büyük yardımcısı da birim testleridir. Birim testleri olan kod korkusuzca değiştirilebilir; çünkü nasıl çalıştığı testler tarafından belirlenmiştir. Tabii bunun da ististaları vardır ve hatalar oluşabilir. Ama kod tekrarının kötülüğünü görmek için "başına gelmekten" daha iyi yöntem yok. O zaman bütün içtenliğimle ve tabii ki şaka olarak "başına gelsin de gör!" diyorum. :-p

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (canalpay):

>

fixedStringForCookie adında işlev yazdım. post ve get methodu için yazdığım fixedString(yeni adı şu olabilir: fixedStringForGetAndPost)

...

Bakmak isteyenler olabilir diye : https://github.com/canalpay/turna/blob/master/library/fixedString.d

Onların kodlarını gözden kaçırmışım; şimdi baktım. Tekrarlanan bölümlerindeki bir fark kullanılan ayraç, değil mi? O zaman o bölümü başka bir işleve yaptırmak gerekiyor. Bu ikisi onu farklı ayraç değeriyle çağırırlar.

Ayrıca ";" ayracı yalnızca cookie için değil: HTML belgelerinin bütün başlık değişkenleri için geçerli. Şimdilik cookie'den başka şeyle ilgilenmiyoruz ama akılda tutmakta yarar var.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

Alıntı (canalpay):

>

Alıntı (acehreli):

>

Herhalde yanlış anlıyorum ama "fixed" onların immutable olduklarını mı söylüyor.

Yok ingilizcem o kadar da kötü değil :-P Şu diziyi :
hayvan=at&derece=Orta&sevilen+hayvan=ğüşçü&ikinci+d%C3%BC%C4%9Fme=Ba%C5%9Fka+D%C3%BC%C4%9Fme

İstediğim biçime getiriyor. Bana göre düzeltiyor.

"Corrected" anlamında kullanıyorsun yani. Hiç aklıma gelmemişti. :) Aslında bir bozukluk olmadığına göre başka yerde de duyduğumuz gibi "decoded" denebilir.

Alıntı:

>

Onun içinde bool türünde bir parametre daha koyarız.

O konuda da genel bir önerim var. Çalıştığım yerlerde de işlevin davranışını belirlemek için bool değişkenler kullanılıyor. Örneğin bizdeki bir işlevin parametresi büyükHarfÖnemli_mi gibi bir şey.

O tür parametreler işlevin çağrıldığı noktaların anlaşılmalarını güçleştiriyorlar. Abartarak:

birİşlev("merhaba", 42, true, false, true);

O true ve false'ların ne anlama geldiklerini hatırlamak çok güç. O yüzden ben ve başka arkadaşlar enum kullanılmasını öneririz. İsimlerinin uzun olduklarını bilerek:

birİşlev("merhaba", 42, BüyükKüçükFarkı.önemli, BirdenFazlaBulunsun.evet, BaşkaBirAyar.hayır);

Alıntı:

>

Bol parametreli işlevleri ben çok severim ancak bu bir yanlışmış.(3 parametre fazla değil ama :-))

Temelde bir yanlışlık yok ama bir noktadan sonra aynı grup parametreleri birden fazla işleve gönderildiği farkedilince o grup parametrenin aslında tek bir tür olmaları gerektiği anlaşılıyor.

Cookie örneğine dönersek, parametreleri o şekilde gruplamak kodun anlaşılmasına da yarıyor. Artık ayrı parametrelerin birlikte cookie anlamına geldiklerini bilmek zorunda değiliz; türleri bunu söylüyor zaten. Gibi...

Alıntı:

>

Buda herhalde programı mikro saniye bazında yavaşlatır.(Webte bunu önemseyenler var :-P ).

Web çatısı için tabii ki çok önemli olabilir ama yanlış algoritmalar seçilmediği sürece bu tür yavaşlıklara sonradan eğilmek gerekir. Ancak ve ancak ölçtükten sonra.

Alıntı:

>

Alıntı:

>

Ayrıca ";" ayracı yalnızca cookie için değil: HTML belgelerinin bütün başlık değişkenleri için geçerli. Şimdilik cookie'den başka şeyle ilgilenmiyoruz ama akılda tutmakta yarar var.

Ad önerisi? Belki aynı biçimde hepsi için ayrıca takma ad kullanmak daha iyi olur.

HeaderVariable veya HeaderLine olabilir. Bir kere o tanımlanırsa, Cookie onu kullanabilir. Hiç derlemeden:

class HeaderLine
{
   string name;
   string[string] values;

   /* İsmi olmadan olmaz */
   this(const(char)[] name)
   {
       this.name = name.idup;
   }

   /* ... addValue(), vs. */
}

class Cookie : HeaderLine
{
   /* Kendi üye değişkenlerine gerek bile yok */

   this()
   {
       super("Set-Cookie");
   }
}

Yani "Cookie bir HeaderLine'dır" diyoruz. Sonra cookie.addValue("bir şey", "değeri") yapılabilir.

Veya Cookie, senin önceki işlevindeki parametreleri kurucu parametreleri olarak şart koşar ve hepsini addValue()'yu çağırarak kurar. Böylece elimizde kullanıma hazır bir HeaderLine oluşur:

class Cookie : HeaderLine
{
   /* Kendi üye değişkenlerine gerek bile yok */

   this(string data,
        long expiresIn = 0,
        string path = null,
        string domain = null,
        bool httpOnly = false)
   {
       super("Set-Cookie");

       /* Burada üst sınıfın addValue()'sunu her değer için çağırabilir  */
   }
}

Eğer HeaderLine.toString() de yazılmışsa cookie.toString() denerek satır oluşturulabilir.

Bunların hepsi tartışmaya açık. Sonuçta "öyle de olur böyle de"... :) Aklıma gelenleri yazıyorum.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]