PHP Long Polling Örneği

Web ve mobil uygulamaların son zamanlardaki olmazsa olmazlarından birisi de bize olayları bildirimler ile iletmesi. Uygulamalar gelen mesajları, beğenileri vs. sayfanın bir yerinde bizim başka bir sayfaya gitmemize gerek kalmadan bize iletiyorlar. Ben de üzerinde çalıştığım bir uygulama+web sayfasında bildirimleri gösterme ihtiyacı hissettim. İlk etapta bunu web socketler ile yapmaya karar verdim. İlk denemem de gayet güzel bir şekilde çalıştı ama bir de mobil uygulama üzerinde denemeye karar verdiğimde hayal kırıklığına uğradım çünkü android WebView’de web socketler desteklenmiyordu. Bu nedenle daha az verimli, daha sorunlu ama yapması gereken işi platform ayırt etmeden yapan eski yöntem long polling ile yapmaya karar verdim. Belki ihtiyacı olanlar olabilir düşüncesiyle burada bir küçük örneğini paylaşmaya karar verdim, temel mantığı göstermekte faydalı olacaktır.  Öncelikle değişiklik olup olmadığını takip eden php dosyamızı yazalım.

polling.php

Bu dosyada öncelikle değişiklikleri takip edilecek kullanıcının idsini alıp, eğer bu idli bir dosya yoksa bir text dosyası oluşturuyoruz.  Daha sonra bir while loop’u içerisinde oluşturulan dosyanın tarihi, while’dan önce alınan tarihten büyük mü diye bakıyoruz. Eğer büyükse dosya güncellenmiştir, dosya güncellemesini ilgili kişiye yapılan işlemlerden önce yapıyoruz. Bir sonraki ekleyeceğimiz dosyada yapılan iş. Eğer bu koşulu sağlıyorsa, while döngüsünden çıkmak için değişkenimize false atıyoruz ve sonrasında veritabanından ilgili sorguları çekiyoruz. Ve bunlarsı json olarak dönüyoruz.

islem.php

Kodumuzun bu kısmı ise kişileri mesaj attığımızda, beğeni gönderdiğimizde vs çalışacak olan veritabanı kodlarının bulunduğu kısım. Burada veritabanı işlemlerinden hemen önce alıcının idsi ile bulunan dosyaya tarih bilgisini atıyoruz ki dosyanın tarihi güncellensin ve az önce yazdığımız while döngüsündeki koşulu sağlasın.

Son olarak da client sayfamızı yazalım.

client.html

Burada öncelikle sayfamız ilk yüklediğinde ajax ile startPolling fonksiyonumuzu çağırıyoruz. gonderenId değişkeni login olan kullanıcıyı, aliciId de mesaj attığımız vs. kullanıcıyı gösterecek. Burada aynı olma sebebi test edebilme amaçlı. Eğer long polling başarı ile tamamlanırsa, yani bir bildirim gelmişse bildirim divlerimizi güncelliyoruz. Sonrasında tekrar startPolling fonksiyonumuzu çağırıyoruz ki dinlemeye devam edebilelim. İşte hepsi bu kadar. İlgili dosyaları lokalinizde oluşturup, kendiniz de deneyebilirsiniz. Jquery dosyasını da aynı dizine koymayı unutmayın.

Bugünlük bu kadar, Çevik Kalın 🙂

NUnit System.ArgumentException (w/ Entity Framework)

 

Entity Framework ile veritabanı işlemlerinizi yaptığınız projelerinizi NUnit ile test etmeye kalktığınızda aşağıdaki gibi bir hata alacaksınız.

System.ArgumentException: The specified named connection is either not found in the configuration, not intended to be used with the EntityClient provider, or not valid.

Bu hatadan kurtulmak için bağlantı bilgilerinizin yer aldığı App.config dosyasını NUnit projeniz ile aynı yere kopyalayıp ismini NUnitProjenizinIsmi.config şekilde değiştirmeniz yeterli.

 

Composition ile Aggregation Arasındaki Fark

Uygulama geliştirirken OOP prensiplerine yaklaştıkça nesneler arasındaki ilişkilerin önemi de gitgide artıyor.  Ben de tasarım desenlerine verdiğim kısa arada çok karıştırılan iki kavramdan bahsetmek istiyorum. Nesneler arasındaki iki ilişki türü : Aggregation, Association

Aggregation : Bu tür ilişki de nesnelerin yaşam döngüleri birbirlerinden ayrıdır. Bir nesne diğerinden bağımsız olarak da yaşamını sürdürebilir. Yani aralarında bir sahiplik ilişkisi (has-a ) vardır. Örneğin Dizüstü Bilgisayarınız ile onun çantası arasında böyle bir ilişki vardır. Çantayı ayrı olarak ya da laptop’u ayrı olarak düşünebiliriz. Yaşam döngüleri ortak değildir. UML diagramında gösterimi ve koda dökülmüş bir örneği aşağıdaki gibidir.

public class Canta
{

}
public class Laptop {
private Canta _canta;
public Laptop(Canta canta)
{
_canta = canta;
}
}

Composition : Bu tür ilişki de nesnelerin yaşam döngüleri birbirleriyle bağlantılıdır. Bir nesne diğerinden bağımsız olarak kullanılamaz. Aralarındaki ilişki parçası olma(is-a-part-of ) ilişkisidir. Az önceki örneğimizden gidersek dizüstü bilgisayarımız ile ekranı arasında bu tarz bir ilişki vardır. UML diagramında gösterimi ve koda dökülmüş bir örneği aşağıdaki gibidir.

public class Ekran
{

}
public class Laptop
{

Ekran _ekran = new Ekran();
}

Observer Design Pattern

Şu aralar daha önceden üzerinden geçtiğim tasarım desenleri ile uğraşıyorum tekrar. Ama bu sefer biraz daha pratik şekilde ilerlemeye çalışıyorum. İlerdikçe de burada hem bana ilerde hatırlamam için not olması hem de ihtiyacı olanların faydalanması için paylaşmaya çalışıyorum.

Son yazımda Strateji tasarım deseninden bahsetmiştim. Bu kez ise Observer tasarım deseninden bahsetmeye çalışacağım. Örneğin bir alışveriş sitesinin kampanyalarından haberdar olmak için maillist’ine kayıt olduğunuzu düşünün, daha sonra bir başkasının da aynı listeye abone olduğunu düşünelim. Bir kampanya olduğunda siteden abone olan herkese bu kampanya gönderilir.  Daha sonradan artık kampanya bilgilerini almak istemezseniz listeden çıkarsınız ve artık yeni kampanya bilgileri diğer abonelere gönderilir.

Observer tasarım deseni de uygulamalarımızdaki bu tarz işlemlerimizi yapmamızı kolaylaştıran bir desendir. Örneğin bir nesnenin durumu değiştiğinde uyarılacak nesneler listesine eklenmiş nesnelerimiz otomatik olarak uyarılır.

Bu desen ile ilgili örneğimi bir önceki strateji deseni örneğim üzerinden yapacağım. Böyle olması biraz daha karışık olmasına sebep oldu ama ezbere kaçmayı önlememi sağladı. Ayrıca iki deseni bir örnek de birleştirmiş oldum. Öncelikle eklememiz gereken yeni arayüz ve sınıfları vereceğim, daha sonra değişiklik yapmamız gereken kısımlardan bahsedeceğim.

İlk olarak biri yayıncı(subject) biri de dinleyici (subscriber,observer) olmak üzere iki interface tanımlayacağım. Daha sonra kullanacağım bütün dinleyici ve yayıncı sınıfları bu sınıflardan türeteceğim.

public interface IYayinci
{
void dinleyiciKaydet(IDinleyici dinleyici);
void dinleyiciCikar(IDinleyici dinleyici);
void dinleyicileriUyar();
}
public interface IDinleyici
{
void guncelle(ArrayList args);
}

Burada IYayinci arayüzümüzde üç adet metodumuz var bunlar uyarılacak nesneleri eklememizi, çıkarmamızı ve nesnenin durumu değiştiğinde listemizdeki nesnelerin uyarılmasını sağlıyor. IDinleyici arayüzündeki metodumuz ise durum değişikliği olduğunda yapılması gereken işlemleri içeren metoddur.

İkinci olarak yayıncı sınıfımızı oluşturuyoruz. Bu sınıfımızda arayüzden aldığı metodları implemente ediyoruz. Ayrıca ben bir adet renkDegisti metodu ekledim ki bu metodu da renk değişimi olduğunda kullanacağız.

public class RenkYayinci : IYayinci
{
ArrayList _dinleyiciler;
ArrayList _args;
public RenkYayinci()
{
_dinleyiciler = new ArrayList();
_args = new ArrayList();
}
public void dinleyiciKaydet(IDinleyici dinleyici)
{
_dinleyiciler.Add(dinleyici);
}
public void dinleyiciCikar(IDinleyici dinleyici)
{
int i = _dinleyiciler.IndexOf(dinleyici);
if (i >= 0)
{
_dinleyiciler.RemoveAt(i);
}
}
public void dinleyicileriUyar()
{
for (int i = 0; i < _dinleyiciler.Count; i++)
{
IDinleyici dinleyici = (IDinleyici)_dinleyiciler[i];
dinleyici.guncelle(_args);
}
}
public void renkDegisti(string renk)
{
_args.Clear();
_args.Add(renk);
dinleyicileriUyar();
}
}

Burada renkDegisti metoduna renk değişkenini almama rağmen bunu arraylist’e atma sebebim IDinleyici arayüzünün sadece renk için özelleşmesini engellemek ve daha sonra da kullanmak istememdir. Daha sonra dinleyicileriUyar() metodunu çağırıyoruz ve bütün ekli nesneleri haberdar ediyoruz.

Artık eski sınıflarımızda değişiklik yapmaya başlayabiliriz. Öncelikle Daire ve Kare Sınıflarımızı aşağıdaki şekle getiriyoruz.

public class Kare : Sekil, IDinleyici
{
private RenkYayinci _renkYayinci;
public Kare(Dictionary<string, int> degerler, RenkYayinci renkYayinci)
{
_cevre = new KareCevre();
_degerler = degerler;
this._renkYayinci = renkYayinci;
this._renkYayinci.dinleyiciKaydet(this);
}
public void guncelle(ArrayList args)
{
Console.WriteLine(“\nKare kenar renkler değişti ” + args[0].ToString());
}
}

 

public class Daire : Sekil, IDinleyici
{
private RenkYayinci _renkYayinci;
public Daire(Dictionary<string, int> degerler, RenkYayinci renkYayinci)
{
_cevre = new DaireCevre();
_degerler = degerler;
this._renkYayinci = renkYayinci;
this._renkYayinci.dinleyiciKaydet(this);
}
public void guncelle(ArrayList args)
{
Console.WriteLine(“\nDaire çember içi renkler değişti” + args[0].ToString());
}
}

Sınıf tanımlamalarımızda koyu ile işaretli yerleri değiştiriyoruz. Burada öncelikle constructor metodumuzda parametre olarak aldığımız yayıncıya nesnemizi ekliyoruz. Daha sonra dinleyici arayüzünden alınan guncelle metodunu implemente ediyoruz.

Artık desenimizi deneyebiliriz. Önceki yazımızda bulunan örnekteki main metodunu aşağıdaki şekilde değiştiriyoruz.

static void Main(string[] args)
{
Dictionary<string, int> dd = new Dictionary<string, int>();
dd.Add(“BirKenar”, 4);
RenkYayinci renkYayinci = new RenkYayinci();
Sekil sk = new Kare(dd, renkYayinci);
renkYayinci.renkDegisti(“mavi”);
Console.WriteLine(sk.cevreHesapla(dd).ToString());
Console.ReadLine();
}

Programımızı derleyip çalıştırdığımızda karşımızda

Kare kenar renkler değişti mavi

16

çıktısını görebiliriz.

Strategy Design Pattern

Strateji tasarım deseni geliştirdiğimiz uygulama içinde algoritmaları sınıflandırmamızı ve çalışma anında kullanacağımız algoritmayı seçmemizi sağlar. Bu algoritmalar kendi içinde kapsüllenerek (encapsulate) programın geri kalanından soyutlanır ve uygulamamızın loosely coupled bir yapıda olmasına yardım eder. Örneğin bir maliyet hesabında LIFO mu yoksa FIFO mu kullanacağımızı çalışma anında belirlemek istiyorsak strateji tasarım desenini kullanarak bunu nesne yönelimli programlama ilkeleri doğrultusunda yapabiliriz.

Algoritmaların seçim işlemini if else blogları ile yapabilirdik. Ancak küçük bir değişiklikte uygulamamızın içine müdahale etmek zorunda kalırdık. Ayrıca yeni algoritmalar ekledikçe bu if else bloglarımız gittikçe uzayacaktı. Ya da işlemi kalıtım yolu ile de gerçekleştirebilirdik. Bir metodu üst bir sınıfta tanımlayıp, alt sınıflarda bu metodu override edebilirdik. Ancak bu durumda da bir değişiklik durumunda bütün alt sınıflarda kodu tekrar düzenlememiz gerekecekti. Ya da eklediğimiz her yeni sınıf için yeniden metodu override etmemiz gerekecekti. Bu durumda kodların yeniden kullanılabilirliği konusunda başarısız olacaktık.

Bu deseni nasıl uygulayabileceğimizi bir örnekle daha iyi gösterebiliriz. Ben nesne yönelimli programlama ile ilgili örnekler verirken daha anlaşılır ve daha uygulanabilir olması nedeniyle mümkün olduğunca şekiller üzerinden gitmeyi tercih ediyorum. Yine vereceğim bu örnekte Strateji tasarım desenini kullanarak Şekil sınıfından türeyen daire ve kare sınıflarının çevrelerini hesaplayan basit bir uygulama yazacağım.

Öncelikle çevre hesaplama algoritmalarını bir araya toplamam gerekiyor. Kapsülleme işlemini gerçekleştirmek ve çevre hesaplama algoritmalarını belli bir formatta tutmak için öncelikle bir interface yazıyorum.

public interface ICevre
{
int hesapla(Dictionary<string, int> degerler);
}

Bundan sonra çevre hesaplama algoritmalarımı tutacak bütün sınıfları bu interface’den türeteceğim. Bu interface’imiz bir adet hesapla metodu içeriyor. Interface’imizden sonra ise çevre hesaplayacak sınıflarımızı oluşturacağız.

public class DaireCevre : ICevre
{
private int cevresi = 0;
public int hesapla(Dictionary<string, int> degerler)
{
cevresi = 2*degerler[“Pi”]*degerler[“r”];
return cevresi;
}
}

DaireCevre sınıfımız ICevre interface’inden aldığı hesapla metodunu implemente ediyor. Aynı şekilde KareCevre sınıfını da yazıyoruz. Bu sınıf da kendine özgü algoritmasıyla çevre hesaplamasını yapıyor.

public class KareCevre : ICevre
{
private int cevresi = 0;
public int hesapla(Dictionary<string, int> degerler)
{
cevresi = degerler[“BirKenar”]*4;
return cevresi;
}
}

Artık çevre ile ilgili hesaplamalarımızı yaptığımıza göre kullanacağımız sınıfları yazmaya geçebiliriz. İlk olarak şekillerimi türeteceğim bir Sekil sınıfı yazıyorum.

public class Sekil
{
public ICevre _cevre;
public Dictionary<string, int> _degerler;

public int cevreHesapla(Dictionary<string, int> degerler)
{
return _cevre.hesapla(degerler);
}
}

Bu sınıfımızda bütün algoritma sınıflarımızı kapsayabilmesi için bir adet ICevre interface’i nesnesi oluşturuyoruz. Böylece loosely coupled özelliğini de sağlamış oluyoruz. Yeni ekleyeceğimiz, çıkaracağımız ya da değiştireceğimiz algoritmalar uygulamanın geri kalanını etkilemiyor. Ayrıca parametreler için bir adet Dictionary nesnesi tanımladım. Burada gördüğümüz cevreHesapla metodu bizim dışarıdan erişeceğimiz ve hesaplama işlemlerini yaptıracağımız metod. Kendi içinde hangi şeklinde çevresi hesaplanacak ise ona ait metodu çağırıyor.

Artık kullanacağımız sınıfları yazabiliriz.

public class Kare : Sekil
{
public Kare(Dictionary<string, int> degerler)
{
_cevre = new KareCevre();
_degerler = degerler;
}
}

public class Daire : Sekil
{
public Daire(Dictionary<string, int> degerler)
{
_cevre = new DaireCevre();
_degerler = degerler;
}
}

Bu sınıflarımız da constructor metod çağrıldığında ICevre türünden olan nesnemize ilgili cevre sınıfı nesnesi(DaireCevre, KAreCevre) oluşturularak atanıyor. Böylece doğru hesapla fonksiyonunun çağrılması sağlanıyor.

Son olarak uygulamamızı deneyeceğimiz kısmı yazabiliriz.

static void Main(string[] args)
{
Dictionary<string,int> dd = new Dictionary<string,int>();
dd.Add(“BirKenar”,4);
Sekil sk = new Kare(dd);
Console.WriteLine(sk.cevreHesapla(dd).ToString());
Console.ReadLine();
}

Böyle bir denemede ekrana 16 yazacaktır.

EnableViewState vs ViewStateMode

Geliştirdiğimiz ASP.NET uygulamalarında durum yönetimini ihtiyaçlarımıza göre birçok şekilde yapabiliriz. Bu seçeneklerden bir tanesi de ViewState yapısıdır. Hepimiz uygulamalarımızda bilinçli ya da bilinçsiz ViewState’leri kullanmışızdır. Bu bizi geleneksel asp ve php’deki kontrollerin durumunu korumak için yaptığımız ekstra işlerden kurtarır.

Ama ViewState’ler her zaman göründüğü kadar masum olamayabiliyor. Bazen ViewState’ler inanılmaz ölçülerde büyüyebiliyor ve bu durumda sayfa yükleme zamanlarınız farkedilir ölçüde artabiliyor. Bu yüzden ASP.NET uygulamalarımızda mümkün olduğunca durumunun tutulması gerekli olmayan kontrollerin ViewState’lerini kapatmamız gerekir.

Bu işlemi ASP.NET 4.0’dan önce EnableViewState özelliği ile yapıyorduk.  Böylece durumu tutulmasını istemediğimiz kontrollerin bu özelliğini false yaparak bu sorundan kurtulabiliyorduk. Ama EnableViewState’lerde tasarımı ile ilgili bir bug vardı. Eğer sayfamızda 100 kontrol içinden sadece 10 tanesinin durumunu tutmak istiyorsak, sayfamızın EnableViewState özelliğini false yapıp sadece bu 10 kontrolün özelliğini true yapmamız yeterli olmalıydı ama olmuyordu. Bu işlemi ancak sayfanın EnableViewState özelliğini true yapıp 90 kontrolün özelliklerini false yaparak sağlayabiliyorduk. Bunun da oluşturacağı zaman ve iş kaybını tahmin edebilirsiniz.

Ancak ASP.NET 4.0 ile gelen ViewStateMode özelliğini bizi bu sıkıntıdan kurtarmaktadır. Bu özellik parent kontrolün durumuna bakmaksızın kontrollerin durumlarını tutup tutmamamızı belirlememizi sağlar. ViewStateMode durumunu üç şekilde belirleyebiliriz.

  1. Inherit : Bu durumda kontrol parent kontrolün aynı şekilde davranacaktır.
  2. Enabled : Bu durumda parent kontrolün değeri disabled olsa bile kontrolün durum bilgileri tutulacaktır.
  3. Disabled : Bu durumda ise parent kontrolün durumu enabled olsa bile kontrolün durum bilgileri tutulmayacaktır.

NOT: TextBox,CheckBox ve RadioButton kontrollerinde EnableViewState özelliğini false yapsanız bile bu kontroller bazı durumlarını tutmaya devam etmektedir. İlgili bilgiyi buradan bulabilirsiniz.

 

Regular Expressions – Lookaround

Önceki gönderimde bahsettiğim gibi bu aralar ciddi anlamda kafayı regular expression’larla bozmuş durumdayım. Ne kadar yetenekli olduklarını gördükçe daha da ayrıntısına girmeye başladım. Ama artık bu ifadelerle boğulmak üzere olduğumu farkedince durmam gerektiğini hissettim. Ama durmadan önce de sizlere yararlı olabileceğini düşündüğüm birşeylerden bahsetmek istiyorum.

Lookaround’a isminden de anlaşılacağı üzere özetle bir regular expression’ın öncesi ya da sonrasını da kontrol etmemizi sağlayan yapı diyebiliriz. Vereceğimiz örnekle kafanızda daha net şekilde canlanacaktır. 2 çeşit lookaround’dan bahsedebiliriz. Bunlar Lookahead ve Lookbehind.

Lookahead :

Lookahead verilen regular expression’dan sonra neyin gelmesini ya da gelmemesini belirlemek istediğimizde kullandığımız yapıdır.  Örneğin input string’imiz “Kara Kartal Karşınızda” olsun. Ben bu string içinde Kar kelimesini aramak istiyorum ama bu Kar kelimesinden sonra a harfi gelmesini istemiyorum. Bu durumda kullanacağım regular expression

Kar(?!a)

şeklinde olacak. Bu şekilde kurduğumuz yapıya negatif  lookahead diyoruz. Negatif lookahead yapısını ?! karakterleriyle oluşturuyoruz ve sonra a harfi gelmemesini istediğimizi belirtiyoruz. a harfi yerine başka bir regular expression’da kullanabilirdik. Örneğimizde gerçekleşecek olan eşleşmeler Kartal’daki ve Karşınızda’daki Kar kelimeleridir.

Bu örneğimiz negatif lookahead olduğuna göre bunun bir de pozitifi olması gerekir. Pozitif lookahead’de ise sonrasında ne gelmesini istediğimizi belirtiyoruz. Bunu ise ?= karakterleri ile yapıyoruz. Önceki input’umuzda bu kez aşağıdaki regular expression’ı kullanalım.

Kar(?=a)

Bu durumda sadece Kara kelimesindeki Kar kısmını eşleyecektir.

Lookbehind :

Lookbehind, lookaround ile aynı mantıkta olmakla beraber bu kez verdiğimiz yapının  öncesinde ne olup olmamasını belirlememize yardım eder.

Bu kez input string’imiz “Kandırdım Sandım” olsun. İlk olarak negatif lookbehind yapalım. Negatif lookbehind yapmak için ?<! karakterlerini kullanırız. Regular expression’ımızı aşağıdaki şekilde düzenleyelim.

(?<!K)an

Bu durumda sadece Sandım kelimesindeki an eşleşecektir. Aynı şekilde pozitif lookahead yapmak için ?<= karakterlerini kullanırız. Bu kez aynı input için regular expression’ımızı aşağıdaki şekilde belirleyelim.

(?<=K)an

Bu durumda ise sadece Kandırdım kelimesindeki an regular expression’ımız ile eşleşecektir.

Bundan sonraki yazılarımda Groups ve Balancing Groups konularından bahsetmeyi planlıyorum. Bu ve diğer konularda sorularınız varsa yorum kısmından elimden geldiğince yardımcı olmaya çalışırım. Şimdilik bol kodlu günler.

ASP.NET Güvenlik Açığı

Geçtiğimiz günler içinde bir konferans sırasında çok ciddi bir güvenlik açığı ortaya çıkarıldı. Ayrıca daha Microsoft bir reaksiyon almadan, bu konferans sırasında açığı kullanan bir demo bile yapıldı. Bu demoya ait videoyu da internette rahatlıkla bulabilirsiniz. Bu açık bütün ASP.NET sürümlerini etkiliyor. Microsoft bu sorunla ilgili olarak bir güvenlik önerisi yayınladı.

Bu açık kullanılarak saldırgan ASP.NET uygulamanızdaki dosyaları indirebilir ya da şifrelenmiş olarak gönderilen bilgileri çözebilir. Saldırı ASP.NET’in gönderdiği hata mesajları aracılığıyla yapılıyor. Saldırgan şifrelenmiş bir text’i server’a göndererek çok sayıda istek gönderiyor. Ve bu sorgular sonucunda dönen hata mesajlarını kontrol ederek bu şifrelenmiş text’i çözebiliyor.

Şu an Microsoft’un önerdiği çözüm CustomErrors’ı açmanız ve bütün hataları tek bir hata mesajı sayfasından göstermeniz. Böylece saldırgan hata mesajları üzerinden çıkarım yapamayacak. Ayrıca bu hata sayfası gösterimi sırasında da bir delay yapılması tavsiye ediliyor.

DevExpress ClientSideEvents FireFox Problemi

DevExpress kontrollerinin client side event’lerinde bir javascript fonksiyonu çağırıyorsak Internet Explorer için bu işlemi aşağıdaki gibi yapabiliriz.

<ClientSideEvents KeyDown=”foo()” />

Ancak bu kodun bulunduğu sayfayı Firefox ile  açmaya çalıştığımızda foo fonksiyonunun tanımlanmadığına dair hata verecektir. Bu sorunu aşmak için fonksiyonu aşağıdaki gibi DevExpress’in normal söz dizimi içinde vermeniz yeterli olacaktır.

 <ClientSideEvents KeyDown=”functions (s, e) {

foo();

}” />

DevExpress Kontrolleri SetEnabled Sorunu

DevExpress kontrollerini kullanırken eğer server tarafında yazdığınız kodda Enabled property’sini kullandıysanız. Örneğin

ASPxTextBox1.Enabled=true;

gibi, Client Side Eventler ‘de kontrolün enablad özelliğini değiştirmek istediğiniz de (SetEnabled fonksiyonu ile)  beklediğinizden farklı ve hatalı sonuçlarla karşılaşırsınız. Buna engel olmak için eğer bir kontrolün enabled özelliğini client side’da değiştireceksek ve server side’da da bu özelliğe müdahale etmemiz gerekiyorsa Enabled yerine ClientEnabled property’sini kullanmalıyız.