مطالب
ایجاد «خواص الحاقی»
حتما با متدهای الحاقی یا Extension methods آشنایی دارید؛ میتوان به یک شیء، که حتی منبع آن در دسترس ما نیست، متدی را اضافه کرد. سؤال: در مورد خواص چطور؟ آیا میشود به وهلهای از یک شیء موجود از پیش طراحی شده، یک خاصیت جدید را اضافه کرد؟
احتمالا شاید عنوان کنید که با اشیاء dynamic میتوان چنین کاری را انجام داد. اما سؤال در مورد اشیاء غیر dynamic است.
یا نمونهی دیگر آن Attached Properties در برنامههای مبتنی بر Xaml هستند. میتوان به یک شیء از پیش موجود Xaml، خاصیتی را افزود که البته پیاده سازی آن منحصر است به همان نوع برنامهها.
راه حل پیشنهادی
یک Dictionary را ایجاد کنیم تا ارجاعی از اشیاء، به عنوان کلید، در آن ذخیره شده و سپس key/valueهایی به عنوان value هر شیء، در آن ذخیره شوند. این key/valueها همان خواص و مقادیر آنها خواهند بود. هر چند این راه حل به خوبی کار میکند اما ... مشکل نشتی حافظه دارد.
شیء Dictionary یک ارجاع قوی را از اشیاء، درون خودش نگه داری میکند و تا زمانیکه در حافظه باقی است، سیستم GC مجوز رهاسازی منابع آنها را نخواهد یافت؛ چون عموما این نوع Dictionaryها باید استاتیک تعریف شوند تا طول عمر آنها با طول عمر برنامه یکی گردد. بنابراین اساسا اشیایی که به این نحو قرار است پردازش شوند، هیچگاه dispose نخواهند شد. راه حلی برای این مساله در دات نت 4 به صورت توکار به دات نت فریم ورک اضافه شدهاست؛ به نام ساختار دادهای ConditionalWeakTable.
معرفی ConditionalWeakTable
ConditionalWeakTable جزو ساختارهای دادهای کمتر شناخته شدهی دات نت است. این ساختار داده، اشارهگرهایی را به ارجاعات اشیاء، درون خود ذخیره میکند. بنابراین چون ارجاعاتی قوی را به اشیاء ایجاد نمیکند، مانع عملکرد GC نیز نشده و برنامه در دراز مدت دچار مشکل نشتی حافظه نخواهد شد. هدف اصلی آن ایجاد ارتباطی بین CLR و DLR است. توسط آن میتوان به اشیاء دلخواه، خواصی را افزود. به علاوه طراحی آن به نحوی است که thread safe است و مباحث قفل گذاری بر روی اطلاعات، به صورت توکار در آن پیاده سازی شدهاست. کار DLR فراهم آوردن امکان پیاده سازی زبانهای پویایی مانند Ruby و Python برفراز CLR است. در این نوع زبانها میتوان به وهلههایی از اشیاء موجود، خاصیتهای جدیدی را متصل کرد.
به صورت خلاصه کار ConditionalWeakTable ایجاد نگاشتی است بین وهلههایی از اشیاء CLR (اشیایی غیرپویا) و خواصی که به آنها میتوان به صورت پویا انتساب داد. در کار GC اخلال ایجاد نمیکند و همچنین میتوان به صورت همزمان از طریق تردهای مختلف، بدون مشکل با آن کار کرد.
پیاده سازی خواص الحاقی به کمک ConditionalWeakTable
در اینجا نحوهی استفاده از ConditionalWeakTable را جهت اتصال خواصی جدید به وهلههای موجود اشیاء مشاهده میکنید:
ObjectCache تعریف شده از نوع استاتیک است؛ بنابراین در طول عمر برنامه زنده نگه داشته خواهد شد، اما اشیایی که به آن منتسب میشوند، خیر. هرچند به ظاهر در متد GetOrCreateValue، یک وهله از شیءایی موجود را دریافت میکند، اما در پشت صحنه صرفا IntPtr یا اشارهگری به این شیء را ذخیره سازی خواهد کرد. به این ترتیب در کار GC اخلالی صورت نخواهد گرفت و شیء مورد نظر، تا پایان کار برنامه به اجبار زنده نگه داشته نخواهد شد.
کاربرد اول
اگر با ASP.NET کار کرده باشید حتما با IPrincipal آشنایی دارید. خواصی مانند Identity یک کاربر در آن ذخیره میشوند.
سؤال: چگونه میتوان یک خاصیت جدید به نام مثلا Disclaimer را به وهلهای از این شیء افزود:
در اینجا مثالی را از کاربرد کلاس AttachedProperties فوق مشاهده میکنید. توسط متد SetDisclaimer یک خاصیت جدید به نام Disclaimer به وهلهای از شیءایی از نوع IPrincipal قابل اتصال است. سپس توسط متد Disclaimer قابل دستیابی خواهد بود.
اگر صرفا قرار است یک خاصیت به شیءایی متصل شود، روش ذیل نیز قابل استفاده میباشد (بجای استفاده از دیکشنری از یک کلاس جهت تعریف خاصیت اضافی جدید استفاده شدهاست):
کاربرد دوم
ایجاد Id منحصربفرد برای اشیاء برنامه.
فرض کنید در حال نوشتن یک Entity framework profiler هستید. طراحی فعلی سیستم Interception آن به نحو زیر است:
سؤال: اینجا رویداد بسته شدن یک اتصال را دریافت میکنیم؛ اما ... دقیقا کدام اتصال؟ رویداد Opened را هم داریم اما چگونه این اشیاء را به هم مرتبط کنیم؟ شیء DbConnection دارای Id نیست. متد GetHashCode هم الزامی ندارد که اصلا پیاده سازی شده باشد یا حتی یک Id منحصربفرد را تولید کند. این متد با تغییر مقادیر خواص یک شیء میتواند مقادیر متفاوتی را ارائه دهد. در اینجا میخواهیم به ازای ارجاعی از یک شیء، یک Id منحصربفرد داشته باشیم تا بتوانیم تشخیص دهیم که این اتصال بسته شده، دقیقا کدام اتصال باز شدهاست؟
راه حل: خوب ... یک خاصیت Id را به اشیاء موجود متصل کنید!
در اینجا مثالی دیگر از پیاده سازی و استفاده از ConditionalWeakTable را ملاحظه میکنید. اگر در کش آن ارجاعی به شیء مورد نظر وجود داشته باشد، مقدار Guid آن بازگشت داده میشود؛ اگر خیر، یک Guid به ارجاعی از شیء، انتساب داده شده و سپس بازگشت داده میشود. به عبارتی به صورت پویا یک خاصیت UniqueId به وهلههایی از اشیاء اضافه میشوند. به این ترتیب به سادگی میتوان آنها را ردیابی کرد و تشخیص داد که اگر این Guid پیشتر جایی به اتصال باز شدهای منتسب شدهاست، در چه زمانی و در کجا بسته شده است یا اصلا ... خیر. جایی بسته نشدهاست.
برای مطالعه بیشتر
The Conditional Weak Table: Enabling Dynamic Object Properties
How to create mixin using C# 4.0
Disclaimer Page using MVC
Extension Properties Revised
Easy Modeling
Providing unique ID on managed object using ConditionalWeakTable
احتمالا شاید عنوان کنید که با اشیاء dynamic میتوان چنین کاری را انجام داد. اما سؤال در مورد اشیاء غیر dynamic است.
یا نمونهی دیگر آن Attached Properties در برنامههای مبتنی بر Xaml هستند. میتوان به یک شیء از پیش موجود Xaml، خاصیتی را افزود که البته پیاده سازی آن منحصر است به همان نوع برنامهها.
راه حل پیشنهادی
یک Dictionary را ایجاد کنیم تا ارجاعی از اشیاء، به عنوان کلید، در آن ذخیره شده و سپس key/valueهایی به عنوان value هر شیء، در آن ذخیره شوند. این key/valueها همان خواص و مقادیر آنها خواهند بود. هر چند این راه حل به خوبی کار میکند اما ... مشکل نشتی حافظه دارد.
شیء Dictionary یک ارجاع قوی را از اشیاء، درون خودش نگه داری میکند و تا زمانیکه در حافظه باقی است، سیستم GC مجوز رهاسازی منابع آنها را نخواهد یافت؛ چون عموما این نوع Dictionaryها باید استاتیک تعریف شوند تا طول عمر آنها با طول عمر برنامه یکی گردد. بنابراین اساسا اشیایی که به این نحو قرار است پردازش شوند، هیچگاه dispose نخواهند شد. راه حلی برای این مساله در دات نت 4 به صورت توکار به دات نت فریم ورک اضافه شدهاست؛ به نام ساختار دادهای ConditionalWeakTable.
معرفی ConditionalWeakTable
ConditionalWeakTable جزو ساختارهای دادهای کمتر شناخته شدهی دات نت است. این ساختار داده، اشارهگرهایی را به ارجاعات اشیاء، درون خود ذخیره میکند. بنابراین چون ارجاعاتی قوی را به اشیاء ایجاد نمیکند، مانع عملکرد GC نیز نشده و برنامه در دراز مدت دچار مشکل نشتی حافظه نخواهد شد. هدف اصلی آن ایجاد ارتباطی بین CLR و DLR است. توسط آن میتوان به اشیاء دلخواه، خواصی را افزود. به علاوه طراحی آن به نحوی است که thread safe است و مباحث قفل گذاری بر روی اطلاعات، به صورت توکار در آن پیاده سازی شدهاست. کار DLR فراهم آوردن امکان پیاده سازی زبانهای پویایی مانند Ruby و Python برفراز CLR است. در این نوع زبانها میتوان به وهلههایی از اشیاء موجود، خاصیتهای جدیدی را متصل کرد.
به صورت خلاصه کار ConditionalWeakTable ایجاد نگاشتی است بین وهلههایی از اشیاء CLR (اشیایی غیرپویا) و خواصی که به آنها میتوان به صورت پویا انتساب داد. در کار GC اخلال ایجاد نمیکند و همچنین میتوان به صورت همزمان از طریق تردهای مختلف، بدون مشکل با آن کار کرد.
پیاده سازی خواص الحاقی به کمک ConditionalWeakTable
در اینجا نحوهی استفاده از ConditionalWeakTable را جهت اتصال خواصی جدید به وهلههای موجود اشیاء مشاهده میکنید:
using System.Collections.Generic; using System.Runtime.CompilerServices; namespace ConditionalWeakTableSamples { public static class AttachedProperties { public static ConditionalWeakTable<object, Dictionary<string, object>> ObjectCache = new ConditionalWeakTable<object, Dictionary<string, object>>(); public static void SetValue<T>(this T obj, string name, object value) where T : class { var properties = ObjectCache.GetOrCreateValue(obj); if (properties.ContainsKey(name)) properties[name] = value; else properties.Add(name, value); } public static T GetValue<T>(this object obj, string name) { Dictionary<string, object> properties; if (ObjectCache.TryGetValue(obj, out properties) && properties.ContainsKey(name)) return (T)properties[name]; return default(T); } public static object GetValue(this object obj, string name) { return obj.GetValue<object>(name); } } }
کاربرد اول
اگر با ASP.NET کار کرده باشید حتما با IPrincipal آشنایی دارید. خواصی مانند Identity یک کاربر در آن ذخیره میشوند.
سؤال: چگونه میتوان یک خاصیت جدید به نام مثلا Disclaimer را به وهلهای از این شیء افزود:
public static class ISecurityPrincipalExtension { public static bool Disclaimer(this IPrincipal principal) { return principal.GetValue<bool>("Disclaimer"); } public static void SetDisclaimer(this IPrincipal principal, bool value) { principal.SetValue("Disclaimer", value); } }
اگر صرفا قرار است یک خاصیت به شیءایی متصل شود، روش ذیل نیز قابل استفاده میباشد (بجای استفاده از دیکشنری از یک کلاس جهت تعریف خاصیت اضافی جدید استفاده شدهاست):
using System.Runtime.CompilerServices; namespace ConditionalWeakTableSamples { public static class PropertyExtensions { private class ExtraPropertyHolder { public bool IsDirty { get; set; } } private static readonly ConditionalWeakTable<object, ExtraPropertyHolder> _isDirtyTable = new ConditionalWeakTable<object, ExtraPropertyHolder>(); public static bool IsDirty(this object @this) { return _isDirtyTable.GetOrCreateValue(@this).IsDirty; } public static void SetIsDirty(this object @this, bool isDirty) { _isDirtyTable.GetOrCreateValue(@this).IsDirty = isDirty; } } }
کاربرد دوم
ایجاد Id منحصربفرد برای اشیاء برنامه.
فرض کنید در حال نوشتن یک Entity framework profiler هستید. طراحی فعلی سیستم Interception آن به نحو زیر است:
public void Closed(DbConnection connection, DbConnectionInterceptionContext interceptionContext) { }
راه حل: خوب ... یک خاصیت Id را به اشیاء موجود متصل کنید!
using System; using System.Runtime.CompilerServices; namespace ConditionalWeakTableSamples { public static class UniqueIdExtensions { static readonly ConditionalWeakTable<object, string> _idTable = new ConditionalWeakTable<object, string>(); public static string GetUniqueId(this object obj) { return _idTable.GetValue(obj, o => Guid.NewGuid().ToString()); } public static string GetUniqueId(this object obj, string key) { return _idTable.GetValue(obj, o => key); } } }
برای مطالعه بیشتر
The Conditional Weak Table: Enabling Dynamic Object Properties
How to create mixin using C# 4.0
Disclaimer Page using MVC
Extension Properties Revised
Easy Modeling
Providing unique ID on managed object using ConditionalWeakTable
C# 9.0 به همراه دو بهبود جزئی دربارهی کار با Lambdas است:
- امکان عدم ذکر بعضی از پارامترهای Lambdas
- امکان تعریف متدهای static anonymous
امکان عدم ذکر بعضی از پارامترهای Lambdas در C# 9.0
مثال زیر را در نظر بگیرید:
در عبارت lambda تعریف شده، از پارامترهای obj و args استفاده نشدهاست. به همین جهت برای کاهش اخطارهای نمایش داده شدهی توسط کامپایلر در C# 9.0 میتوان آنها را به صورت discard parameters توسط _ معرفی کرد؛ به یکی از دو روش زیر:
که در یکی، نوعها به همراه discard parameters ذکر شدهاند و در دومی فقط discard parameters را داریم.
نمونهی دیگر آن در حین تعریف رخدادگردانها است:
که اینبار پارامترهای استفاده نشده به صورت زیر قابل بیان هستند:
امکان تعریف Static anonymous functions در C# 9.0
برای کاهش میزان تخصیص حافظهی در حین کار با عبارات lambda ای که از متغیرهای محلی استفاده میکنند، اینبار در C# 9.0 میتوان این عبارات را static تعریف کرد. برای نمونه مثال زیر را درنظر بگیرید:
در اینجا نحوهی فرمت نهایی اطلاعات نمایش داده شده، توسط یک عبارت lambda تامین میشود. اتفاقی که در اینجا رخ میدهد، اصطلاحا capture شدن یک متغیر (text در اینجا) توسط یک anonymous function است (همان عبارت lambda نوشته شده). حاصل این capture شدن، ایجاد یک شیء موقتی برای مدیریت آن است که تخصیص حافظه و همچنین سربار عملیاتی اضافهای را به همراه دارد. برای حذف این سربارها در C# 9.0 میتوان متغیر استفاده شده را const تعریف کرد و سپس عبارت lambda تعریف شده را به صورت static نوشت:
با تعریف شدن یک عبارت lambda و یا یک anonymous method به صورت static که از تخصیص حافظهی اضافی ایجاد شیء موقتی مدیریت کنندهی دسترسی به متغیر text جلوگیری میکند، اتفاقات زیر نیز رخ میدهند:
- این متد به عنوان static anonymous function شناخته میشود.
- دیگر نمیتواند دسترسی به حالت scope جاری را داشته باشد. بنابراین دیگر دسترسی به متغیرها، پارامترها و حتی شیء this را هم نخواهد داشت.
- میتواند با سایر اعضای استاتیک scope جاری کار کند.
- میتواند به تعاریف const مربوط به scope جاری، دسترسی داشته باشد.
- امکان عدم ذکر بعضی از پارامترهای Lambdas
- امکان تعریف متدهای static anonymous
امکان عدم ذکر بعضی از پارامترهای Lambdas در C# 9.0
مثال زیر را در نظر بگیرید:
Action<object, EventArgs> handler1 = (object obj, EventArgs args) => ShowDialog();
Action<object, EventArgs> handler2 = (object _, EventArgs _) => ShowDialog(); // OR Action<object, EventArgs> handler3 = (_, _) => ShowDialog();
نمونهی دیگر آن در حین تعریف رخدادگردانها است:
button1.Click += (s, e) => ShowDialog();
button1.Click += (_, _) => ShowDialog();
امکان تعریف Static anonymous functions در C# 9.0
برای کاهش میزان تخصیص حافظهی در حین کار با عبارات lambda ای که از متغیرهای محلی استفاده میکنند، اینبار در C# 9.0 میتوان این عبارات را static تعریف کرد. برای نمونه مثال زیر را درنظر بگیرید:
namespace CS9Features { public class LambdasTests { public void Test() { string text = "{0} is a good user !"; PrintItems(item => string.Format(text, item)); } private void PrintItems(Func<string, string> formatFunc) { foreach (var item in new[] { "User 1", "User 2" }) { Console.WriteLine(formatFunc(item)); } } } }
const string text = "{0} is a good user !"; PrintItems(static item => string.Format(text, item));
- این متد به عنوان static anonymous function شناخته میشود.
- دیگر نمیتواند دسترسی به حالت scope جاری را داشته باشد. بنابراین دیگر دسترسی به متغیرها، پارامترها و حتی شیء this را هم نخواهد داشت.
- میتواند با سایر اعضای استاتیک scope جاری کار کند.
- میتواند به تعاریف const مربوط به scope جاری، دسترسی داشته باشد.
نظرات مطالب
پردازشهای Async در Entity framework 6
- به روز رسانی خودکار وابستگیهای پروژه:
- تعریف فضای نام مرتبط:
PM> update-package
using System.Data.Entity;
روش سنتی بررسی نال بودن اشیاء و متغیرها در زبان #C، استفاده از اپراتور == است:
اما از زمان C# 7.0 و معرفی pattern matching، از واژهی کلیدی is نیز میتوان برای اینکار استفاده کرد (که به آن constant pattern هم میگویند):
اکنون سؤال اینجا است که امروز بهتر است از کدامیک استفاده کنیم؟
سربارگذاری عملگرها و مقایسهی وهلههای اشیاء با null
در عمل، تفاوتی بین استفادهی از عملگر == و واژهی کلیدی is برای بررسی نال بودن وهلهای از یک شیء وجود ندارد؛ اما ... با یک شرط! فقط در حالتیکه عملگر == سربارگذاری نشده باشد.
برای نمونه کلاس Person زیر را در نظر بگیرید که عملگرهای == و =! آن بازنویسی شدهاند:
در این حالت اگر قطعه کد زیر را اجرا کنیم که در یک سطر آن، وهلهی person که مقدار نال را دارد، توسط عملگر == با null مقایسه شدهاست و در سطر بعدی با کمک واژهی کلیدی is با نال مقایسه شدهاست:
به نظر شما خروجی این قطعه کد چیست؟
اگر در کلاس Person سربارگذاری عملگر == صورت نمیگرفت، خروجی زیر را مشاهده میکردیم:
اما اینبار خروجی واقعی قطعه کد فوق، با چیزی که انتظار داریم متفاوت است:
مزیت کار با واژهی کلیدی is، صرفنظر کردن از operator overloads یا همان سربارگذاری عملگرها است. در حین حالت فقط مقدار person، با null مقایسه میشود و دیگر، کار به بررسی خروجی false زیر نمیرسد (کاری که با استفاده از عملگر == حتما انجام خواهد شد):
به عبارتی استفادهی از عملگر == جهت مقایسهی با null، حتما نیاز به بررسی کدهای کلاس Person را جهت مشاهدهی کدهای تغییر یافتهی عملگر == را نیز دارد؛ اما زمانیکه از وژهی کلیدی is استفاده میکنیم، مقصود اصلی ما را که بررسی مقدار جاری با null است، برآورده میکند (و در 99 درصد موارد، ما هدف دیگری را دنبال نمیکنیم و برای ما مهم نیست که عملگر == سربارگذاری شدهاست یا خیر). همچنین سرعت مقایسه در حالت استفاده از واژهی کلیدی is نیز بیشتر است؛ چون دیگر فراخوانی کدی که عملگر == را سربارگذاری میکند، صورت نخواهد گرفت و از زمان C# 9.0، برای حالت بررسی حالت عکس آن میتوان از if (obj is not null) نیز استفاده کرد (بجای if (!(obj is null))) که از حالت سربارگذاری عملگر =! صرفنظر میکند.
یک نکته: null coalescing operator یعنی ?? و null coalescing assignment operator یعنی =?? نیز همانند واژهی کلیدی is عمل میکنند. یعنی از == سربارگذاری شده صرفنظر خواهند کرد.
if(person == null) { }
if(person is null) { }
سربارگذاری عملگرها و مقایسهی وهلههای اشیاء با null
در عمل، تفاوتی بین استفادهی از عملگر == و واژهی کلیدی is برای بررسی نال بودن وهلهای از یک شیء وجود ندارد؛ اما ... با یک شرط! فقط در حالتیکه عملگر == سربارگذاری نشده باشد.
برای نمونه کلاس Person زیر را در نظر بگیرید که عملگرهای == و =! آن بازنویسی شدهاند:
public class Person { public static bool operator ==(Person x, Person y) { return false; } public static bool operator !=(Person x, Person y) { return !(x == y); } public override bool Equals(object obj) { return base.Equals(obj); } }
Person person = null; Console.WriteLine("Is Person null?"); Console.WriteLine($"== says: {person == null}"); Console.WriteLine($"is says: {person is null}");
اگر در کلاس Person سربارگذاری عملگر == صورت نمیگرفت، خروجی زیر را مشاهده میکردیم:
Is Person null? == says: True is says: True
Is Person null? == says: False is says: True
public static bool operator ==(Person x, Person y) { return false; }
یک نکته: null coalescing operator یعنی ?? و null coalescing assignment operator یعنی =?? نیز همانند واژهی کلیدی is عمل میکنند. یعنی از == سربارگذاری شده صرفنظر خواهند کرد.
مطالب
آموزش Knockout.Js #4
مقید سازی رویداد کلیک
Click Binding روشی است برای اضافه کردن یک گرداننده رویداد در زمانی که قصد داریم یک تابع جاوااسکریپتی را در هنگام کلیک بر روی المان مورد نظر فراخوانی کنیم. از این مقید سازی عموما در عناصر button و input و تگ a استفاده میشود. اما در حقیقت در تمام عناصر غیر پنهان صفحه مورد استفاده قرار میگیرد.
Click Binding روشی است برای اضافه کردن یک گرداننده رویداد در زمانی که قصد داریم یک تابع جاوااسکریپتی را در هنگام کلیک بر روی المان مورد نظر فراخوانی کنیم. از این مقید سازی عموما در عناصر button و input و تگ a استفاده میشود. اما در حقیقت در تمام عناصر غیر پنهان صفحه مورد استفاده قرار میگیرد.
<div> Number Of Clicks <span data-bind="text: numberOfClicks"></span> times <button data-bind="click: clickMe">Click me</button> </div> <script type="text/javascript"> var viewModel = { numberOfClicks : ko.observable(0), clickMe: function() { var previousCount = this.numberOfClicks(); this.numberOfClicks(previousCount + 1); } }; </script>
رویداد کلیک button در کد بالا به تابعی با نام clickMe مقید شده است. این تابع در viewModel جاری صفحه تعریف شده است و در بدنه آن تعداد کلیکهای قبلی را به علاوه یک خواهد کرد. از آنجا که تگ span در بالای صفحه به تعداد کلیکها مقید شده است در نتیجه همواره مقدار این تگ به روز خواهد بود.
*نکته اول: اگر قصد داشته باشیم که عنصر جاری در viewModel را به گرداننده رویداد پاس دهیم چه باید کرد؟
هنگام فراخوانی رویدادها، KO به صورت پیش فرض مقدار جاری مدل را به عنوان اولین پارامتر به این گرداننده پاس میدهد. این روش مخصوصا در هنگامی که قصد اجرای عملیاتی خاص بر روی تک تک عناصر یک مجموعه را داشته باشید(مثل حلقه foreach) بسیار مفید خواهد بود.
*نکته اول: اگر قصد داشته باشیم که عنصر جاری در viewModel را به گرداننده رویداد پاس دهیم چه باید کرد؟
هنگام فراخوانی رویدادها، KO به صورت پیش فرض مقدار جاری مدل را به عنوان اولین پارامتر به این گرداننده پاس میدهد. این روش مخصوصا در هنگامی که قصد اجرای عملیاتی خاص بر روی تک تک عناصر یک مجموعه را داشته باشید(مثل حلقه foreach) بسیار مفید خواهد بود.
<ul data-bind="foreach: places"> <li> <span data-bind="text: $data"></span> <button data-bind="click: $parent.removePlace">Remove</button> </li> </ul> <script type="text/javascript"> function MyViewModel() { var self = this; self.places = ko.observableArray(['Tehran', 'Esfahan', 'Shiraz']); self.removePlace = function(place) { self.places.remove(place) } } ko.applyBindings(new MyViewModel()); </script>
در تابع removePlace میبینید که مقدار آیتم جاری در لیست به عنوان اولین آرگومان به این تابع پاس داده میشود، در نتیجه میدانیم که کدام عنصر را باید از لیست مورد نظر حذف کنیم. برای به دست آوردن آیتم جاری در لیست از parent$ یا root$ میتوان استفاده کرد.
همان طور که پست قبل توضیح داده شد؛ برای اینکه بتوانیم از یک viewModel به مجموعه از عناصر در یک حلقه foreach مقید کنیم امکان استفاده از اشاره گر this میسر نیست. در نتیجه بهتر است در ابتدای viewModel مقدار این اشاره گر را در یک متغیر معمولی (در اینجا به نام self است) ذخیره کنیم و از این پس این متغیر را برای اشاره به عناصر viewModel به کار بریم. در اینجا self به عنواتن یک alias برای this خواهد بود.
*نکته دوم: دسترسی به عنصر رویداد
در بعضی مواقع نیاز است در حین فراخوانی رویداد ،عنصر رویداد DOM به عنوان فرستنده در اختیار تابع گرداننده قرار گیرد. خبر خوش این است که KO به صورت پیش فرض این عنصر را نیز به عنوان پارامتر دوم به توابع گرداننده رویداد پاس میدهد. برای مثال:
تابع myFunction در مثال بالا دارای دو پارامتر است. پارامتر دوم در این تابع به عنوان عنصر فرستنده رویداد مورد استفاده قرار خواهد گرفت. بدین ترتیب در توابع event Handlerها میتوان به راحتی اطلاعات مورد نیاز درباره آبجکت رویداد را به دست آورد.
*نکته سوم: به صورت پیش فرض KO از اجرای عملیات پیش فرض رویدادها جلوگیری به عمل میآورد. این به این معنی است که اگر برای رویداد کلیک تگ a بک تابع گرداننده تعریف کرده باشید، بعد از کلیک بر روی این المان؛ مرورگر فقط این تابع تعریف شده توسط شما را فراخوانی خواهد کرد و دیگر عملیات راهبری به صفحه مورد نظر در خاصیت href صورت نخواهد گرفت. اگر به هر دلیلی قصد داشته باشیم که این رفتار صورت نگیرد کافیست در انتهای تابع گرداننده رویداد مقدار true برگشت داده شود.
*نکته چهارم: مفهوم clickBubble
ابتدا به کد زیر دقت کنید:
همان طور که مشاهده میکنید در کد بالا برای عنصر button یک رویداد کلید تعریف شده است. از طرف دیگر این button درون تگ div قرار دارد که برای این تگ نیز این رویداد کلیک با تابع گرداننده متفاوتی تعریف شده است. نکته این جاست که به صورت پیش فرض بعد از فراخوانی رویداد کلیک عنصر داخلی، رویداد کلیک عنصر خارجی نیز فراخوانی خواهد شد. به این رفتار event bubbling میگویند. اگر قصد داشته باشیم که این رفتار را غیر فعال کنیم(بعنی با کلیک بر روی button، رویداد کلیک تگ div اجرا نشود باید مقدار خاصبت clickBubble رویداد عنصر داخلی را برابر false قرار دهیم) به صورت زیر:
همان طور که پست قبل توضیح داده شد؛ برای اینکه بتوانیم از یک viewModel به مجموعه از عناصر در یک حلقه foreach مقید کنیم امکان استفاده از اشاره گر this میسر نیست. در نتیجه بهتر است در ابتدای viewModel مقدار این اشاره گر را در یک متغیر معمولی (در اینجا به نام self است) ذخیره کنیم و از این پس این متغیر را برای اشاره به عناصر viewModel به کار بریم. در اینجا self به عنواتن یک alias برای this خواهد بود.
*نکته دوم: دسترسی به عنصر رویداد
در بعضی مواقع نیاز است در حین فراخوانی رویداد ،عنصر رویداد DOM به عنوان فرستنده در اختیار تابع گرداننده قرار گیرد. خبر خوش این است که KO به صورت پیش فرض این عنصر را نیز به عنوان پارامتر دوم به توابع گرداننده رویداد پاس میدهد. برای مثال:
<button data-bind="click: myFunction"> Click me </button> <script type="text/javascript"> var viewModel = { myFunction: function(data, event) { if (event.shiftKey) { } else { } } }; ko.applyBindings(viewModel); </script>
*نکته سوم: به صورت پیش فرض KO از اجرای عملیات پیش فرض رویدادها جلوگیری به عمل میآورد. این به این معنی است که اگر برای رویداد کلیک تگ a بک تابع گرداننده تعریف کرده باشید، بعد از کلیک بر روی این المان؛ مرورگر فقط این تابع تعریف شده توسط شما را فراخوانی خواهد کرد و دیگر عملیات راهبری به صفحه مورد نظر در خاصیت href صورت نخواهد گرفت. اگر به هر دلیلی قصد داشته باشیم که این رفتار صورت نگیرد کافیست در انتهای تابع گرداننده رویداد مقدار true برگشت داده شود.
*نکته چهارم: مفهوم clickBubble
ابتدا به کد زیر دقت کنید:
<div data-bind="click: myDivHandler"> <button data-bind="click: myButtonHandler"> Click me </button> </div>
<div data-bind="click: myDivHandler"> <button data-bind="click: myButtonHandler, clickBubble: false"> Click me </button> </div>