Aynı alanı elli ekranda elli kez tanımlamamanın yolu

Büyük bir ERP'de "ürün kodu" gibi bir alan onlarca ekranda, onlarca tabloda tekrar tekrar karşınıza çıkar. Her seferinde uzunluğunu, formatını, zoom (arama) davranışını ayrı ayrı tanımlarsanız, bir gün "ürün kodu uzunluğunu 20'den 30'a çıkaralım" kararı geldiğinde elli farklı yeri güncellemeniz gerekir — ve kaçınılmaz olarak birini atlarsınız. TROIA'nın Domain kavramı tam olarak bu problemi çözmek için var: tek bir yerde tanımlanan, birçok kontrol/tablo alanı/veritabanı kolonu tarafından paylaşılan bir meta-veri tanımı.

Bir domain neyi standartlaştırır

  • Alan tipi ve alt tipi: Veri tipi (ODBA ya da sanal tablo kolonu) ve kontrol alt tipi — dinamik kontrol oluşturmada kullanılıyor.
  • Uzunluk ve ondalık basamak: String ve sayısal tipler için boyut sınırları.
  • Check Table / Zoom Dialog / Zoom Field / Zoom Filter: Bir alana "büyüteç" (zoom/arama) ile değer seçtirme davranışının tüm parametreleri.
  • Salt okunur / sadece zoom ile giriş & büyük-küçük harf duyarlılığı: Alanın nasıl düzenlenebileceği.
  • Etiketler (SLabel/MLabel/LLabel/HLabel): Farklı ekran genişliklerinde gösterilecek kısa/orta/uzun/başlık metinleri.
  • Seçenekler ve tooltip: Combobox değerleri ve yardım metni.

Override mekanizması: domain'i miras alıp yerelde değiştirmek

Bir kontrol, domain'in bir özelliğini kendi seviyesinde geçersiz kılabilir. Domain'den gelen değeri korumak istediğinizde özel bir işaretleyici kullanılır: string alanlar için {D}, integer alanlar için -10. Bu işaretleyiciyi görmeden "bu kontrolde değer boş/tanımsız görünüyor" diye endişelenmeyin — bu, "domain'in ayarını kullan" anlamına gelen bilinçli bir değerdir.

Domain kodları: olaylar ve dönüşümler domain seviyesinde de tanımlanabilir

Şaşırtıcı bir esneklik: TEXTCHANGED, ZOOMBEFORE, ZOOMAFTER, LOSEFOCUS, GAINFOCUS, RIGHTCLICKMENU, DRAG, DROP, PASTE gibi olaylar domain seviyesinde de kodlanabilir. Bu kod, sadece o domain'i kullanan kontrolün kendi olay implementasyonu yoksa çalışır — yani domain, "aksi belirtilmedikçe" varsayılan bir davranış sağlıyor. Bir ekranda beklenmedik bir LOSEFOCUS davranışı görürseniz ve o kontrolün kendi kodunda hiçbir şey yazmıyorsa, bir sonraki durak domain tanımı olmalı.

İki yönlü veri dönüşümü için ayrı kodlar var:

  • SERVER TO CLIENT CODE: Sunucudaki değeri istemciye gösterirken dönüştürür.
  • CLIENT TO SERVER CODE: İstemciden gelen değeri sunucuya kaydetmeden önce dönüştürür.

Ve bir Validation Code: değişkenle aynı tipte bir parametre alır, geçerliyse 1, geçersizse 0 döner. Bu, bir alanın formatını (örneğin bir vergi numarası deseni) tüm kullanıldığı yerlerde tutarlı şekilde doğrulamanın merkezi yolu.

Nerede tanımlanır, nerede saklanır

Domain'ler DEVT10 System Domains transaction'ında oluşturulup yönetiliyor. Arka planda dört tabloya dağılmış durumda: SYSDOMAINS, SYSDOMAINSX, SYSDOMAINSTXT, SYSDOMAINLINK. Bir domain'in kullanıldığı tüm yerleri bulmanız gerektiğinde (örneğin bir uzunluk değişikliğinin etki alanını ölçmek için), SYSDOMAINLINK tablosu başlangıç noktanız olmalı.

Gerçek bir örnek: ortak bir "E-posta" domain'i

Bir "EPOSTA" domain'i tanımlayıp: uzunluk 150, Validation Code'da basit bir @ ve . kontrolü, CLIENT TO SERVER CODE'da küçük harfe çevirme (LOWER()) yazarsanız — bu domain'i kullanan her ekran (müşteri kartı, tedarikçi kartı, kullanıcı ayarları) otomatik olarak aynı doğrulama ve normalize etme davranışını kazanır. Yarın "e-posta doğrulamasını güçlendirelim" kararı gelirse, tek değişiklik yeri DEVT10'daki bu domain tanımıdır.

Sık yapılan hatalar

  • Aynı anlamdaki alan için her ekranda ayrı domain/serbest tanım kullanmak — bu, domain kavramının çözmeye çalıştığı problemin ta kendisi; yeni bir alan eklerken önce "bu zaten var olan bir domain'e uyuyor mu" diye sormak, ileride tutarsızlığı önler.
  • {D}/-10 işaretleyicisini "boş değer" sanıp silmek — bu değeri kaldırıp yerine gerçek bir sabit yazmak, o kontrolü domain'den kalıcı olarak koparır; domain'de yapılan gelecekteki güncellemeler artık o kontrolü etkilemez.
  • Domain seviyesinde tanımlı bir olayın neden çalışmadığını anlamadan kontrol seviyesinde aynı olayı boş bırakmak — kontrolün kendi olay kodu var ama boşsa, bu genelde domain'in varsayılanını değil, kontrolün boş implementasyonunu çalıştırır; domain davranışını miras almak istiyorsanız kontrol seviyesinde o olayı hiç tanımlamamanız gerekir.
  • Validation Code'da tip uyumsuzluğu — fonksiyonun aldığı parametrenin, domain'in bağlı olduğu değişken tipiyle birebir eşleşmesi gerekiyor; aksi halde doğrulama sessizce çalışmayabilir.

Sıradaki adım

Bir sonraki yazıda operatörlere ve tip dönüşümüne (== ile karşılaştırma, = ile atama, basit tipler arası otomatik casting) değineceğim.