Yani, tarayıcıda oturan kişinin girdiği isim, soyad gibi değerleri sonradan programda alabilmek için o "text field"lere isim vermemiz gerekiyor.

Yine daha önceki düşünceme devam ediyorum: eğer TextField olabilmek için label ve isim şartsa, ikisi de kurucu parametresi olarak gelmeli. (Erdem name'i seçime bağlı bırakmış; öyle de kullanılabiliyor herhalde. (?))

Ali

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

Alıntı (erdem):

    name_ = name;
    attributes_["name"] ~= name;

Aynı bilgiden iki tane bulunması karışıklığa neden olabilir mi sonradan? Eğer burada name_'i sonra kullanmayacaksan üst sınıfın addAttribute()'ını çağırabiliriz galiba:

   addAttribute("name", name);

Alıntı:

Tabii birden fazla TextField olabilir, değil mi?

Alıntı:

Hatta bu örneklerdeki gibi serbest metin değil de bir resim bile olabiliyor sanırım. O zaman bence formun içeriği aslında oldukça serbest. Kullanıcılarımız istedikleri elemanları istedikleri sırada addElement() ile eklesinler ve XmlElement'ın yazdırma kodu normal işleyişi ile yazdırsın.

Öyle olur, değil mi?

Ali

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

Alıntı (erdem):

Güzel bir araç. Denetimleri geçmeliyiz.

Alıntı:

O denemeyi kendim yazdığıma göre öyle kullanımları sevdiğim belli herhalde. :) Bunu da daha önce konuşmuştuk ama yalnızca parametre olarak kullanılacak olan değişkenlere isim vermeyi sevmiyorum. Bu iyi:

foo(Bar(7), Zar(42));

Şu bana gereksiz geliyor:

auto bar = Bar(7);
auto zar = Zar(42);
foo(bar, zar);

Gereksiz değişken kullanmayınca daha bir "tablo" gibi oluyor. Hatta verdiğin bağlantıdaki gibi kullanınca belgenin şekli de kod içinde görünüyor gibi.

Alıntı:

Üstü kapalı olarak geçen ilkelerimizi listeleyelim:

• Bahsettiğin "action" gibi şart olan veriler kurucu parametreleri olmalı. Böylece eksik kurulmuş nesne hatalarımız olamaz.

• Seçime bağlı olan veriler ya varsayılan değerli kurucu parametreleri olur, ya da üye işlevlerle sonradan verilebilir

• Gösterdiğin yerdeki kodda formları örneğin postFormu() diye bir işlevle oluşturmuşum. O işlev bir XmlElement döndürdüğü için fazla esnek oluyor. Onun yerine, HTML standardının bütün parçalarını özel tür olarak belirlersek tam denetimli ve neredeyse hatasız belgeler oluşturabiliriz (Form, vs. tanımlayarak zaten böyle yapıyoruz.)

• Kullanım kolay olmalı. Bu muallak bir ilke; kütüphaneyi kendimiz kullandıkça nasıl daha kullanışlı olacağını anlar ve değiştiririz

Ali

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

Metod için enum kullanman güzel. Daha önce konuştuğumuz konuları da güzelce halletmişsin.

Erdem'in uyardığı gibi, "action" da şart. Onu da kurucu parametresi yapmalıyız.

Gözüme çarpan bir şey, bütün niteliklerin hep birden veriliyor olması kullanışsız olabilir. XmlElement'tan türeyen sınıflar kendi istedikleri nitelikleri kurucularında ayarladıktan sonra, kullanıcılar ayrıca ek yapamazlar. Yani bir de setAttribute() gibi bir işlev yararlı olacak:

void setAttribute(string key, string value)

Ali

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

override string toString () {
       string result;
       result ~= "<"~tag;
       foreach ( key , value ; attributes ) {
           result ~= format(" %s=\"%s\"",key,value);
       }
       result ~= ">"~content;
       foreach (element ; elements ){
           result ~= element.toString();
       }
       result ~= "</"~tag~">";
       result ~= "\n";
   return result;
   }

toString işlevi override anahtar sözcüğü olmadan benim derleyicimde hata veriyor.

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

Tam olarak nasıl bir hata verdiğini yazabilirmisin.

Normalde sorunsuz olarak derlenmesi lazım. 'override' anahtar sözcüğünü bir alt sınıf bir üst sınıfın davranışını tekrar tanımlamak istediğinde kullanıyoruz.

Örneğin üst sınıfımız Anadol diye bir sınıf olsun. Alt sınıfımız da Ferrari diye bir sınıf olsun. Üst sınıfta Anadol 'void hızlan()' kodu örneğin Anadol arabayı 60sn'de 100 km hıza çıkartıyor diyelim. Alt sınıfta bu 'void hızlan()' işlevini Ferrari 100 km'ye 5 sn'de çıkacak şekilde tekrar üst sınıfın 'void hızlan()' işlevinin üzerine yazacak şekilde tekrar yazabiliriz. İşte bu durumda 'override' anahtar sözcüğüne ihtiyaç duyarız.

Bizim 'XmlElement' sınıfı zaten kendisi üst sınıf olduğu için 'override' yazmaya gerek yok.

Ben sorunsuz derleyebildim :rolleyes:

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

Alıntı:

Hata bu şekilde. toString işlevinin başına override anahtar sözcüğü eklediğimde düzeliyor. Şu ara tam da bu konuyu çalışıyor olduğumdan helper'in gelişimini takip ederek kodları anlamaya, yapılanı kavramaya çalışıyorum. Yine kitapta şöyle bir ifade var:
Alıntı:

Dikkatimi çekmesi ve üzerine bu biçimde düşme nedenim buydu. Biraz daha açarsam: helper.d içerisindeki şu toString işlevi:

string toString () {

bu şekilde override anahtar sözcüğü kullanılmadan tanımlanıp derlendiğinde bende hata veriyor. Ancak yukarıdaki kitaptan alıntıladığım bölümde anlatıldığı gibi 'override' ile işaretleyince sorun ortadan kalkıyor ve helper.d derlenebiliyor

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

Hımm.. Doğru düşünmüşsün. Demek ki 'XmlElement' de 'Object''den türediği için ve 'Object ''XmlElement''in üst sınıfı olduğu ve 'toString' isimli bir üye işleve sahip olduğu için o zaman yazmalıyız. Düzeltme için teşekkürler :)

Ben de kodu derlerken uyarı seçenekleri ile derlemeye alışmalıyım sanırım :-D

'$ dmd xmlelement.d -ofxmlelement -w'

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

Evet, her sınıf Object'ten türediğinden orada tanımlı olan toString() işlevinin bastırılması anlamına geliyor 'override'. Sayenizde pekiştiriyorum ben de kendi hesabıma dili.
:-)

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

Bu arada modüle xml yorumları için değer olarak -- karakterleri kullanılmadığını yada xml içinde < gibi xml için özel olarak tanımlanmış karakterlerin kullanılmadığını kontrol etmeniz gerekiyor. Hatırlatmakta fayda var.

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