Forum: Projeler turna RSS
Ortam Değişkenine Değer Yazdırmak?(çerez methodu için)
Sayfa:  önceki  1  2  3  4  sonraki 
canalpay (Moderatör) #31
Kullanıcı başlığı: Can Alpay Çiftçi
Üye Tem 2009 tarihinden beri · 1133 mesaj · Konum: İzmir
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj ID 3386
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/cook…

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/fixe…
acehreli (Moderatör) #32
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4474 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Daha bütün projeyi indirip bakmadığım için özür dilerim. Ama gördüğüm kadarıyla çok iyi gidiyor. :)

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 <body> 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.

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

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

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.

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
acehreli (Moderatör) #33
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4474 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #31
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/fixe…

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
canalpay (Moderatör) #34
Kullanıcı başlığı: Can Alpay Çiftçi
Üye Tem 2009 tarihinden beri · 1133 mesaj · Konum: İzmir
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
- 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.

(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.

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.

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.

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.

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: "+", "=", "&"

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 :-)

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 ).

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.
acehreli (Moderatör) #35
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4474 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
canalpay:
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.

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);

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...

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.

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
Kadir Can #36
Üye Haz 2010 tarihinden beri · 413 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Ben görevimi alabilir miyim? :D

Ben ne yapayım proje için?Giti çözdüm.
acehreli (Moderatör) #37
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4474 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Kadir Can:
Ben ne yapayım proje için?

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

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

Ali
canalpay (Moderatör) #38
Kullanıcı başlığı: Can Alpay Çiftçi
Üye Tem 2009 tarihinden beri · 1133 mesaj · Konum: İzmir
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
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?
Kadir Can #39
Üye Haz 2010 tarihinden beri · 413 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
canalpay;
Az olsa da her şey kendi modülünde olsun.Daha düzenli olur.

Göreve başlıyorum,komutanım. :D
canalpay (Moderatör) #40
Kullanıcı başlığı: Can Alpay Çiftçi
Üye Tem 2009 tarihinden beri · 1133 mesaj · Konum: İzmir
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #38
"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!
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.)

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.
acehreli (Moderatör) #41
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4474 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
canalpay:
Evet düzeltilmiş anlamında kullanıyorum.

"fixed" ve "corrected" bir bozukluğu düzeltme anlamı taşıyorlar. Bir bozukluk olmadığı için ikisi de olmaz.

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.

"decode" uygundur. "encode" işini de başka taraf (tarayıcı, değil mi?) hallediyor.

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

Basitlik konusuna kesinlikle katılıyorum. Bazı nesne yönelimli programcı anlayışlarının tersine, ben işlevlerin önce geldiklerini düşünürüm.

Ama orada duramayız. Sınıfları ve yapıları hoş oldukları için kullanmıyoruz. Sınıf veya yapı gerekene kadar işlev, gerektikten sonra sınıf veya yapı...

Header işlevini Ali Bey siz yazar mısınız?

Bu işlev başlığı üretip örneğin bir string olarak mı döndürecek, yoksa doğrudan stdio'ya mı yazacak?

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.

Benim D modülleri konusunda fazla deneyimim yok. Ama herhalde ikisinin ortasında bir yerde buluşmak gerek.

Ali
canalpay (Moderatör) #42
Kullanıcı başlığı: Can Alpay Çiftçi
Üye Tem 2009 tarihinden beri · 1133 mesaj · Konum: İzmir
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Bu işlev başlığı üretip örneğin bir string olarak mı döndürecek, yoksa doğrudan stdio'ya mı yazacak?

Belki işlevsel programlamaya uygun değil ancak stdio kullanılarak yazılacak.

Benim D modülleri konusunda fazla deneyimim yok. Ama herhalde ikisinin ortasında bir yerde buluşmak gerek.

Benim anladığım D'ciler daha çok tek modülde toplamayı seviyor. 40 satır bile olmayan bir kod parçaları için modül tanımlamak doğru değildir bence. Heleki şu biçimde çağırmak library.post.post() zaten bir kere post demiyor muyuz? Ancak ayrı ayrı yazılmasınında importlar için fazla satır yazımından başka zararıda yok.
Kadir Can #43
Üye Haz 2010 tarihinden beri · 413 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Şimdi düşündüm,tek modül fikri iyi gibi.
canalpay (Moderatör) #44
Kullanıcı başlığı: Can Alpay Çiftçi
Üye Tem 2009 tarihinden beri · 1133 mesaj · Konum: İzmir
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Şimdi düşündüm,tek modül fikri iyi gibi.

Sağol katıldığın için. Çünkü yaptım bile :-p

Yeni modülümüz: envVar. Daha iyi bir ad önerinizi bekliyorum.

Modül : https://github.com/canalpay/turna/blob/master/library/envV…
acehreli (Moderatör) #45
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4474 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #42
canalpay:
Belki işlevsel programlamaya uygun değil ancak stdio kullanılarak yazılacak.

Onun başka bir sakıncası da çıktının yarım kalma olasılığı. CGI programı hata kodu döndürünce Apache herhalde çıktıyı kullanmıyordur ama sayfayı oluşturan parçaların bütünlüğünden emin olunmadan çıktının yazılmaya başlaması doğru değil.

Her zaman olduğu gibi itiraz etmiyorum ama doğrusunun Sayfa türünde bir nesne oluşturmak ve en sonunda ona "kendini HTML düzeninde göster" demek olduğunu söylüyorum.

Başlık satırlarından birisinin sayfa oluşturulmaya başlandıktan sonra gerektiğini düşünün. Eğer stdout'a yazmışsak başlık çoktan elimizden uçup gitmiştir. Bir başlık satırı değişkeni eklemek veya çıkartmak artık olanaksızdır.

Ali
Doğrulama Kodu: VeriCode Lütfen resimde gördüğünüz doğrulama kodunu girin:
İfadeler: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Özel Karakterler:
Sayfa:  önceki  1  2  3  4  sonraki 
Forum: Projeler turna RSS
Bağlı değilsiniz. · Şifremi unuttum · ÜYELİK
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Şu an: 2017-09-23, 18:28:13 (UTC -07:00)