نظرات مطالب
سری فیبوناچی و دات نت 4 !
بله. درسته. ولی من دراکثر موارد خوانایی کد را به چند میلی ثانیه بهبود کارآیی ترجیح میدم.
در مورد تفاوت نتایج حاصل از بررسی کارآیی Array.ForEach، مطالبی در اینجا هست که علت رو بیشتر باز کرده (و دقیقا در مثالهای جاری صادق هست؛ یکی با lambda است و دیگری بدون lambda):
تفاوت کارآیی در حین استفاده از Lambdas و Method groups
تفاوت کارآیی در حین استفاده از Lambdas و Method groups
Variable Naming Best Practices in JavaScript
Like any other programming language, JavaScript relies heavily on well-structured and understandable code. One of the fundamental building blocks of clean JavaScript code is effective variable naming.
By adhering to certain best practices, you can significantly enhance the readability and maintainability of your JavaScript projects. Let’s dive into 12 sets of JavaScript variable naming guidelines.
مقدمات ساخت بلاگ مبتنی بر ember.js در قسمت قبل به پایان رسید. در این قسمت صرفا قصد داریم بجای استفاده از HTML 5 local storage از یک REST web service مانند یک ASP.NET Web API Controller و یا یک ASP.NET MVC Controller استفاده کنیم و اطلاعات نهایی را به سرور ارسال و یا از آن دریافت کنیم.
تنظیم Ember data برای کار با سرور
Ember data به صورت پیش فرض و در پشت صحنه با استفاده از Ajax برای کار با یک REST Web Service طراحی شدهاست و کلیه تبادلات آن نیز با فرمت JSON انجام میشود. بنابراین تمام کدهای سمت کاربر قسمت قبل نیز در این حالت کار خواهند کرد. تنها کاری که باید انجام شود، حذف تنظیمات ابتدایی آن برای کار با HTML 5 local storage است.
برای این منظور ابتدا فایل index.html را گشوده و سپس مدخل localstorage_adapter.js را از آن حذف کنید:
همچنین دیگر نیازی به store.js نیز نمیباشد:
اکنون برنامه را اجرا کنید، چنین پیام خطایی را مشاهده خواهید کرد:
این درخواست نیز بر اساس تعاریف موجود در فایل Scripts\Routes\posts.js، به سرور ارسال شدهاست:
Ember data شبیه به یک ORM عمل میکند. تنظیمات ابتدایی آنرا تغییر دهید، بدون نیازی به تغییر در کدهای اصلی برنامه، میتواند با یک منبع داده جدید کار کند.
تغییر تنظیمات پیش فرض آغازین Ember data
آدرس درخواستی http://localhost:25918/posts به این معنا است که کلیه درخواستها، به همان آدرس و پورت ریشهی اصلی سایت ارسال میشوند. اما اگر یک ASP.NET Web API Controller را تعریف کنیم، نیاز است این درخواستها، برای مثال به آدرس api/posts ارسال شوند؛ بجای /posts.
برای این منظور پوشهی جدید Scripts\Adapters را ایجاد کرده و فایل web_api_adapter.js را با این محتوا به آن اضافه کنید:
سپس تعریف مدخل آنرا نیز به فایل index.html اضافه نمائید:
تعریف فضای نام در اینجا سبب خواهد شد تا درخواستهای جدید به آدرس api/posts ارسال شوند.
تغییر تنظیمات پیش فرض ASP.NET Web API
در سمت سرور، بنابر اصول نامگذاری خواص، نامها با حروف بزرگ شروع میشوند:
اما در سمت کاربر و کدهای اسکریپتی، عکس آن صادق است. به همین جهت نیاز است که CamelCasePropertyNamesContractResolver را در JSON.NET تنظیم کرد تا به صورت خودکار اطلاعات ارسالی به کلاینتها را به صورت camel case تولید کند:
نحوهی صحیح بازگشت اطلاعات از یک ASP.NET Web API جهت استفاده در Ember data
با تنظیمات فوق، اگر کنترلر جدیدی را به صورت ذیل جهت بازگشت لیست مطالب تهیه کنیم:
با یک چنین خطایی در سمت کاربر مواجه خواهیم شد:
این خطا از آنجا ناشی میشود که Ember data، اطلاعات دریافتی از سرور را بر اساس قرارداد JSON API دریافت میکند. برای حل این مشکل راهحلهای زیادی مطرح شدهاند که تعدادی از آنها را در لینکهای زیر میتوانید مطالعه کنید:
http://jsonapi.codeplex.com
https://github.com/xqiu/MVCSPAWithEmberjs
https://github.com/rmichela/EmberDataAdapter
https://github.com/MilkyWayJoe/Ember-WebAPI-Adapter
http://blog.yodersolutions.com/using-ember-data-with-asp-net-web-api
http://emadibrahim.com/2014/04/09/emberjs-and-asp-net-web-api-and-json-serialization
و خلاصهی آنها به این صورت است:
خروجی JSON تولیدی توسط ASP.NET Web API چنین شکلی را دارد:
اما Ember data نیاز به یک چنین خروجی دارد:
به عبارتی آرایهی مطالب را از ریشهی posts باید دریافت کند (مطابق فرمت JSON API). برای انجام اینکار یا از لینکهای معرفی شده استفاده کنید و یا راه حل سادهی ذیل هم پاسخگو است:
در اینجا ریشهی posts را توسط یک anonymous object ایجاد کردهایم.
اکنون اگر برنامه را اجرا کنید، در صفحهی اول آن، لیست عناوین مطالب را مشاهده خواهید کرد.
تاثیر قرارداد JSON API در حین ارسال اطلاعات به سرور توسط Ember data
در تکمیل کنترلرهای Web API مورد نیاز (کنترلرهای مطالب و نظرات)، نیاز به متدهای Post، Update و Delete هم خواهد بود. دقیقا فرامین ارسالی توسط Ember data توسط همین HTTP Verbs به سمت سرور ارسال میشوند. در این حالت اگر متد Post کنترلر نظرات را به این شکل طراحی کنیم:
کار نخواهد کرد؛ چون مطابق فرمت JSON API ارسالی توسط Ember data، یک چنین شیء JSON ایی را دریافت خواهیم کرد:
بنابراین Ember data چه در حین دریافت اطلاعات از سرور و چه در زمان ارسال اطلاعات به آن، اشیاء جاوا اسکریپتی را در یک ریشهی هم نام آن شیء قرار میدهد.
برای پردازش آن، یا باید از راه حلهای ثالث مطرح شده در ابتدای بحث استفاده کنید و یا میتوان مطابق کدهای ذیل، کل اطلاعات JSON ارسالی را توسط کتابخانهی JSON.NET نیز پردازش کرد:
در اینجا توسط requestMessage به محتوای ارسال شدهی به سرور که همان شیء JSON ارسالی است، دسترسی خواهیم داشت. سپس متد JObject.Parse، آنرا به صورت عمومی تبدیل به یک شیء JSON میکند و نهایتا با استفاده از متد SelectToken آن میتوان ریشهی comment و یا در کنترلر مطالب، ریشهی post را انتخاب و سپس تبدیل به شیء Comment و یا Post کرد.
همچنین فرمت return نهایی هم مهم است. در این حالت خروجی ارسالی به سمت کاربر، باید مجددا با فرمت JSON API باشد؛ یعنی باید comment اصلاح شده را به همراه ریشهی comment ارسال کرد. در اینجا نیز anonymous object تهیه شده، چنین کاری را انجام میدهد.
Lazy loading در Ember data
تا اینجا اگر برنامه را اجرا کنید، لیست مطالب صفحهی اول را مشاهده خواهید کرد، اما لیست نظرات آنها را خیر؛ از این جهت که ضرورتی نداشت تا در بار اول ارسال لیست مطالب به سمت کاربر، تمام نظرات متناظر با آنها را هم ارسال کرد. بهتر است زمانیکه کاربر یک مطلب خاص را مشاهده میکند، نظرات خاص آنرا به سمت کاربر ارسال کنیم.
در تعاریف سمت کاربر Ember data، پارامتر دوم رابطهی hasMany که با async:true مشخص شدهاست، دقیقا معنای lazy loading را دارد.
در سمت سرور، دو راه برای فعال سازی این lazy loading تعریف شده در سمت کاربر وجود دارد:
الف) Idهای نظرات هر مطلب را به صورت یک آرایه، در بار اول ارسال لیست نظرات به سمت کاربر، تهیه و ارسال کنیم:
در اینجا خاصیت Comments، تنها کافی است لیستی از Idهای نظرات مرتبط با مطلب جاری باشد. در این حالت در سمت کاربر اگر مطلب خاصی جهت مشاهدهی جزئیات آن انتخاب شود، به ازای هر Id ذکر شده، یکبار دستور Get صادر خواهد شد.
ب) این روش به علت تعداد رفت و برگشت بیش از حد به سرور، کارآیی آنچنانی ندارد. بهتر است جهت مشاهدهی جزئیات یک مطلب، تنها یکبار درخواست Get کلیه نظرات آن صادر شود.
برای اینکار باید مدل برنامه را به شکل زیر تغییر دهیم:
در اینجا یک خاصیت جدید به نام Links ارائه شدهاست. نام Links در Ember data استاندارد است و از آن برای دریافت کلیه اطلاعات لینک شدهی به یک مطلب استفاده میشود. با تعریف این خاصیت به نحوی که ملاحظه میکنید، اینبار Ember data تنها یکبار درخواست ویژهای را با فرمت api/posts/id/comments، به سمت سرور ارسال میکند. برای مدیریت آن، قالب مسیریابی پیش فرض {api/{controller}/{id را میتوان به صورت {api/{controller}/{id}/{name اصلاح کرد:
اکنون دیگر درخواست جدید api/posts/3/comments با پیام 404 یا یافت نشد مواجه نمیشود.
در این حالت در طی یک درخواست میتوان کلیه نظرات را به سمت کاربر ارسال کرد. در اینجا نیز ذکر ریشهی comments همانند ریشه posts، الزامی است:
پردازشهای async و متد transitionToRoute در Ember.js
اگر متد حذف مطالب را نیز به کنترلر Posts اضافه کنیم:
قسمت سمت سرور کار تکمیل شدهاست. اما در سمت کاربر، چنین خطایی را دریافت خواهیم کرد:
منظور از حالت inFlight در اینجا این است که هنوز کار حذف سمت سرور تمام نشدهاست که متد transitionToRoute را صادر کردهاید. برای اصلاح آن، فایل Scripts\Controllers\post.js را باز کرده و پس از متد destroyRecord، متد then را قرار دهید:
به این ترتیب پس از پایان عملیات حذف سمت سرور، قسمت then اجرا خواهد شد. همچنین باید دقت داشت که this اشاره کننده به کنترلر جاری را باید پیش از فراخوانی then ذخیره و استفاده کرد.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید:
EmberJS03_05.zip
تنظیم Ember data برای کار با سرور
Ember data به صورت پیش فرض و در پشت صحنه با استفاده از Ajax برای کار با یک REST Web Service طراحی شدهاست و کلیه تبادلات آن نیز با فرمت JSON انجام میشود. بنابراین تمام کدهای سمت کاربر قسمت قبل نیز در این حالت کار خواهند کرد. تنها کاری که باید انجام شود، حذف تنظیمات ابتدایی آن برای کار با HTML 5 local storage است.
برای این منظور ابتدا فایل index.html را گشوده و سپس مدخل localstorage_adapter.js را از آن حذف کنید:
<!--<script src="Scripts/Libs/localstorage_adapter.js" type="text/javascript"></script>-->
<!--<script src="Scripts/App/store.js" type="text/javascript"></script>-->
اکنون برنامه را اجرا کنید، چنین پیام خطایی را مشاهده خواهید کرد:
همانطور که عنوان شد، ember data به صورت پیش فرض با سرور کار میکند و در اینجا به صورت خودکار، یک درخواست Get را به آدرس http://localhost:25918/posts جهت دریافت آخرین مطالب ثبت شده، ارسال کردهاست و چون هنوز وب سرویسی در برنامه تعریف نشده، با خطای 404 و یا یافت نشد، مواجه شدهاست.
این درخواست نیز بر اساس تعاریف موجود در فایل Scripts\Routes\posts.js، به سرور ارسال شدهاست:
Blogger.PostsRoute = Ember.Route.extend({ model: function () { return this.store.find('post'); } });
تغییر تنظیمات پیش فرض آغازین Ember data
آدرس درخواستی http://localhost:25918/posts به این معنا است که کلیه درخواستها، به همان آدرس و پورت ریشهی اصلی سایت ارسال میشوند. اما اگر یک ASP.NET Web API Controller را تعریف کنیم، نیاز است این درخواستها، برای مثال به آدرس api/posts ارسال شوند؛ بجای /posts.
برای این منظور پوشهی جدید Scripts\Adapters را ایجاد کرده و فایل web_api_adapter.js را با این محتوا به آن اضافه کنید:
DS.RESTAdapter.reopen({ namespace: 'api' });
<script src="Scripts/Adapters/web_api_adapter.js" type="text/javascript"></script>
تغییر تنظیمات پیش فرض ASP.NET Web API
در سمت سرور، بنابر اصول نامگذاری خواص، نامها با حروف بزرگ شروع میشوند:
namespace EmberJS03.Models { public class Post { public int Id { set; get; } public string Title { set; get; } public string Body { set; get; } } }
using System; using System.Web.Http; using System.Web.Routing; using Newtonsoft.Json.Serialization; namespace EmberJS03 { public class Global : System.Web.HttpApplication { protected void Application_Start(object sender, EventArgs e) { RouteTable.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}", defaults: new { id = RouteParameter.Optional } ); var settings = GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings; settings.ContractResolver = new CamelCasePropertyNamesContractResolver(); } } }
نحوهی صحیح بازگشت اطلاعات از یک ASP.NET Web API جهت استفاده در Ember data
با تنظیمات فوق، اگر کنترلر جدیدی را به صورت ذیل جهت بازگشت لیست مطالب تهیه کنیم:
namespace EmberJS03.Controllers { public class PostsController : ApiController { public IEnumerable<Post> Get() { return DataSource.PostsList; } } }
WARNING: Encountered "0" in payload, but no model was found for model name "0" (resolved model name using DS.RESTSerializer.typeForRoot("0"))
http://jsonapi.codeplex.com
https://github.com/xqiu/MVCSPAWithEmberjs
https://github.com/rmichela/EmberDataAdapter
https://github.com/MilkyWayJoe/Ember-WebAPI-Adapter
http://blog.yodersolutions.com/using-ember-data-with-asp-net-web-api
http://emadibrahim.com/2014/04/09/emberjs-and-asp-net-web-api-and-json-serialization
و خلاصهی آنها به این صورت است:
خروجی JSON تولیدی توسط ASP.NET Web API چنین شکلی را دارد:
[ { Id: 1, Title: 'First Post' }, { Id: 2, Title: 'Second Post' } ]
{ posts: [{ id: 1, title: 'First Post' }, { id: 2, title: 'Second Post' }] }
using System.Web.Http; using EmberJS03.Models; namespace EmberJS03.Controllers { public class PostsController : ApiController { public object Get() { return new { posts = DataSource.PostsList }; } } }
اکنون اگر برنامه را اجرا کنید، در صفحهی اول آن، لیست عناوین مطالب را مشاهده خواهید کرد.
تاثیر قرارداد JSON API در حین ارسال اطلاعات به سرور توسط Ember data
در تکمیل کنترلرهای Web API مورد نیاز (کنترلرهای مطالب و نظرات)، نیاز به متدهای Post، Update و Delete هم خواهد بود. دقیقا فرامین ارسالی توسط Ember data توسط همین HTTP Verbs به سمت سرور ارسال میشوند. در این حالت اگر متد Post کنترلر نظرات را به این شکل طراحی کنیم:
public HttpResponseMessage Post(Comment comment)
{"comment":{"text":"data...","post":"3"}}
برای پردازش آن، یا باید از راه حلهای ثالث مطرح شده در ابتدای بحث استفاده کنید و یا میتوان مطابق کدهای ذیل، کل اطلاعات JSON ارسالی را توسط کتابخانهی JSON.NET نیز پردازش کرد:
namespace EmberJS03.Controllers { public class CommentsController : ApiController { public HttpResponseMessage Post(HttpRequestMessage requestMessage) { var jsonContent = requestMessage.Content.ReadAsStringAsync().Result; // {"comment":{"text":"data...","post":"3"}} var jObj = JObject.Parse(jsonContent); var comment = jObj.SelectToken("comment", false).ToObject<Comment>(); var id = 1; var lastItem = DataSource.CommentsList.LastOrDefault(); if (lastItem != null) { id = lastItem.Id + 1; } comment.Id = id; DataSource.CommentsList.Add(comment); // ارسال آی دی با فرمت خاص مهم است return Request.CreateResponse(HttpStatusCode.Created, new { comment = comment }); } } }
همچنین فرمت return نهایی هم مهم است. در این حالت خروجی ارسالی به سمت کاربر، باید مجددا با فرمت JSON API باشد؛ یعنی باید comment اصلاح شده را به همراه ریشهی comment ارسال کرد. در اینجا نیز anonymous object تهیه شده، چنین کاری را انجام میدهد.
Lazy loading در Ember data
تا اینجا اگر برنامه را اجرا کنید، لیست مطالب صفحهی اول را مشاهده خواهید کرد، اما لیست نظرات آنها را خیر؛ از این جهت که ضرورتی نداشت تا در بار اول ارسال لیست مطالب به سمت کاربر، تمام نظرات متناظر با آنها را هم ارسال کرد. بهتر است زمانیکه کاربر یک مطلب خاص را مشاهده میکند، نظرات خاص آنرا به سمت کاربر ارسال کنیم.
در تعاریف سمت کاربر Ember data، پارامتر دوم رابطهی hasMany که با async:true مشخص شدهاست، دقیقا معنای lazy loading را دارد.
Blogger.Post = DS.Model.extend({ title: DS.attr(), body: DS.attr(), comments: DS.hasMany('comment', { async: true } /* lazy loading */) });
الف) Idهای نظرات هر مطلب را به صورت یک آرایه، در بار اول ارسال لیست نظرات به سمت کاربر، تهیه و ارسال کنیم:
namespace EmberJS03.Models { public class Post { public int Id { set; get; } public string Title { set; get; } public string Body { set; get; } // lazy loading via an array of IDs public int[] Comments { set; get; } } }
ب) این روش به علت تعداد رفت و برگشت بیش از حد به سرور، کارآیی آنچنانی ندارد. بهتر است جهت مشاهدهی جزئیات یک مطلب، تنها یکبار درخواست Get کلیه نظرات آن صادر شود.
برای اینکار باید مدل برنامه را به شکل زیر تغییر دهیم:
namespace EmberJS03.Models { public class Post { public int Id { set; get; } public string Title { set; get; } public string Body { set; get; } // load related models via URLs instead of an array of IDs // ref. https://github.com/emberjs/data/pull/1371 public object Links { set; get; } public Post() { Links = new { comments = "comments" }; // api/posts/id/comments } } }
namespace EmberJS03 { public class Global : System.Web.HttpApplication { protected void Application_Start(object sender, EventArgs e) { RouteTable.Routes.MapHttpRoute( name: "DefaultApi", routeTemplate: "api/{controller}/{id}/{name}", defaults: new { id = RouteParameter.Optional, name = RouteParameter.Optional } ); var settings = GlobalConfiguration.Configuration.Formatters.JsonFormatter.SerializerSettings; settings.ContractResolver = new CamelCasePropertyNamesContractResolver(); } } }
در این حالت در طی یک درخواست میتوان کلیه نظرات را به سمت کاربر ارسال کرد. در اینجا نیز ذکر ریشهی comments همانند ریشه posts، الزامی است:
namespace EmberJS03.Controllers { public class PostsController : ApiController { //GET api/posts/id public object Get(int id) { return new { posts = DataSource.PostsList.FirstOrDefault(post => post.Id == id), comments = DataSource.CommentsList.Where(comment => comment.Post == id).ToList() }; } } }
پردازشهای async و متد transitionToRoute در Ember.js
اگر متد حذف مطالب را نیز به کنترلر Posts اضافه کنیم:
namespace EmberJS03.Controllers { public class PostsController : ApiController { public HttpResponseMessage Delete(int id) { var item = DataSource.PostsList.FirstOrDefault(x => x.Id == id); if (item == null) return Request.CreateResponse(HttpStatusCode.NotFound); DataSource.PostsList.Remove(item); //حذف کامنتهای مرتبط var relatedComments = DataSource.CommentsList.Where(comment => comment.Post == id).ToList(); relatedComments.ForEach(comment => DataSource.CommentsList.Remove(comment)); return Request.CreateResponse(HttpStatusCode.OK, new { post = item }); } } }
Attempted to handle event `pushedData` on while in state root.deleted.inFlight.
Blogger.PostController = Ember.ObjectController.extend({ isEditing: false, actions: { edit: function () { this.set('isEditing', true); }, save: function () { var post = this.get('model'); post.save(); this.set('isEditing', false); }, delete: function () { if (confirm('Do you want to delete this post?')) { var thisController = this; var post = this.get('model'); post.destroyRecord().then(function () { thisController.transitionToRoute('posts'); }); } } } });
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید:
EmberJS03_05.zip
نظرات مطالب
بهبود کارآیی حلقههای foreach در دات نت 7
یک نکتهی تکمیلی: آشنایی با مفهوم «C# Lowering»
در این مطلب، جهت بررسی درک علت یکسان بودن کارآیی حلقههایی که از دیدگاه ما یکی نیستند، از قابلیت نمایش #Low-level C استفاده شد که نام اصلی آن «C# Lowering» است. Lowering به معنای ترجمهی امکانات سطح بالای یک زبان به امکانات سطح پایین آن است. یعنی حاصل عملیات صورت گرفته نیز باز به همان زبان اولیه است که نمونهی آن، تبدیل یک حلقهی foreach سطح بالا به نمونهی سطح پایینی است که توسط NET Runtime. بهتر درک شده و سادهتر اجرا میشود.
مزایای Lowering
- بهبود کارآیی برنامه: برای مثال یکی از کارهایی که در این بین عموما انجام میشود «Loop unrolling» است. یعنی یک حلقه به چندین حلقهی کوچکتر تقسیم میشود تا سربار instructions کنترلی حلقه کاهش پیدا کنند.
- طراحی سادهتر زبان: اینکار به تیم طراحی زبان امکان نوشتن کدهای اضافهتری را میدهد که کار برنامه نویسها را کمتر میکند. برای مثال یک record واقعا چیزی نیست بجز یک کلاس پیاده سازی کنندهی IEquatable به صورت خودکار و در پشت صحنه.
Lowering چه زمانی رخ میدهد؟
Lowering جزئی از عملیات صورت گرفتهی در حین کامپایل است. زمانیکه دستور dotnet build را صادر میکنیم، ابتدا semantics & syntax analysis صورت میگیرد تا اگر برای مثال خطای دستوری وجود دارد، مشخص شود. سپس کدها به CIL یا Common intermediate language تبدیل میشوند. در حین این قسمت است که عملیات lowering نیز انجام میشود.
اگر علاقمند به مشاهدهی این کد #C ثانویهی تولید شدهی توسط کامپایلر هستید، میتوان از ابزار https://sharplab.io نیز استفاده کرد. برای مثال در سمت چپ آن کدهای زیر را قرار دهید:
using System; using System.Collections.Generic; var list = new List<int> { 1, 2 }; foreach(var item in list) Console.Write(item);
ویجتهای وب Kendo UI کدامند؟
ویجتهای وب Kendo UI مجموعهای از کنترلهای سفارشی HTML 5 هستند که برفراز jQuery تهیه شدهاند. این کنترلها برای برنامههای وب و همچنین برنامههای دسکتاپ لمسی طراحی شدهاند.
بهترین روش برای مشاهدهی این مجموعه، مراجعه به فایل examples\index.html پوشهی اصلی Kendo UI است که لیست کاملی از این ویجتها را به همراه مثالهای مرتبط ارائه میدهد. تعدادی از اعضای این مجموعه شامل کنترلهای ذیل هستند:
Window, TreeView, Tooltip, ToolBar, TimePicker, TabStrip, Splitter, Sortable, Slider, Gantt, Scheduler, ProgressBar, PanelBar, NumericTextBox, Notification, MultiSelect, Menu, MaskedTextBox, ListView, PivotGrid, Grid, Editor, DropDownList, DateTimePicker, DatePicker, ComboBox, ColorPicker, Calendar, Button, AutoComplete
نحوهی استفاده کلی از ویجتهای وب Kendo UI
با توجه به اینکه کنترلهای Kendo UI مبتنی بر jQuery هستند، نحوهی استفاده از آنها، مشابه سایر افزونههای جیکوئری است. ابتدا المانی به صفحه اضافه میشود:
سپس این المان را در رویداد document ready، به یکی از کنترلهای Kendo UI مزین خواهیم کرد. برای مثال تزئین یک TextBox معمولی با یک Date Picker:
روش دیگری به نام declarative initialization نیز برای اعمال ویجتهای وب Kendo UI قابل استفاده است که از ویژگیهای *-data مرتبط با HTML 5 کمک میگیرد. برای نمونه، کدهای جاوا اسکریپتی فوق را میتوان با ویژگی data-role ذیل جایگزین کرد:
اگر در این حالت برنامه را اجرا کنید، تفاوتی را مشاهده نخواهید کرد.
برای فعال سازی حالت declarative initialization باید به دو نکتهی مهم دقت داشت:
الف) در مطلب معرفی Kendo UI اسکریپتهای ذیل برای آماده سازی Kendo Ui معرفی شدند:
باید دقت داشت که در آن واحد نمیتوان تمام این بستهها را با هم بکار برد؛ چون برای مثال فایلهای جداگانه ویجتهای وب و موبایل با هم تداخل ایجاد میکنند. بجای اینکار بهتر است از فایلهای kendo.all.min.js (که حاوی تمام اسکریپتهای لازم است) و cssهای عنوان شده استفاده کرد:
ب) data-roleها توسط متد kendo.init فعال میشوند.
یک مثال کامل:
- در این مثال نحوهی پیوست تمام فایلهای لازم Kendo UI را به صورت یکجا ملاحظه میکنید که در ابتدای head صفحه ذکر شدهاند.
- در اینجا pickDate به صورت معمولی فعال شدهاست.
- اما در قسمت kendo.init نام یک ناحیه یا نام یک کنترل را میتوان ذکر کرد. برای مثال در اینجا کل ناحیهی مشخص شده توسط یک div با id مساوی container به صورت یکجا با تمام کنترلهای داخل آن فعال گردیدهاست.
بنابراین برای اعمال declarative initialization، یک ناحیه را توسط kendo.init مشخص کرده و سپس توسط data-roleها، نام ویجت وب مورد نظر را به صورت lower case مشخص میکنیم. همچنین فایلهای اسکریپت مورد استفاده نیز نباید تداخلی داشته باشند.
تنظیمات ویجتهای وب Kendo UI
تاکنون نمونهی سادهای از بکارگیری ویجتهای وب Kendo UI را بررسی کردیم؛ اما این ویجتها توسط تنظیمات پیش بینی شده برای آنها بسیار قابل تنظیم و تغییر هستند. تنظیمات آنها نیز بستگی به روش استفاده و آغاز آنها دارد. برای مثال اگر این ویجتها را توسط کدهای جاوا اسکریپتی آغاز کردهاید، در همانجا توسط پارامترهای افزونهی جیکوئری میتوان تنظیمات مرتبط را اعمال کرد:
که در اینجا توسط پارامتر format، نحوهی دریافت تاریخ نهایی مشخص میشود.
در حالت declarative initialization، پارامتر format تبدیل به ویژگی data-format خواهد شد:
تنظیمات DataSource ویجتهای وب
بسیاری از ویجتهای وب Kendo UI با دادهها سر و کار دارند مانند Grid، Auto Complete، Combo box و غیره. این کنترلها دادههای خود را از طریق خاصیت DataSource دریافت میکنند. برای نمونه در اینجا یک combo box را در نظر بگیرید. در مثال اول، خاصیت dataSource کنترل ComboBox در همان افزونهی جیکوئری تنظیم شدهاست:
و در مثال دوم، نحوهی مقدار دهی ویژگی data-source را در حالت declarative initialization مشاهده میکنید. همانطور که عنوان شد، در این حالت ذکر متد kendo.init بر روی یک ناحیه و یا یک کنترل ویژه، جهت آغاز فعالیت آن ضروری است:
کار با رویدادهای ویجتهای وب
نحوهی کار با رویدادهای ویجتهای وب نیز بر اساس نحوهی آغاز آنها متفاوت است. در مثالهای ذیل، دو حالت متفاوت تنظیم رویداد change را توسط خواص افزونهی جیکوئری:
و همچنین توسط ویژگی data-change مشاهده میکنید:
در هر دو حالت، انتخاب یک گزینهی جدید combo box، سبب فراخوانی متد callback ایی به نام onColorChange میشود.
تغییر قالب ویجتهای وب
Kendo UI همیشه یک جفت CSS را جهت تعیین قالبهای ویجتهای خود، مورد استفاده قرار میدهد. برای نمونه در مثالهای فوق، kendo.common.min.css حاوی اطلاعات محل قرارگیری و اندازهی ویجتها است. شیوه نامهی دوم همیشه به شکل kendo.[skin].min.css تعریف میشود که دارای اطلاعات رنگ و پس زمینهی ویجتها خواهد بود؛ مانند kendo.black.min.css، kendo.blueopal.min.css و امثال آن که در پوشهی styles قابل مشاهده هستند.
همچنین باید دقت داشت که همیشه common باید پیش از skin ذکر شود؛ زیرا در تعدادی از حالات، شیوه نامهی skin، اطلاعات common را بازنویسی میکند.
علاوه بر skinهای پیش فرض موجود در پوشهی styles، امکان استفاده از یک theme builder آنلاین نیز وجود دارد: kendo-ui-themebuilder
ویجتهای وب Kendo UI مجموعهای از کنترلهای سفارشی HTML 5 هستند که برفراز jQuery تهیه شدهاند. این کنترلها برای برنامههای وب و همچنین برنامههای دسکتاپ لمسی طراحی شدهاند.
بهترین روش برای مشاهدهی این مجموعه، مراجعه به فایل examples\index.html پوشهی اصلی Kendo UI است که لیست کاملی از این ویجتها را به همراه مثالهای مرتبط ارائه میدهد. تعدادی از اعضای این مجموعه شامل کنترلهای ذیل هستند:
Window, TreeView, Tooltip, ToolBar, TimePicker, TabStrip, Splitter, Sortable, Slider, Gantt, Scheduler, ProgressBar, PanelBar, NumericTextBox, Notification, MultiSelect, Menu, MaskedTextBox, ListView, PivotGrid, Grid, Editor, DropDownList, DateTimePicker, DatePicker, ComboBox, ColorPicker, Calendar, Button, AutoComplete
نحوهی استفاده کلی از ویجتهای وب Kendo UI
با توجه به اینکه کنترلهای Kendo UI مبتنی بر jQuery هستند، نحوهی استفاده از آنها، مشابه سایر افزونههای جیکوئری است. ابتدا المانی به صفحه اضافه میشود:
<input id="pickDate" type="text"/>
<script type="text/javascript"> $(function() { $("#pickDate").kendoDatePicker(); }); </script>
<input id="dateOfBirth" type="text" data-role="datepicker" />
برای فعال سازی حالت declarative initialization باید به دو نکتهی مهم دقت داشت:
الف) در مطلب معرفی Kendo UI اسکریپتهای ذیل برای آماده سازی Kendo Ui معرفی شدند:
<!--KendoUI: Web--> <link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" /> <link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" /> <script src="js/jquery.min.js" type="text/javascript"></script> <script src="js/kendo.web.min.js" type="text/javascript"></script> <!--KendoUI: DataViz--> <link href="styles/kendo.dataviz.min.css" rel="stylesheet" type="text/css" /> <script src="js/kendo.dataviz.min.js" type="text/javascript"></script> <!--KendoUI: Mobile--> <link href="styles/kendo.mobile.all.min.css" rel="stylesheet" type="text/css" /> <script src="js/kendo.mobile.min.js" type="text/javascript"></script>
<link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" /> <link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" /> <script src="js/jquery.min.js" type="text/javascript"></script> <script src="js/kendo.all.min.js" type="text/javascript"></script>
یک مثال کامل:
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> <link href="styles/kendo.common.min.css" rel="stylesheet" type="text/css" /> <link href="styles/kendo.default.min.css" rel="stylesheet" type="text/css" /> <script src="js/jquery.min.js" type="text/javascript"></script> <script src="js/kendo.all.min.js" type="text/javascript"></script> <script type="text/javascript"> $(function () { $("#pickDate").kendoDatePicker(); }); $(function () { // initialize any widgets in the #container div kendo.init($("#container")); }); </script> </head> <body> <span> Pick a date: <input id="pickDate" type="text" /> </span> <div id="container"> <input id="dateOfBirth" type="text" data-role="datepicker" /> <div id="colors" data-role="colorpalette" data-columns="4" data-tile-size="{ width: 34, height: 19 }"></div> </div> </body> </html>
- در اینجا pickDate به صورت معمولی فعال شدهاست.
- اما در قسمت kendo.init نام یک ناحیه یا نام یک کنترل را میتوان ذکر کرد. برای مثال در اینجا کل ناحیهی مشخص شده توسط یک div با id مساوی container به صورت یکجا با تمام کنترلهای داخل آن فعال گردیدهاست.
بنابراین برای اعمال declarative initialization، یک ناحیه را توسط kendo.init مشخص کرده و سپس توسط data-roleها، نام ویجت وب مورد نظر را به صورت lower case مشخص میکنیم. همچنین فایلهای اسکریپت مورد استفاده نیز نباید تداخلی داشته باشند.
تنظیمات ویجتهای وب Kendo UI
تاکنون نمونهی سادهای از بکارگیری ویجتهای وب Kendo UI را بررسی کردیم؛ اما این ویجتها توسط تنظیمات پیش بینی شده برای آنها بسیار قابل تنظیم و تغییر هستند. تنظیمات آنها نیز بستگی به روش استفاده و آغاز آنها دارد. برای مثال اگر این ویجتها را توسط کدهای جاوا اسکریپتی آغاز کردهاید، در همانجا توسط پارامترهای افزونهی جیکوئری میتوان تنظیمات مرتبط را اعمال کرد:
<script type="text/javascript"> $(function () { $("#pickDate").kendoDatePicker({ format: "yyyy/MM/dd" }); }); </script>
در حالت declarative initialization، پارامتر format تبدیل به ویژگی data-format خواهد شد:
<input id="dateOfBirth" type="text" data-role="datepicker" data-format="yyyy/MM/dd" />
تنظیمات DataSource ویجتهای وب
بسیاری از ویجتهای وب Kendo UI با دادهها سر و کار دارند مانند Grid، Auto Complete، Combo box و غیره. این کنترلها دادههای خود را از طریق خاصیت DataSource دریافت میکنند. برای نمونه در اینجا یک combo box را در نظر بگیرید. در مثال اول، خاصیت dataSource کنترل ComboBox در همان افزونهی جیکوئری تنظیم شدهاست:
<input id="colorPicker1" /> <script type="text/javascript"> $(document).ready(function () { $("#colorPicker1").kendoComboBox({ dataSource: ["Blue", "Green", "Red", "Yellow"] }); }); </script>
<input id="colorPicker2" data-role="combobox" data-source='["Blue", "Green", "Red", "Yellow"]' /> <script type="text/javascript"> $(document).ready(function () { kendo.init($("#colorPicker2")); }); </script>
کار با رویدادهای ویجتهای وب
نحوهی کار با رویدادهای ویجتهای وب نیز بر اساس نحوهی آغاز آنها متفاوت است. در مثالهای ذیل، دو حالت متفاوت تنظیم رویداد change را توسط خواص افزونهی جیکوئری:
<input id="colorPicker3" /> <script type="text/javascript"> function onColorChange(e) { alert('Color Change!'); } $(document).ready(function () { $("#colorPicker3").kendoComboBox({ dataSource: ["Blue", "Green", "Red", "Yellow"], change: onColorChange }); }); </script>
<input id="colorPicker4" data-role="combobox" data-source='["Blue", "Green", "Red", "Yellow"]' data-change="onColorChange" /> <script type="text/javascript"> function onColorChange(e) { alert('Color Change!'); } $(document).ready(function () { kendo.init($("#colorPicker4")); }); </script>
تغییر قالب ویجتهای وب
Kendo UI همیشه یک جفت CSS را جهت تعیین قالبهای ویجتهای خود، مورد استفاده قرار میدهد. برای نمونه در مثالهای فوق، kendo.common.min.css حاوی اطلاعات محل قرارگیری و اندازهی ویجتها است. شیوه نامهی دوم همیشه به شکل kendo.[skin].min.css تعریف میشود که دارای اطلاعات رنگ و پس زمینهی ویجتها خواهد بود؛ مانند kendo.black.min.css، kendo.blueopal.min.css و امثال آن که در پوشهی styles قابل مشاهده هستند.
همچنین باید دقت داشت که همیشه common باید پیش از skin ذکر شود؛ زیرا در تعدادی از حالات، شیوه نامهی skin، اطلاعات common را بازنویسی میکند.
علاوه بر skinهای پیش فرض موجود در پوشهی styles، امکان استفاده از یک theme builder آنلاین نیز وجود دارد: kendo-ui-themebuilder
اشتراکها
سایتی رسمی TypeScript
عموما بستههای نیوگت تولید شده، قابلیت دیباگ ضعیفی را دارند. برای بالابردن بهبود تجربهی کاربری آنها میتوان توزیع فایلهای PDB و فعالسازی قابلیت Source Link را به آنها اضافه کرد.
فعالسازی توزیع فایلهای PDB به همراه بستههای NuGet
وجود فایلهای PDB، برای اجرای برنامهها ضرورتی ندارند؛ اما اگر ارائه شوند، به کمک آنها میتوان گزارشهای استثناءهای بسیار کاملتری را به همراه نام فایل و شماره سطرهای مرتبط موجود در Exception.StackTrace، مشاهده کرد.
پیشتر توسعه دهندگان بستههای NuGet، فایلهای PDB را خودشان با تعریف یک سری include در فایل مشخصات بسته، به فایل نهایی تولیدی اضافه میکردند. اما این روزها با ارائهی «NuGet.org Symbol Server»، دیگر افزودن فایلهای PDB به بستههای nupkg توصیه نمیشود. چون حجم نهایی و زمان بازیابی بستهها را بیش از اندازه افزایش میدهند؛ خصوصا اگر مصرف کنندهای قصد دیباگ آنها را نداشته باشد.
راه حل جدید توصیه شده، ارائهی فایلهای ویژهی snupkg. در کنار بستههای nupkg. معمولی است که حاوی فایلهای PDB متناظر با بستهی اصلی NuGet هستند.
برای فعالسازی آنها در پروژههای NET Core. بستههای نیوگت خود تنها کافی است دو تنظیم زیر را به فایل csproj اضافه کنید:
در این حالت پس از ساخت بستهی نیوگت توسط دستور «dotnet pack -c release»، دو فایل با پسوندهای snupkg و nupkg تولید میشوند که باید هر دو را به سایت NuGet ارسال کرد.
در سمت مصرف کننده، IDE شما باید برای کار با این Symbol Server تنظیم شده باشد.
فعالسازی تولید Source Link
وجود PDBها جهت دیباگ بستههای ارائه شده بسیار مفیدند؛ اما اگر بر روی کدهای نهایی بهینه سازی صورت گرفته باشد، ممکن است اطلاعات دیباگ آنها با کد اصلی تطابق پیدا نکنند. برای بهبود این وضعیت و ارتقاء آن به یک سطح بالاتر، مفهوم source link ارائه شدهاست که مستقل است از نوع زبان و همچنین سورس کنترل.
کار سورسلینک، افزودن متادیتای سورس کنترل انتخابی، به بستهی نهایی تولید شدهاست. به این صورت میتوان سورس کامل و متناظر با قطعه کد بسته و کتابخانهی ثالث در حال دیباگ را در IDE خود داشت و با آن به نحو متداولی کار کرد. یعنی سورس لینک، قابلیت «Step Into" the source code"» را مهیا میکند. متادیتای اضافه شده، دقیقا مشخص میکند که بستهی تولیدی نهایی، متناظر با کدام commit سورس کنترل است. به این ترتیب دقیقا میتوان به کدهای همان commit ای که بسته بر اساس آن کامپایل شدهاست، در IDE خود دسترسی یافت.
این قابلیت از Visual Studio 15.3 به بعد در اختیار کاربران آن است (گزینهی Enable Source Server Support، در قسمت Debug/General آن باید فعال شود). همچنین Rider و VSCode نیز از آن پشتیبانی میکنند. برای Rider باید در قسمت Tools/External symbols، گزینههای Use sources from symbol files when available و Allow downloading symbols from remote locations را فعال کنید.
همچنین برای فعالسازی آن در فایل csproj بستهی نیوگت خود میتوانید تنظیمات زیر را اضافه کنید:
البته در اینجا پروایدر مخصوص GitHub را مشاهده میکنید (اگر مخزن کد بستهی شما بر روی آن قرار دارد) و همچنین سایر پروایدرهای مخصوص سورس کنترلهای دیگر مانند Azure DevOps/VSTS نیز برای آن تهیه شدهاند.
روش فعالسازی Source Link در پروژهی VSCode
اگر از VSCode استفاده میکنید، نیاز است تنظیمات زیر را به قسمت configurations فایل launch.json خود اضافه کنید تا قابلیت «Step Into" the source code"» بستههای نیوگتی که از SourceLink پشتیبانی میکنند، با فشردن دکمهی F11 در حین دیباگ، فعال شود:
فعالسازی توزیع فایلهای PDB به همراه بستههای NuGet
وجود فایلهای PDB، برای اجرای برنامهها ضرورتی ندارند؛ اما اگر ارائه شوند، به کمک آنها میتوان گزارشهای استثناءهای بسیار کاملتری را به همراه نام فایل و شماره سطرهای مرتبط موجود در Exception.StackTrace، مشاهده کرد.
پیشتر توسعه دهندگان بستههای NuGet، فایلهای PDB را خودشان با تعریف یک سری include در فایل مشخصات بسته، به فایل نهایی تولیدی اضافه میکردند. اما این روزها با ارائهی «NuGet.org Symbol Server»، دیگر افزودن فایلهای PDB به بستههای nupkg توصیه نمیشود. چون حجم نهایی و زمان بازیابی بستهها را بیش از اندازه افزایش میدهند؛ خصوصا اگر مصرف کنندهای قصد دیباگ آنها را نداشته باشد.
راه حل جدید توصیه شده، ارائهی فایلهای ویژهی snupkg. در کنار بستههای nupkg. معمولی است که حاوی فایلهای PDB متناظر با بستهی اصلی NuGet هستند.
برای فعالسازی آنها در پروژههای NET Core. بستههای نیوگت خود تنها کافی است دو تنظیم زیر را به فایل csproj اضافه کنید:
<PropertyGroup> <IncludeSymbols>true</IncludeSymbols> <SymbolPackageFormat>snupkg</SymbolPackageFormat> </PropertyGroup>
در سمت مصرف کننده، IDE شما باید برای کار با این Symbol Server تنظیم شده باشد.
فعالسازی تولید Source Link
وجود PDBها جهت دیباگ بستههای ارائه شده بسیار مفیدند؛ اما اگر بر روی کدهای نهایی بهینه سازی صورت گرفته باشد، ممکن است اطلاعات دیباگ آنها با کد اصلی تطابق پیدا نکنند. برای بهبود این وضعیت و ارتقاء آن به یک سطح بالاتر، مفهوم source link ارائه شدهاست که مستقل است از نوع زبان و همچنین سورس کنترل.
کار سورسلینک، افزودن متادیتای سورس کنترل انتخابی، به بستهی نهایی تولید شدهاست. به این صورت میتوان سورس کامل و متناظر با قطعه کد بسته و کتابخانهی ثالث در حال دیباگ را در IDE خود داشت و با آن به نحو متداولی کار کرد. یعنی سورس لینک، قابلیت «Step Into" the source code"» را مهیا میکند. متادیتای اضافه شده، دقیقا مشخص میکند که بستهی تولیدی نهایی، متناظر با کدام commit سورس کنترل است. به این ترتیب دقیقا میتوان به کدهای همان commit ای که بسته بر اساس آن کامپایل شدهاست، در IDE خود دسترسی یافت.
این قابلیت از Visual Studio 15.3 به بعد در اختیار کاربران آن است (گزینهی Enable Source Server Support، در قسمت Debug/General آن باید فعال شود). همچنین Rider و VSCode نیز از آن پشتیبانی میکنند. برای Rider باید در قسمت Tools/External symbols، گزینههای Use sources from symbol files when available و Allow downloading symbols from remote locations را فعال کنید.
همچنین برای فعالسازی آن در فایل csproj بستهی نیوگت خود میتوانید تنظیمات زیر را اضافه کنید:
<PropertyGroup> <PublishRepositoryUrl>true</PublishRepositoryUrl> <EmbedUntrackedSources>true</EmbedUntrackedSources> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0" PrivateAssets="All" /> </ItemGroup>
روش فعالسازی Source Link در پروژهی VSCode
اگر از VSCode استفاده میکنید، نیاز است تنظیمات زیر را به قسمت configurations فایل launch.json خود اضافه کنید تا قابلیت «Step Into" the source code"» بستههای نیوگتی که از SourceLink پشتیبانی میکنند، با فشردن دکمهی F11 در حین دیباگ، فعال شود:
"justMyCode": false, "symbolOptions": { "searchMicrosoftSymbolServer": true }, "suppressJITOptimizations": true, "env": { "COMPlus_ZapDisable": "1" }