C#, Yeni Bir Soluk
Microsoft ''un Visual Studio.NET paketi ve .NET Framework teknolojisi ile
birlikte sunumunu yaptığı yeni programlama dili C# (Si şarp), çok
bilinmeyenli denklem görünümünden dolayı bu yeni teknolojinin en çok ilgi çeken
kısımlarından birisi oldu. Dile kolay; yepyeni bir programlama dilinden
bahsediyoruz. İsmiyle, sözdizimiyle ve genel yapısıyla C/C++ ''tan türetilmiş
olan C# atalarından daha modern olmakla kalmayıp daha yenilikçi olmayı ihmal
etmiyor. Tamamıyla nesne yönelimli..
Kullanıcı Kontrollerine Giriş
Bir web sitesini oluşturan sayfalar arasında, ortak kullanılan
kodların, arabirim parçalarının olması kaçınılmazdır. Mesela, site
içinde dolaşımı sağlayan bir menü,
yaygın olarak tüm sayfalarda aynı şekilde görüntülenir. Veya, siteyi
kimliklendiren bir logo da aynı şekilde tüm sayfalarda kullanılmak
istenebilir. Bu gibi durumlarda, her sayfaya tek tek bu kod parçalarını
eklemek en ilkel yol olacaktır. Çünkü bu kısımlarda yapılacak herhangi
bir değişiklik için, sitedeki tüm sayfaların değişmesi gibi zahmetli
bir zorunluluk doğacaktır.
HTML kodlarının arasında SSI (Server Side Includes)
yönergeleri kullanılarak sunucu üzerinde farklı dosyaların kapsanması
sağlanmıştı. Bu yönergeleri içeren dosyalar, statik HTML dosyalarından
farklı olarak
.shtml uzantısıyla saklanıyor. Bu SSI yönergelerinden en çok bilinen ve bizim de konumuz olan yönerge Include. Include yönergesinin yazım şekli şöyle:
| Include Yönergesi Kullanım Şekli | |
|
<!--#INCLUDE FILE="../common/sabitler.inc"-->
<!--#INCLUDE VIRTUAL="/mySite/common/sabitler.inc"--> |
|
Include yönergesinin kullanımını ASP ve ASP.NET de destekliyor. Rahatlıkla kullanabilirsiniz. Ama bu yöntemin bizi kısıtladığı noktalar var:
Include direktifinin, sayfada diğer sunucu taraflı komutlardan önce çalışması.
Programatik olarak bi dosyayı Include yönergesiyle içermenin münkün olmayışı.
Kapsanmak istenen dosyaya parametre göndermenin zor oluşu.
Kapsanan
dosyalara erişimin dosya yolunu yazarak mümkün oluşu. (.asp uzantısı
kullanılmadığı zaman, kaynak kodun görüntülenme riski)
ASP.NET'in getirdiği tüm yenilikler gibi Kullanıcı Kontrolleri
de, Microsoft'un yaşanan sorunlara iyi odaklandığını gösteriyor.
Bahsettiğimiz tüm kısıtlamalar, Kullanıcı Kontrollerinin esnek mekanizması ile ortadan kalkıyor.
Ve İşte Kullanıcı Kontrolleri
Kullanıcı Kontrolleri (User Controls)
.aspx sayfalarında deklare edilip
kullanılmak üzere oluşturulan özel ASP.NET sayfalarıdır. Bir ASP.NET
sayfası kolaylıkla bir kullanıcı kontrolüne dönüştürülebilir. Çünkü tek
fark uzantıları ve varsayılan ön-işlemci yönergesidir.
- Bir web formu sayfası .aspx uzantısıyla, bir kullanıcı kontrolü .ascx uzantısıyla saklanır.
- Bir web formundaki Page ön-işlemci yönergesi, kullanıcı kontollerinde Control olarak kullanılır.
Şimdi basit bir örnekle kullanıcı kontrolleri dünyasına
girelim. Diğer sayfalarda kullanacağımızı varsaydığımız bir menu
kontrolü yapacağız. Kontrolü
menu.ascx adında bir dosya olarak kaydediyoruz.
| menu.ascx | |
|
<a href="sayfa1.aspx">Sayfa1</a> |
<a href="sayfa2.aspx">Sayfa2</a> | <a href="sayfa3.aspx">Sayfa3</a> |
|
Evet, bu kadar basit. Bu kontrolümüzde basitlik için sadece statik HTML içeriği kullandık. Şimdi bunu bir
.aspx sayfasına nasıl katacağımızı görelim:
| sayfa.aspx | |
|
<%@ Register TagPrefix="Sitemiz" TagName="IlkKontrolumuz" Src="menu.ascx" %>
<html> |
|
Kullanıcı kontrolünü sayfamızda kullanabilmek için ilk satırda,
Register ön-işlemci yönergesiyle kontrolün yolunu ve sayfada diğer etiketlerden ayrılmasını sağlayan
TagPrefix ve
TagName özelliklerini belirtiyoruz.
- Src özelliğinde .ascx uzantılı kullanıcı kontrol dosyasının bağıl veya kesin yolunu yazıyoruz.
- TagPrefix ve TagName
özelliği kontrolümüz için ayırıcı bir etiket tanımlamamızı sağlıyor.
Kontrolümüz sayfa içerisinde deklare ederken etiket isminde bu iki
özelliği ( TagPrefix:TagName ) kullanıyoruz. TagPrefix kontrol
için bir ad uzayı (namespace) oluşturmamızı sağlıyor. Bu önek, farklı
kontrolleri farklı uzaylar içerisinde aynı TagName özelliği ile
tanımlamamızı mümkün kılıyor. Unutmamak gerek ki, TagPrefix:TagName
ikilisi, bir sayfada sadece bir kontrol için kayıt edilebilir. İkinci
bir kontrol için aynı ikiliyi kayıt etmeye çalışırsanız, Parser Error
alırsınız.
Kontrolümüzü kayıt etmek, ilk adımdı. Kayıt edilmiş
kontrolümüzden bir örneği sayfa içerisine yerleştirmek için aşağıdaki
bildirimi kullandık:
|
<Sitemiz:IlkKontrolumuz ID="ilkKontrol" Runat="Server"/>
|
- Etiket tanımında, yukarıda kayıt ederken belirttiğimiz TagPrefix:TagName ikilisini kullandığımıza dikkat edin.
- ID niteliğini kullanmayabilirsiniz. Ancak programatik olarak erişebilmek için belirtmelisiniz.
- Runat="Server" ise sihirli bir ifade. Tüm sunu taraflı
kontrollerde olmak zorunda. Bu özelliği belirtmezseniz, ASP.NET, bu
etikete statik HTML muamelesi yapacaktır.
Yukarıda ilk kullanıcı kontrolümüzü oluşturduk. Ama farkındaysanız, aynı işi
Include yönergesi ile yapabilirdik.
Çünkü hiç bir parametreye göre şekillenmeyen, sadece statik HTML metni
içeren bir kontrol yazdık. Ancak şimdi dışarıdan özelliklerine
erişebileceğimiz bir kontrol yazacağız. Herşeyden önce, bir kullanıcı
kontrolünün de özel bir ASP.NET sayfası olduğunu unutmamalıyız. Aynı
şekilde sunucu taraflı kod bloğu oluşturup, aynı şekilde fonksiyonlar,
özellikler ve sınıflar tanımlayabiliriz.
| kontrol2.ascx | |
|
<%@ Control Language="VB" %>
<Script Runat="Server"> Public Metin As String = "Varsayılan Metin" Public ArkaPlanRengi As String = "#33CCFF" Public FontBoyutu As String = "15" </Script> <div Style="Background-Color: <%= ArkaPlanRengi %>; Font-Size: <%= FontBoyutu %>px"><%= Metin %></div> |
|
kontrol2.ascx, üç tane
Public alan tanımlıyoruz. Kontrolü
içereceğimiz sayfadan bu özelliklere erişebilmemiz için onları Public
erişimli kılmalıyız. Bu özellikleri kullanarak aşağıda deklare
ettiğimiz
Div etiketinin style özelliğini ve göstereceği metni belirleyeceğiz. Ayrıca değişkenlere ilk değerler verildiğine de dikkat edin.
Şimdi bu kontrolü kullanan bir istemci sayfa yazalım. Kontrolümüzü
sayfa içerisinde iki kere kullanacağız. İlkinde hiç değer atamadan,
ikincisinde ise üç özelliğe de değer atayarak...
| sayfa2.aspx | |
|
<%@ Register TagPrefix="Sitemiz" TagName="Kontrol2" Src="kontrol2.ascx" %>
<html> <title>.</title> <body> <Sitemiz:Kontrol2 ID="kontrol1" Runat="Server"/> <br> <Sitemiz:Kontrol2 ArkaPlanRengi="yellow" FontBoyutu="19" Metin="Yeni Metin" ID="kontrol2" Runat="Server"/> </body> </html> |
|
Kullanıcı kontrolünün özelliklerine, onları tanımladığımız
etiketin nitelikleriymiş gibi ulaşabildiğimizi görüyorsunuz. Ancak bir
alternatif yol daha var: Programatik olarak ulaşmak. Yukarıdaki sayfayı yeniden yazalım:
| sayfa2.aspx | |
|
<%@ Register TagPrefix="Sitemiz" TagName="Kontrol2" Src="kontrol2.ascx" %>
<Script Runat="Server"> Sub Page_Load (s As Object, E As EventArgs) kontrol2.ArkaPlanRengi = "yellow" kontrol2.FontBoyutu = "19" kontrol2.Metin = "Yeni Metin" End Sub </Script> <html> <title>.</title> <body> <Sitemiz:Kontrol2 ID="kontrol1" Runat="Server"/> <br> <Sitemiz:Kontrol2 ID="kontrol2" Runat="Server"/> </body> </html> |
|
Yukarıdaki kodla da aynı sonucu elde edeceğiz. Burdaki fark, kontrole
özelliklerinin deklaratif olarak bildirilmesi yerine, sayfanın kod
bloğunda programatik olarak belirlenmesi. Kontrolü deklare ederken
verdiğimiz
ID özelliğini, ona kod bloğundan ulaşmak için nesne adı olarak kullandığımıza da dikkat edin.
Son olarak da bir kullanıcı kontrolünü çalışma zamanında (runtime)
nasıl ekleyebileceğimizi görelim. Aşağıdaki sayfamız, yine
kontrol2.ascx i kullanacak. Ama kontrolün sayfaya dahil edilmesi kod
bloğunda, LoadControl() metodu ile gerçekleşiyor. Parametre olarak
.ascx dosyanın yolunu veriyoruz. Kontrolü sayfada istediğimiz noktaya
yerleştirebilmek için bir yer tutucu kontrol kullanıyoruz.
| sayfa3.aspx | |
|
<Script Runat="Server">
Sub Page_Load (s As Object, E As EventArgs) Dim uCtrl As UserControl uCtrl= LoadControl( "kontrol2.ascx" ) YerTutucu.Controls.Add( uCtrl ) End Sub </Script> <html> <title>.</title> <body> <asp:PlaceHolder ID="YerTutucu" Runat="Server" /> </body> </html> |
|
Ve görüntü:
Bitirirken
Kullanıcı kontrolleri, ASP.NET'in getirdiği, kolay ve esnek kullanımı
ile göz dolduran bir özellik. Çok sık kullanılacak parçaları bir kez
yazarak tüm sayfalara, bir kontrol deklarasyonu basitliğinde dahil
edebilmenizi sağlıyor. Ve eskide kalan Include yönergesiyle
karşılaştırılamayacak ölçüde güçlü yetenekler sunuyor. En önemli
ayrıntılardan biri de, .ascx uzantılı kullanıcı kontrolleri
tarayıcılardan yolu yazılarak görüntülenemiyor. Yani bir web sayfası
olarak değil, sadece diğer ASP.NET sayfalarına ve kontrollere katılma
izni olan akıllı bir "parça" olarak görev yapıyor.
PostBack Üzerine Notlar
Eskiden web programcıları sahip oldukları araçlarla geliştirdikleri uygulamalara otomasyon kazandırmak için çok çaba sarfederlerdi. Gerçi ASP.NET henüz çok yeni ve birçok kişi için çok yabancı olduğu için bu cümlede geçmiş zaman kullanmak doğru olmayabilir. Ama web programcısının önüne gelen yeni araçların eskiden zor yapılabilen şeyleri "işten bile değil" derecesine getirdiği bir gerçek..
Bazen web uygulamalarında, yapılan seçime göre yeni seçeneklerin gösterilmesi gibi şeylerin yapılması gerekir. Seçilen markanın sahip olduğu modellerin listelenmesi gibi mesela.. Ve bunun yapılabilmesi için genelde hazır javascript kodları kullanılır. Dreamweaver gibi programlar sahip oldukları javascript kütüphanesi ile programcıya yardımcı olmaya çalışır. Bir web tasarımcısı böyle birşeyi yapmaya çalıştığında hem zorlanır hem de kendisini tam bir programcı gibi hisseder.
İlk iki makalemi genel olarak web kontrolleri konusunda yazdım. Verdiğim iki örnekle kontrollerin nasıl kullanılabileceğini gösterdim. Bu makalemde ise ile olarak yukarıda anlattığım işi, yani kendi kendine tetiklenme (spontaneous triggering) işini müthiş kolay hale getiren bir özellikten bahsedeceğim. Bahsi geçecek olan "AutoPostBack" özelliği bizzat ismiyle insana çok şey anlatıyor zaten. Aslına bakarsanız bu özellikde kontroller ile direk olarak alakalı..
Birçok web kontrolü AutoPostBack özelliğinin değeri programcı tarafından "True" olarak belirlenmişse kendilerine has olayların gerçekleşmesiyle hedefteki Sub ''ı tetikleyebilirler. Biraz karışık bir cümle oldu sanırım. Bazı kontrollerin kendilerine has olayları vardır. AutoPostBack özelliği aktif olan kontrolün olayı gerçekleştiğinde otomatik olarak tetiklenirler. İşte buna AutoPostBack denir. Ancak bu özelliği çok fazla kullanmak, server ''a ek yük getirecektir. Çünkü tüm seçimlerde sayfa yeniden yüklenecektir. Bu nedenle AutoPostBack özelliği sadece gerektiğinde kullanılmalıdır. İsterseniz küçük bir örnekle AutoPostBack ''in çalışmasını göstereyim.
| AutoPostBack özelliğine bir bakış.. | |
|
<%@ Page Language="VB" Debug="True"%>
<title> AutoPostBack örneği..</title> <script runat="server" language="vb"> Sub SecimYap(Sender As Object, E As EventArgs) <form runat="server"> |
|
Örnek olarak verdiğim kodda da gördüğünüz gibi ListBox kontrolünün olayı olan OnSelectedIndexChanged gerçekleştiğinde hedef olarak belirlenmiş ve yazılmış SecimYap sub ''ı tetikleniyor. Bu olay Türkçe manasıyla "Seçili index değiştiğinde" oluyor. Kontrol otomatik olarak bir Post Back yapması konusunda direktif aldığından dolayı olayın gerçekleşmesiyle birlikte görevini yerine getiriyor.
İlk makalemde verdiğim dinamik listeler isimli örneği hatırlamanızı istiyorum. O örnekte iki adet ListBox ve iki adet de Button kontrolü kullanmıştık. Seçili elemanı PostBack sonunda diğer listeye atıp zaten içinde olduğu listeden çıkartıyorduk. Ancak konumuzla alakası; bu işi yapmak için kullanıcı önce seçim yapıyor, sonra gerekli butonu tıklıyordu. Butonun OnClick olayında ise gerekli işlemler gerçekleştiriliyordu.
Bu örneği AutoPostBack özelliğini kullanarak geliştirmeye çalışabilirsiniz. Bir ListBox için nasıl AutoPostBack yapabileceğinizi yukarıda verdiğim kod ile gösterdim. Artık iki değil bir adet bile Button kontrolü kullanmamıza gerek yok. Yapmanız gereken; iki ListBox kontrolünün de AutoPostBack özelliğinin değerini "True" yapmak ve butonların hedefleri olan sub ''ları ListBox kontrollerinin OnSelectedIndexChanged olaylarının hedefi yapmak olacaktır.
Böylece kullanıcı herhangi bir listeden seçim yaptığında PostBack oluşacak ve seçili eleman diğer listeye atılacaktır. Dinamik listeler örneğinde, herhangi bir listeden seçim yapılmadan butonlardan birine tıklanırsa veya seçim yapıldığı halde yanlış butona tıklanırsa bir hata mesajı ile karşılaşılıyordu. Bunun nedeni diğer listeye atmak için bir değişkene atanacak olan seçili eleman değerinin boş olmasıydı. Seçim yapılmadığı için veya yanlış butona basıldığında yanlış listeden seçili eleman arandığı için değer bulunamıyordu. Gerek görmediğim için koda bunu engelleyecek bir kontrol deyimi koymamıştım. (Kodu ve örneğin çalışan halini değiştirdim) AutoPostBack özelliği kullanılarak yeniden yazılacak dinamik listeler örneğinde ise seçim yapılması zorunlu hale geleceği için bu hatayla karşılaşılma ihtimali yoktur ve "if" kontrolü koymaya gerek kalmaz.
ASP.NET, HTTP ''nin stateless (durumsuz) olmasının getirdiği büyük handikapı aşmak için değişik mekanizmalar kullanır. Bu şekilde kullanıcıya aynı sayfayı kullandığı hissini verir. Kullanıcı kendisini bir masaüstü programın kolllarında hisseder. Kullanıcı butona tıklar, OnClick olayı server''da çalışır ve yanıt client''e gönderilir. Gerekli bilgiler HTML kodu içerisinde tutulur. Böylece kontrollerin PostBack öncesi değerleri PostBack sonrasına taşınırlar.
Arka planda tonlarca veri taşınmakta ve devam etmekte olan session (ziyaret sezonundan bahsediyorum) ''un selameti için kullanıcıya çaktırmadan client-server arası iletişim devam ettirilmektedir. Böylece client ile server arasındaki "al gülüm, ver gülüm" ilişkisi "al gülüm, vermeni bekliyom gülüm" ilişkisine döner. İki taraf arasındaki bağlantı her ne kadar yine kesiliyor olsa da taraflar birbirlerine karşı vefalıdır ve bir dahaki görüşlerinde selamlaşırlar.
EnableViewState özelliği ise kontrollerde veya direkt olarak @Page direktifi içerisinde kullanılabilir. @Page direktifi içinde kullanıldığında sayfa içerisindeki kontrollerin EnableViewState özelliklerinin değerinin bağlayıcılığı kalmaz ve direktifte ne dendiyse o olur. EnableViewState özelliğinin değeri "False" olarak belirlenmiş bir TextBox kontrolünün değeri PostBack sonrasında korunmaz. Ancak bu "korunmama" işlemi, listedeki seçili elemanın PostBack ''den sonra da seçili olmamasını sağlayamaz. Bilmiyorum tahmin edebildinizmi ama EnableViewState özelliğinin değeri "True" olan bir ListBox ''un elemanlarını page_load içerisinde doldurur ve buna bir "if not IsPostBack" kontrolü koyarsanız, PostBack sonunda liste boşalır. Normalde aynı "if" deyimi nedeniyle tekrar yüklenmemesini sağladığımız elemanlar zaten korunmuş olacaktı.
| ASP.NET motorunun client tarayıcıya gönderdiği HTML koduna eklediği VIEW STATE etiketi.. | |
|
<input type="hidden" name="__VIEWSTATE" value="dDwtNTE4Nzg5ODcwO3Q8O2w8aTwxPjs+O2w8dDw7bDxpPDE+Oz47bDx0PHQ8O3A8bDxpPDA+O2
k8MT47aTwyPjtpPDM+O2k8ND47aTw1Pjs+O2w8cDxpc3RhbmJ1bDtpc3RhbmJ1bD47cDxrb2NhZWxpO2t vY2FlbGk+O3A8YW5rYXJhO2Fua2FyYT47cDxrb255YTtrb255YT47cDxidXJzYTtidXJzYT47cDx0cmFi em9uO3RyYWJ6b24+Oz4+Oz47Oz47Pj47Pj47PtltnU/veMAZkdOEW5h1dao1QoH4" /> |
|
Çalıştırılan .aspx dosyaları işlendikten sonra client tarayıcıya gönderildiğinde yorumlanan kaynak koda bakılırsa ismi "__VIEWSTATE" olan "hidden" bir INPUT etiketi dikkati çekecektir. Sayfadaki kontrol sayısına doğru orantılı olarak bu etiketin değeri uzar.
EnableViewState özelliğini nerelerde kullanabiliriz ? Aslına bakarsanız ben de henüz uygulama geliştirme aşamasına geçmediğim için aklıma pek kullanım alanı gelmedi. Ancak size bu özelliğin nasıl kullanıldığı ve nasıl işlediği hakkında bir fikir verebilmek için basit bir örnek bulmam gerekiyordu. Gerçekten de çok basit birşey buldum ve kısa bir kod verip konuyu daha fazla uzatmayacağım.
| EnableViewState örneği.. | |
|
<%@ Page Language="VB" Debug="True" %>
<script runat="server"> <form runat="server"> |
|
Bu kodda göreceğiniz iki label kontrolünün değeri az önce de bahsettiğim gibi page_load olayı içerisinde ve IsPostBack kontrolünde belirleniyor. btnGonder isimli butonun tek görevi bir PostBack oluşturmak olduğu için OnClick olayına hedef belirtilmiyor. Bu buton tıklandığında EnableViewState değeri "False" olan lblMesaj1 ''in değeri boşalırken lblMesaj2 ''nin değeri korunuyor. Bu arada @Page direktifinde bu konuda hiçbir belirtme yapılmadığına dikkatinizi çekerim.
Peki, sizce @Page direktifine EnableViewState="False" deyimini eklesek nasıl bir tepki alırız ? Tahmin edebileceğiniz gibi label kontrollerinin ikisi de artık değerlerini korumayacaktır. lblMesaj2 ''nin içerisinde "değerini koru" dediğimiz halde.. Aynı durum tersinde de çalışacaktır. Ancak kontrolün değerini IsPostBack kontrolü ile belirlemezseniz istediğiniz kadar yere EnableViewState="False" yazın değeri yok edemezsiniz. Sanırım bu konu için bu kadarı yeter...
Makalenin üçüncü konusu olan "AutoEventWireUp" kelimesinin anlamı için "Otomatik bağla" diyebiliriz. Neyi bağlıyoruz ? Cevap: "Page" ''e ait olayları.. "Page" ''e ait en çok kullandığımız olay "page_load"..
AutoEventWireUp, @Page direktifinin bir niteliğidir. True ve False şeklinde iki değeri vardır. Varsayılan değeri True ''dur. Değerinin True olması durumunda, sayfanın çalıştırılması sırasında Page ''e ait olaylar otomatik olarak tetiklenirler. Yani bağlanırlar.. Bu olaylara ait sub ''ları çağırmaya gerek yoktur. AutoEventWireUp="False" deyimini @Page direktifine yazdığınızda ise bu iki olay işleme konmaz. Ben kod vermeyeceğim ama nasıl deneme yapabileceğinizi söylemek istiyorum.
Script bloğu içerisinde bir page_load sub ''ı oluşturun. Sayfa içerisinde oluşturduğunuz bir label kontrolüne page_load içerisinde değer atayın. Bu kodu önce AutoEventWireUp="True" şeklinde çalıştırın. Label kontrolüne değer atandığını göreceksiniz. Şimdi de AutoEventWireUp="False" yapın ve label kontrolünün değersiz olduğunu görün. Bu özelliğin iki değeri için @Page direktifi ve page_load sub ''ı şu şekilde olacaktır.
|
<%@ Page Language="VB" Debug="True" AutoEventWireUp="False" %>
<script runat="server"> |
|
<%@ Page Language="VB" Debug="True" AutoEventWireUp="True" %>
<script runat="server"> |
Üçüncü makalemi yazdım ve üçünde de temel olarak web kontrollerinin, olayların nasıl kullanılacağını göstermek istedim. Verdiğim örneklerin basit olmasına, kafa karıştırmamasına ve anlatmak istediğimi tam olarak anlatmasına dikkat ettim. Her ne kadar bu örneklerde kullandığım ve böylece tanıştırdığım web kontrolleri bir elin parmaklarını geçmiyor olsa da en azından ampulu yakabildiğimi düşünüyorum. Eminim birçok kişi veritabanı kullanma ile ilgili makalelerin yazılmasını ve yayınlanmasını bekliyor. Ancak ben temel bilgileri vermeden direkt olarak veritabanı gibi daha ayrıntı ve gelişmiş bir konuya girmenin yanlış olacağını düşündüm hep.
Ama şimdi bakıyorum ki web kontrollerinin kullanımı veya kullanışlı özellikleri üzerine daha fazla makale yazmama gerek yok. Sanırım birçoğunuz artık veritabanı konusuna vakıf olacak kadar ASP.NET bilgisi edinmişsinizdir. Bu ne demek oluyor ? En yakın zamanda veritabanı kullanımı ile ilgili makaleler gelecek. Ama bundan sonra yazacağım makalelerde de web kontrolleri hakkında bilgi vereceğim ve satır aralarında onlara değineceğim. Zaten web kontrolleri direkt olarak tasarımı etkilediği için konumuzun ayrılmaz parçası olarak baki kalacak. Gelecek makalelerde tekrar okuşmak üzere...
Sevgi, saygı, ASP.NET...