Arkadaşlar;
Helper'da ne kaldı?Ne gibi fonksiyonlar yazmamız lazım?
Tablo oluşturma var,frame oluşturma var,div var...
Mesela frame oluşturma işini nasıl yapabiliriz?
Hem boyutlar var, hem de framelerin adı var.
Bir örnek verebilir misiniz?

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

Ayrıca htmlHelper adından başka formHelper adında bir modül tanımlamak gerekiyor. Orada get post gibi iletişim methodlarının html ayağı tanımlanacak. Bu tanımlar sanırım htmlHelper miras alınarak yapılmalı. Ne dersiniz?

Alıntı:

Bence HtmlPage adında bir struct tanımlanmalı. htmlHelper'dan başka modüllerde(örneğin yukarıda anımsattığım modül.) değişkene veri yazabilmeli ve değişkeni bir kere ekrana yazdırınca html ile ilgili bütün işimiz bitmiş olmalı. String bunun için çok alt düzey kalıyor.

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

Şu an yine zamanım yok. :( Tartışma başlasın; ben sonra katılırım.

Şimdilik helper'da herşey dizgiler halinde gelişiyor. Uyumlu olmak için yeni elemanları da örneğin createList gibi yapabiliriz. Hemen aklıma gelen:

   string createFrameSet(/* boyut bilgisi buraya */, string[] frames ...)

Frame'ler de benzer şekilde:

   string createFrame(/* bunun parametrelerinden emin değilim */)

Ali

Not: Başından beri aklım bütün bu elemanların yapı veya sınıf türleri olarak ifade edilmelerine kayıyor. Şimdilik string oluştura oluştura gidiyoruz. Kesinlikle gerekene kadar sesimi çıkartmıyorum, çünkü belki de ben gereksizce öyle düşünüyorumdur. :)

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

Struct mantıklı,ne gibi özellikleri olmalı?Ne gibi değişkenler içermeli?

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

Mengü'ye frameworklerde bunların nasıl adlandırıldığını sormuştuk ve onun yanıtı da bu olmuştu. Yanılmış mı diye bakıyorum ve aklıma ilk gelen frameworkte bile doğru olduğunu görüyorum: https://bitbucket.org/ellislab/codeigniter/src/c07dcadf094e/system/helpers/

Bir D uygulamasında php uygulamasını örnek almak doğru olmayabilir. Hatta bence olmazda.

Alıntı:

Benimde düşüncem bu. Yalnız bu türün ayrı bir modülde tanımlanabileceğini söylüyorum. diğer miras alacağı modülü public ile belirtip miras alırız ve herhangi bir modülsel sorunda kalmamış olur. Ancak hepsini tek modülde tanımlamakta isteyebiliriz tabiki.

Şuanki son düşüncem sizin dediğiniz gibi:

Alıntı:

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

Alıntı (canalpay):

Programlar gerçek dünyayı, gerçek kavramları, veya çok genel olarak soyut da olsa her türlü kavramı programlama dilinin olanakları ile ifade ederler. Benim anladığım bu.

O yüzden programlardaki isimler o ismin neyi ifade ettiğini veya modellediğini göstermelidir. HTML'in standardında, tanımında, veya herhangi bir yerinde "helper" diye bir kavram yok. Onun için htmlHelper hiçbir şeyi modellemiyor.

htmlHelper'ın bir programlama kavramını modellediğini de söyleyebiliriz. Kabul. Peki bu türlerden iki nesne oluştursam ikisinin farkları nedir?

Eğer HtmlBelgesi desek anlarım. Çünkü sunucunun istemciye göndereceği belgeyi ifade eder. Bizim kütüphaneyi kullanan programcılar bundan bir tane oluştururlar ve bize "bunu istemciye gönder" derler. Böyle olunca gerçeği modellemiş oluruz. Apache altında işleyen programlama HTML belgesi oluşturma hizmeti veriyoruz.

Bunlara daha önce değindiğim için yukarıda özellikle htmlHelper'dan başladım.

Eğer bunlara katılıyorsanız formHelper yerine Form diye bir türün daha uygun olduğu fikrine katılabilirsiniz. Gerçeğe uyuyor: programcı birden fazla Form nesnesi oluşturabilir ve belgenin istediği noktalarına onlardan yerleştirebilir. "Bu HtmlBelgesi'ne bu Form'u yerleştir" deyince doğru bir modelleme oluyor.

Alıntı:

İsmine katılmadığım herhalde açık. :)

Miras konusunda temel bir kural, "bu özel tür, o genel türdendir" diyebilmektir. Bildik örnekler: "kedi hayvandır" (kedi özel, hayvan genel), "otomatik araba arabadır" (otomatik araba özel, araba genel), vs.

Eğer get ve post olayını tanımlayan türün ismi Form ise, onun hangi türden türetileceğini onunla aynı düzeyde kullanılan başka türlere bakarak anlayabiliriz:

"Bu HtmlBelgesi'ne bu formu yerleştir"
"Bu HtmlBelgesi'ne bu resmi yerleştir"
"Bu HtmlBelgesi'ne bu paragrafı yerleştir"
"Bu HtmlBelgesi'ne bu başlığı yerleştir"
vs.

Orada "form", "resim", "paragraf", "başlık", vs. nesnelerinin özel olduklarını düşünürsen onların hepsini birden genel olarak ifade eden kavram nedir? HTML belgelerinin belirli noktalarına ne yerleştirebiliriz? Bence ona HtmlElemanı diyebiliriz. Çünkü HtmlBelgesi'nin gözünde ona eklenen şeyler HTML elemanlarıdır.

Ben burada şunu görüyorum: "form HTML elemanıdır" (form özel, HtmlElemanı genel). O yüzden aklıma yatan şu:

class Form : HtmlElemanı
{
}

Her zamanki hatırlatma: tabii ki başka türlü de olabilir. ;)

HtmlElemanı her HTML elemanının sunması gereken işlevleri tanımlayan bir arayüz olabilir:

interface HtmlElemanı
{
   string girintiliÇıktı(int girintiDüzeyi) const;
}

Veya kendi üyelerinin olması gerekecekse

class HtmlElemanı
{
   string girintiliÇıktı(int girintiDüzeyi) const;
}

(Çünkü interface'lerin üyeleri olamıyor. (Not: Aslında artık final ve static üye işlevleri de olabiliyor. Bakınız: http://digitalmars.com/d/2.0/interface.html. Şurayı değiştireceğim: http://ddili.org/ders/d/interface.html))

Ali

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

Alıntı (Kadir Can):

Form bir XML elemanıdır. Etiketi "form"dur. İki niteliği vardır: "method" ve "action". method niteliğinin iki değeri olabilir: "POST" veya "GET". action ise bir URL'dir.

'...'

Oradaki '...' yerine başka elemanlar gelebilir. (Aslında etiketli elemanların "formun giriş bilgileri" gibi özel görevleri vardım ama 'un içine başka elemanlar da gelebiliyor.) Demek ki tanımlayacağımız Form'un ayrıca eleman ekleme özelliği de olmalı.

Düşünürsek: Bütün o yazdıklarım aslında genel olarak başka XML elemanları için de geçerlidir:

'<etiket nitelik="degeri" baska-nitelik="onun degeri" ...>...'

Onu modelleyen XmlElemanı diye bir türümüz olsa bütün HTML elemanlarını onu kullanarak halledebiliriz. Bold yazı da o yapıya uyar, paragraf da, form da, hepsi... :)

Ali

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

Hatırlatma: Amacımız o string'i oluşturan bir işlev yazmak değil, gerçek hayattaki "HTML formu" ve bana katıldıysanız daha genel olarak "XML elemanı" kavramlarını modellemek.

Dizgiyi göstermemin nedeni, formun kavramsal olarak nelerden oluştuğuna bakmak.

En sonunda ve bütün sayfa string'e dönüştürülürken formun da kendisini string'e dönüştürmesi çok kolay olur:

' '<' ~ etiket ~ '>' vs.'

Ali

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

(Umarım sesim kızgın gelmiyordur; yalnızca biraz hararetli. :))

Alıntı (canalpay):

Ben de, o kadar genel isimlerin yararlı olmadıklarını düşündüğümü söylemiştim. :) Ama ben, çok sevdiğim ve tanışma şansını edinmiş olduğum Kevlin Henney'nin etkisi altındayım. ACCU'da verdiği 10 Mart 2009'daki konuşmasını hatırlıyorum: http://accu.org/index.php/accu_branches/accu_usa/past Orada "util" (veya uzun olarak "utility") gibi isimleri de eleştirmişti.

Her kütüphane bir yardım getirir. CodeIgniter'cıların "helper" olMAyan kütühanelerinin ne şekilde yardım getirMEdiklerini de duymak isterim. Yardımcı olmayan kütüphaneleri yoksa neden geri kalan her şeye de "helper" demiyorlar? Bece tarihsel nedenlerle "helper" konmuş ve öyle de kalmıştır.

Başka kütüphanelerin de öyle yaptıklarını söyleyebiliriz; ama tartışmayı değiştirmez: hiçbir anlamı olmayan ve tarihsel nedenle ve belki de başkaları da öyle yapıyor diye konmuş isimlerdir herhalde.

Alıntı:

Dilden çok, ne yapıldığına bakmak gerek. CodeIgniter'da "form" diye bir kavram bile yok: form_open() ile başlayarak dizgi üretiyorlar.

Hangi dilde olursa olsun, form kavramını modelleyen bir uygulama işine dizgi oluşturarak devam etmez. Kavramları modelleyen araç türlerdir. Form diye bir tür olur ve programda o kullanılır.

Bir örnek: Kütüphaneyi kullanan programcı, belgeye bir form eklesin. Program ilerledikçe ilerideki bir noktada o önceki forma yeni bir düğme eklemek gerektiğini farketsin. Dizgi oluşturan yöntemde "o form" diye bir kavram yoktur artık. Ama Form türünde ve örneğin kullanıcıBilgisiFormu diye bir değişken olsa:

   auto kullanıcıBilgisiFormu = new Form(/* ... */);
   /* ... */
   belge.ekle(kullanıcıBilgisiFormu);
   /* ... çok sonra ... */
   if (birDurum_mu) {
       auto özelDüğme = new Düğme(/* ... */);
       kullanıcıBilgisiFormu.düğmeEkle(özelDüğme);  // <-- CodeIgniter bunu yapamaz
   }

Çünkü Form diye bir kavramları yok. HTML belgesinin yapısını modellememişler. O kütüphanenin gözünde HTML belgesi bir dizgidir.

Ben öyle görmüyorum. Ya da benim programcılıktan anladığıma uymuyor. Dediğin doğru olabilir: hangi dilden geldiğine bağlı olarak insan farklı şekillerde düşünebiliyor.

Ali

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

Dedikleriniz oldukça güzel fakat ben koda çeviremiyorum.Küçük bir örnek kod parçacığı yapabilir misiniz?

Geriye kalanları ben hallederim.

Kusura bakmayın,deneyimsiz olduğum için sizi uğraştırıyorum.

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