Önümüzdeki yol - 1

by Necat Bolpaça 16. December 2007 13:58

asp.net in yapısı ve diğer cgi tabanlı işlere göre üstünlüğünü hep abartmışımdır biraz. Fanatiklik mi diyelim artık buna, yoksa "kuzguna yavrusu şahin görünür" diye mi açıklamalı? Yazdığım kodları gözden geçirdiğimde, gerek benim .net framework ün istediği standartlara tam uyamadığım için, gerekse aslında en ideal mimari yapı asp.net yorumlayıcısı tarafından render edilemediği ama işlerin bir şekilde yürümesi gerektiği ve kodların araya sıkıştırılması sonucu, tam modüler bir yapıya halen kavuşamamışım. Ve sağda solda reklamı çıkan Dundas Upload, netadvantage chart gibi bileşenleri yazmak için takip edilmesi gereken süreç, tıpkı eski perl scriptlerini yazmak için gereken süreç gibi geliyor bana. Bu yüzden bu çelişkiye yeninin içindeki bu eskiye şaşırmaktayım daha geniş bir bakış açısından baktığımda.

Javascript kodlarının kontroller içine gömülmesi : Tasarım zamanında müdahale edilemeyen Repeater, DataList, DataGrid ve GridView gibi bileşenlerin her satırına veya her öğesine ItemDataBound veya RowDataBound olayı ile erişip, onların özelliklerine js eklemek, örneğin memnun olmadığım şeylerin başında geliyor. asp.net 3.5 örneklerinde yazılan js örneklerinde (sender,eventargs) şeklinde bir göndermeye rastladım. Acaba, biz kontrolün render edilme şeklini tahmin ederek, onların içine gerekli olayları sonradan iliştirip, js ile aspx kodlarını birbirinden iyice ayırabilir miyiz? Yapı itibarıyla her cihaza farklı render çıktısı verdiğinden (en azından teorik olarak böyle) bu hareketten çekinmekteyim.

Javascript kodlarının <body> düğümü içine yazılması : Master Pages çıktı çıkalı bu tür hatalı örneklere rastlamaktayım. Ancak bunun çözümü basit. <head> içinde ayrı bir ContentPlaceHolder tanımlayıp, onun içinde CSS ve js kodlarımızı yerleştirebiliriz.

CSS veya Temalar : App_Themes ile birlikte nesneye iliştireceğimiz CSS class(ları) ve özellikleri kodun içinden ayıklanmış durumda. Bu durumdan çok memnunum. Ancak nesnenin ClientID değerini <%%> bloğu olmadan elde etmenin bir yolu olmalıydı diye düşünüyorum.

Platform anlayışı, (dil & kütüphane ayrımı) : Python un sloganı olan "batteries included" anlayışının bir benzeri bizde de var. Madem asp.net kullanıyorsun, o halde senin kullanacağın kütüphane bellidir? Common Type System nedeniyle aynı tipleri paylaşan tonla (ama pratikte iki adet C#, VB) dil var. Bu çok kullanışlı bir şey olsada gittikçe kullanılan kütüphanelerin  her  yeni  sürümle birlikte kullandığımız platforma eklenmesinin bazı sakıncaları olduğunu düşünüyorum. Nedir bunlar?

  • "Platformumuzun" boyutu şiştikçe şişiyor.
  • Platformumuzu başka işletim sistemlerine taşımak (port) isteyenlerin işi artıyor, zorlaşıyor.
  • İdeal mimariden (sapla samanı, markup ile js i css i ayırmamak mesela) uzaklaşma tehlikesi doğuyor.

.net framework 1.0 dan bu yana, şu ünlü /bin klasörüne atılan assembly lerin otomatik olarak entry point inin bulunduğu ve üçüncü parti kütüphanelerin çalışmaya hazır hale gelmesi gibi büyük bir nimet var elimizde buna karşılık. Ancak bu doğal koda (native code) çağrı yapmayan kütüphaneler (mscorlib.dll harici dll ler) için geçerli.

Eğer biz, asp.net kullanıyor ve onunla kodluyor isek, (bence) kodlama konusunda bir takım prensipler belirlememiz gerekli. Öncelikle kullandığımız platforma, platform gözüyle bakmamız gerektiğine inanıyorum. Pazarlama amaçlı "her yerde çalışabilir" sloganlarını ancak biz gerçekten işler hale getirebiliriz, tabii eğer tercihimiz bu ise veya ileride bunu düşünüyorsak şimdiden bazı alışkanlıklarımızı değiştirmemiz faydalı olacaktır.

Haftaya yazmayı planladığım bir sonraki yazıda: 

  • Mono bizim için ne kadar kullanışlı olabilir?
  • Silverlight hakkındaki görüşler (Burada Azer Koçulu nun bir sunumundan da faydalanacağım)
  • Ajax kütüphaneleri ve dhtml frameworks, nasıl entegre edebiliriz? 

Tags:

Vizyon | asp.net | Türkçe

Ajax? Remote Scripting? (ceviz.net)

by Necat Bolpaça 9. December 2007 18:05

Not: Bu yazı şu anda ceviz.net ana sayfasında  http://www.ceviz.net/ajax-remote-scripting_a1095.html  adresinde de yayınlanmaktadır.

Bu günkü yazımızda size remote scripting i anlatmayı planlıyorum, remote scripting, bir html sayfasının yeniden yüklenmesine gerek kalmadan yayınlandığı sunucu ile (evet sadece yayınlandığı sunucu ile, bu kısıtlama güvenlik sebebiyle konulmuştur, ama aşılabilir.) iletişimini sağlayan kodlama kalıplarıdır.

Google ajax ın reklamını yapmadan çok önce de ajax denilen şey remote scripting adı altında yapılıyordu, ama ne zaman ajax meydana çıktı javascript in yıldızı parladı, sinir bozucu java - javascript ayırt edememezliğinin yanına bir de ajax ile dhtml ayırt edememezliği çıktı.

Bildiğim kadarıyla size remote scripting in (rs, ajax ı kapsar bu yüzden ondan bahsedeceğim) tarihçesini kendi bakış açımdan anlatayım:

  • Remote scripting ile ilk tanışmam www.yazgelistir.com dan bir arkadaşın sadece ie 5.5+ da geçerli olan <xml> elementiyle sunucu ile iletişim kurmasıyla başlar. (Şu an o site üzerindeki aramalarım ne yazık ki bir sonuç vermedi, yazıyı yazanın ismini burada anmayı ve yazıya link vermeyi çok isterdim rastlayan biri varsa veya o yazının yazarı şu an bunu okuyorsa bana bildirebilir, o yazı zamanının çok ilerisinde bir yazı idi çünkü) **Ekleme : Yazı sayın Turgut Haspolat tarafından yazılmış.**
  • O tarihlerde .net 1.0 dan 1.1 e yeni yeni geçiyordu, asp.net sayfalarında SmartNavigation diye bir özellik vardı peki ne yapardı bu SmartNavigation? kendine özgü bir js kodu ile sayfanın içinde bir IFRAME elementi oluşturur ve sayfanın içine ekler, request i o iframe içinden yapar ve dönen yanıtı (IFRAME elementinin outerHTML özelliği) o IFRAME i içeren sayfaya (normal sayfamız) yansıtırdı, böylece sayfanın postback işlemi anlaşılmazdı. Ama bu özellik sadece IE ailesiyle çalışıyor, çünkü outerHTML standart bir özellik değil.
  • Microsoft.XMLHTTP ve Msxml2.XMLHTTP2 vardı ama tüm tarayıcılarla çalışmadığı için popüler değildi. Açıkcası Mozilla, Mozilla Firefox olana kadar bu nesnelerden haberi olan kişi sayısı az idi.
  • Sanıyorum XmlHttpRequest nesnesine ilk desteğini veren tarayıcı Safari idi, yanılıyorsam düzeltin ama onunla ilgili ilk dökümanlara apple sitesinde rastlamıştım.
  • Firefox 1 in yaygınlaşması ve google ın gmail hizmetinde bu nesneleri kademeli olarak kullanması ayrıca "google suggest" adını verdiği daha aradığımız şeyi arama kutusuna yazarken sonuçların "ajax" ile sorgulanması ve hemen metin kutusunun altındaki bir (layer, div) içinde gösterilmesi söz konusuydu. Eh google bunu javascript (hem de anlaşılmaz yapmaya çalıştıkları bir javascript) ile yapınca herkes bunu merak edip sağda-solda bloglarda decode edebildiği ve mantığını anlatabildiği kadarını, yayınlamaya başladı.
  • Sonra şu kalıp (ki sanırım çoğu ajax kütüphanesinin temel kalıplarından biridir.)  http://jibbering.com/2002/4/xmlhttp.js
  • Daha çok php programcılarının kullandığına şahit olduğum sajax, xajax gibi kütüphaneler.

  • Atlas ın geliştirilmesine başlandı (şimdiki adıyla asp.net ajax)
  • Anthem ile tanıştık. ajaxpro, anthem gibi üçüncü parti kütüphaneler (ki anthem kendi içinde dosya upload ederken iframe kullanmaktadır) gördük.
Gerek cevizde gerekse diğer yerli ve yabancı sitelerde çokca rastladığım bir hataya, ajax ile javascript ayrımınının yapılamamasına karşılık, şimdi bir çizgi çizmek gereklidir diye düşünüyorum bu çizgi ajax denilen şeyin sadece sunucudan veri alınan durumlar için geçerli olduğunu savunduğumdur. Gelin örnek iskelet kod üzerinde birlikte inceleme yapalım.

Örnek iskelet kod olarak şunu kullanacağım : http://forum.ceviz.net/showthread.php?t=17334

Üye olmayanlar kodu şuradan indirebilirler (aslına sadık kalmak için içindeki saçma sapan açıklamaları silmiyorum)
http://www.ceviz.net/ceviz_main/uploads/uye7346/xmlhttp.zip

var xmlhttp = new_xmlhttp();/**alacaklı haciz koymuş bekire of offf*/

Bu kod xmlhttp nesnesini kurar. Nesne öncelikle Msxml2.xmlhttp ve microsoft.xmlhttp nesnelerine kurulmaya çalışır, eğer kullanıcı ie çalışmıyorsa bu kısımları atlayıp en sondaki XMLHttpRequest oluşturulup bu nesneye atanacaktır.

xmlhttp.open("POST","post.asp",true);

Geriye hangi nesne dönerse dönsün bu nesnelerin gerçekleştirdiği arayüz aynıdır. Aynı metot ve özelliklere sahiptirler. Bu satırda kullandığımız metot, "open" ve ilk parametresinde o nesne vasıtasıyla çağıracağımız dosyayı hangi fiil ile çağıracağımızı belirtiyoruz. Bu örnekte POST kullandık, asp de POST un karşılığı post ile gönderilen verilerin alış şekli Request.Form ile olmaktadır, eğer GET kullansaydık, Request.QueryString ile alacaktık. İkinci parametre yanıt döndürecek olan sayfanın ismidir.

Üçüncü parametre bu nesneyi kullanış biçimimizin asenkron (eş zamanlı olmayan) olup olmayacağını belirler. Ne işe yarar eşzamanlılık? Eş zamanlı olmayan kod, bir çeşit thread gibi, değişik bir kapsamda çalışır ve event tetikler (işini bitirdiği zaman) ama eş zamanlı kod, yanıt döndürene kadar scriptin çalışmasını bekletir ve scriptin donmuş hissi vermesine yol açar.

(Asynchronous javascript and xml) deki A harfine karşılık gelir, anlayacağınız ajax ın a sıdır :-)

Neyse konuya dönelim, aradaki iki satırı atlayıp dikkatinizi

xmlhttp.onreadystatechange

Satırına çekmek istiyorum bu bir olay tutacağımı desem olay yönetici mi desem, ingilizcede "event handler" denilen nesnedir işte. Asenkron olan xmlhttprequest nesnesi her durum değiştirdiğinde (siz onu yolladıktan sonra dökümandan dönen yanıta göre status bayrağı değişir. 200 kodu OK anlamında olduğundan yanıtın döndüğünü anlayıp, işlemlerimizi yapıyoruz.

Kaynakça :

Tags:

Month List

Visitors

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in  anyway.

--

Bu sitede yazılı olanlar kendi kişisel görüşlerimdir işverenlerimi ve benimle birlikte çalışanları temsil etmemektedir.