Data Dictionary در C#.NET
خواندن و نوشتن فایل CSV در #C
var excel = new ExcelQueryFactory(pathToExcelFile); string sheetName = "Sheet1"; var persons = from a in excel.WorksheetNoHeader(sheetName) where a[1] == "Mashhad" //مقدار در ستون دوم select a; foreach (var a in persons) { for(int i=0;i<a.Count;i++) MessageBox.Show(a[i]); }
<head> @*سایر شیوه نامهها و اسکریپت ها*@ @RenderSection("styles", required: false) </head>
namespace DynamicCssExample.Controllers { public class HomeController : Controller { public ActionResult Index() { return View(); } public string GetStyle() { Response.ContentType = "text/css"; //در این قسمت میتوانیم به دیتابیس متصل شویم و شیوه نامهی مورد نظر را واکشی کنیم و بازگشت دهیم return "h2{color:yellow}"; } } }
@{ ViewBag.Title = "Index"; Layout = "~/Views/Shared/_Layout.cshtml"; } @section styles { <link rel="stylesheet" href="@Url.Action("GetStyle", "Home")" type="text/css"/> } <h2>Index</h2>
مثال این مطلب : DynamicCssExample.zip به همراه بازسازی کامل پوشه packages بستههای NuGet به صورت خودکار
Exception و خوانایی کد
تکه کد زیر را در نظر بگیرید: یک Action معمولی در Asp.Net MVC که یک نام را دریافت کرده و یک کارمندرا ایجاد میکند:
public ActionResult CreateEmployee(string name) { try { ValidateName(name); // ادامه کدها return View("با موفقیت ثبت شد"); } catch (ValidationException ex) { return View("خطا", ex.Message); } } private void ValidateName(string name) { if (string.IsNullOrWhiteSpace(name)) throw new ValidationException("نام نمیتواند خالی باشد"); if (name.Length > 100) throw new ValidationException("نام نمیتواند طولانی باشد"); }
در این قطعه کد، در متد ValidateName، در صورت معتبر نبودن ورودی، یک Exception رخ میدهد و بلاک کد try/catch، این exception را دریافت کرده و خطای مناسبی را به کاربر نشان خواهد داد. تا اینجا ظاهرا همه چیز مرتب است و مشکلی ندارد! احتمالا کدهای مشابه به این کد را زیاد دیدهاید. در اینجا متد ValidateName، صادق نیست. در قسمت اول، در مورد Honesty صحبت کردیم. به عبارت سادهتر شما از امضای این متد نمیتوانید به نوع خروجی و کاری که قرار است انجام دهد، پی ببرید. در واقع شما همیشه باید پیاده سازی متد را گوشهای، در ذهن خود داشته باشید و برای اطمینان از کاری که متد انجام میدهد، همیشه باید به بدنهی متد برگردیم. اگر بهخاطر داشته باشید، توابع برنامه نویسی را به توابع ریاضی تشبیه کردیم. پس میتوانیم بگوییم:
به عبارت دیگر وقتی از exceptionها برای کنترل flow برنامه استفاده میکنید، مشابه کاری را انجام میدهید که دستور GOTO انجام میداد. این دستور در روشهای قبل از برنامه نویسی ساخت یافته وجود داشت و توسط یک دانشمند هلندی به نام آقای دیکسترا حذف شد. وقتی از دستور GOTO یا JUMP استفاده میکنیم، فهمیدن flow برنامه پیچیدگیهای زیادی را خواهد داشت. چراکه فراخوانی قطعههای کد و متدها، وابستگی شدیدی خواهند داشت و البته میتوان گفت استفاده از exceptionها برای کنترل جریان برنامه، میتوانند از GOTO هم بدتر باشند؛ چرا که exception میتواند از لایههای مختلف کد نیز عبور کند.
امیدوارم تا اینجا به یک عقیدهی مشترک رسیده باشیم. خوب راهکار چیست؟ تصور کنید که تکه کد بالا را به صورت زیر تبدیل کنیم:
public ActionResult CreateEmployee(string name) { string error = ValidateName(name); if (error != string.Empty) return View("خطا", error); // ادامه کدها return View("با موفقیت ثبت شد"); } private string ValidateName(string name) { if (string.IsNullOrWhiteSpace(name)) return "نام نمیتواند خالی باشد"; if (name.Length > 100) return "طول نام نمیتواند بیشتر از 100 کاراکتر باشد"; return string.Empty; }
با refactor ای که انجام دادیم، متد ValidateName را به یک تابع ریاضی تبدیل کردیم. به این معنا که هر آنچه را که از امضای متد، مشخص است، انجام میدهد و در این حالت چیزی مخفی نیست. توجه داشته باشید که این راهکار نهایی ما نیست و لطفا مقاله را تا انتها بخوانید!
موارد استفاده Exception
با همهی بدیهایی که از Exceptionها گفتیم، با این حساب پس چه زمانی از آن استفاده کنیم؟
- Exceptionها واقعا برای موارد استثنائی هستند.
- Exceptionها برای شرایطی هستند که به معنای واقعی یک باگ باشند.
- منتظر رخ دادن Exception نباشیم!
در توضیح مورد سوم، در اعتبار سنجی دادههای کاربر (Validation) انتظار دادهی نادرستی را میتوان داشت، پس نمیتوانیم آن را یک حالت استثنایی بدانیم. معماری زیر را در نظر بگیرید
دیتایی که به API ما ارسال خواهد شد، همیشه شامل عملیات Filter یا به عبارتی Validation است و از آنجایی که میتوان انتظار استفادهی نادرست یا دیتای نادرست را داشت، نمیتوانیم این را حالتی از استثنائات در نظر بگیریم؛ ولی بر خلاف آن، وقتی در دامین پروژه و ارتباط بین دامینهای مختلف، دیتایی رد و بدل میشود که معتبر نیست، میتوانیم آن را جزء استثناءها در نظر بگیریم. به مثال زیر دقت کنید:
public ActionResult UpdateEmployee(int employeeId, string name) { string error = ValidateName(name); if (error != string.Empty) return View("Error", error); Employee employee = GetEmployee(employeeId); employee.UpdateName(name); } public class Employee { public void UpdateName(string name){ if (name == null) throw new ArgumentNullException(); // ادامه کدها } }
در قطعه کد بالا تصور این است که کلاس Employee و متد UpdateName خارج از دامین میباشند. همانطورکه مشاهده میکنید، ما در action controller، از خالی نبودن نام اطمینان حاصل کردیم و سپس آن را به متد UpdateName ارجاع دادیم. ولی اگه به بدنهی متد UpdateName دقت کنید، میبینید که مجددا از خالی نبودن نام اطمینان حاصل کردهایم و در صورت خالی بودن، یک Exception را صادر میکنیم! به این مدل چک کردنها در دامینهای مختلف، معمولا guard clause گفته میشود و یک نوع قرارداد بین برنامه نویس هاست. اگر طبق تعریفی که بالاتر ارائه کردیم هم چک کنیم، میتوانیم حدس بزنیم که خالی بودن نام، نشان یک باگ در نرم افزار است!
مفهوم fail fast
تا اینجا متوجه شدیم که از exceptionها باید در شرایط استثنائی استفاده کنیم. خوب با توجه به این مساله، چه طور میتوانیم آنها را Handle کنیم؟ این سؤال ما را به مفهومی به نام fail fast میرساند. این مفهوم به ما میگوید:
- کار جاری را به محض یک اتفاق استثنائی باید متوقف کنیم.
- رعایت این نکته در نهایت ما را به یک نرم افزار پایدار خواهد رساند.
برای درک هر چه بهتر این موضوع، بیایید به عکس این حالت نگاه کنیم؛ اصطلاحا Fail Silently.
متد زیر را ببینید:
public void ProcessItems(List<Item> items) { foreach (Item item in items) { try { Process(item); } catch (Exception ex) { Logger.Log(ex); } } }
در قطعه کد بالا، در نگاه اول احتمالا حس نرم افزار پایدارتر و بدون خطا را خواهیم داشت. اما در واقع اینطور نیست. احتمال اینکه خطا از چشم برنامه نویس به دور باشد و بعد از اجرا باعث شود که یکپارچگی دادهها را به هم بریزد وجود دارد. در واقع هیچ راهی برای زمانیکه این عملیات نباید انجام شود، در نظر گرفته نشدهاست. طبق صحبتهایی که بالاتر داشتیم، شرایط غیر منتظره، در واقع یک باگ در نرم افزار است و هیچ مزیتی در جلوگیری از وقوع این باگ بدون حل مشکل نیست!
به صور خلاصه مهمترین مزیت Fail Fast را میتوانیم به صورت زیر خلاصه کنیم:
- مسیر رسیدن به خطاها سر راستتر میشود.
- نرم افزار به پایداری مناسبی خواهد رسید.
- از اعتبار دیتای ذخیره شده اطمینان خواهیم داشت.
کجا exceptionها را به دام بیندازیم؟
در یکی از حالتهای زیر:
- لاگ کردن
- متوقف کردن عملیات
- هیچ گاه در بلاک catch هیچ منطقی را پیاده نکنید.
حالت دیگر در استفاه از کتابخانههای دیگران (3rd parties) است. به طور مثال در استفاده از EF ممکن است به دلیل عدم برقراری ارتباط با دیتابیس، خطایی را دریافت کنید. در این حالت با توجه به نکات فوق، با این استثنائات برخورد کنید:
- جلوی این نوع استثنائات را در پایینترین حد ممکن در کد خود بگیرید.
- Exception هایی را catch کنید که میدانید در حالت استثناء، چه کاری را میتوانید انجام دهید.
این به این معنی میباشد که به صورت کلی همه نوع Exception ای را به صورت کلی نگیرید و نوع Exception اختصاصی را در بلاک catch قرار دهید. الان که قرار شد در بعضی از حالتها جلوی استثنائات را بگیریم، خوب است ببینیم چطور باید اینکار را انجام بدیم.
قطعه کد زیر را در نظر بگیرید:
public void CreateCustomer(string name) { Customer customer = new Customer(name); bool result = SaveCustomer(customer); if (!result) { MessageBox.Show("Error connecting to the database. Please try again later."); } } private bool SaveCustomer(Customer customer) { try { using (MyContext context = new MyContext()) { context.Customers.Add(customer); context.SaveChanges(); } return true; } catch (DbUpdateException ex) { if (ex.Message == "Unable to open the DB connection") return false; else throw; } }
همانطور که مشاهده میکنید، در حالتیکه خطایی از نوع DbUpdateException رخ میدهد، مقدار بازگشتی متد را برابر با false میکنیم. اما مشکلی که وجود دارد این است که اینکار به اندازهی کافی خوانا نیست. همچنین honest بودن متد را نقض کردهایم. به علاوه مشکل بزرگتر دیگر این است که ما با بازگرداندن یک مقدار bool، میتوانیم به متد بالاتر اطلاع بدهیم که کار مورد نظر انجام شده یا نه، اما در مورد دلیل انجام نشدن آن، هیچ کاری نمیتوانیم بکنیم. پیشنهاد من برای مقدار بازگشتی متدهایی که احتمال انجام نشدن کاری در آنها میرود، استفاده از یک نوع اختصاصی میباشد.
در اینجا من این نوع را با نام کلاس Result معرفی میکنم. انتظاری که از این نوع اختصاصی داریم:
- Honest بودن متد را نگه دارد.
- خروجی متد را به همراه وضعیت اجرا شدن برگرداند.
- شکل یکسانی را برای خطاها داشته باشد.
- فقط جلوی خطاهای غیر منتظره را بگیرد.
برای مثال کد بالا را به شکل زیر refactor میکنیم:
private Result SaveCustomer(Customer customer) { try { using (var context = new MyContext()) { context.Customers.Add(customer); context.SaveChanges(); } return Result.Ok(); } catch (DbUpdateException ex) { if (ex.Message == "Unable to open the DB connection") Result.Fail(ErrorType.DatabaseIsOffline); if (ex.Message.Contains("IX_Customer_Name")) return Result.Fail(ErrorType.CustomerAlreadyExists); throw; } }
به عبارتی با این روش میتوانیم از انجام شدن/نشدن عملیات اطمینان حاصل کنیم و خروجی/دلیل انجام نشدن را نیز میتوانیم برگردانیم.
اگر به امضای متدهای زیر نگاه کنیم، میتوانیم آنها را طبق الگوی CQS دستهبندی کنیم:
به عنوان نمونه یک پیاده سازی از این کلاس را در اینجا قرار دادهام. قطعا میتوانیم پیاده سازیهای بهتری را از این کلاس داشته باشیم. خوشحال میشوم که نظرات خود رو با ما به اشتراک بگذارید. امیدوارم که این قسمت و صحبتهایی که در مورد استثنائات داشتیم، توانسته باشد دیدگاه جدیدی را به کدهایتان بدهد. در ادامهی این سری مطالب، مفاهیم پارادایم برنامه نویسی تابعی را بیشتر مورد بررسی قرار خواهیم داد.
خوب، تا اینجا ممکن است مشکلی به نظر نرسد و هدف از کش کردن اطلاعات یک اکشن متد نیز همین مورد است. اما اگر این اکشن متد کش شده، به اشتباه در یک کنترلر مزین شده با ویژگی Authorize قرار گیرد، چه خواهد شد؟ مثلا این کنترلر امن، برای ارائه فایلها یا حتی نمایش قسمتی از صفحه یا کل صفحه، از کش استفاده کرده است. در بار اول دریافت فایل، بدیهی است که تمام مسایل اعتبارسنجی باید مطابق طول عمر یک کنترلر روی دهند. اما در بار دوم فراخوانی آدرس دریافت صفحه یا فایل، اصلا کار به فراخوانی کنترلر نمیرسد. به عبارتی کلیه کاربران سایت (اعم از لاگین شده، نشده، دارای دسترسی مشاهده صفحه یا آدرس امن و یا بدون دسترسی)، به این محتوای خاص بدون مشکلی دسترسی خواهند داشت (فقط کافی است که از آدرس نهایی به نحوی مطلع شوند).
سؤال: چگونه میتوان کلیه اکشن متدهای یک پروژه ASP.NET MVC را که دارای ویژگی OutputCache در یک کنترلر امن هستند، یافت؟
using System; using System.Linq; using System.Reflection; // Add a ref. to \Program Files\Microsoft ASP.NET\ASP.NET MVC 4\Assemblies\System.Web.Mvc.dll using System.Web.Mvc; // Add a ref. to System.Web using System.Web.UI; namespace FindOutputCaches { class Program { static void Main(string[] args) { var path = @"D:\site\bin\Web.dll"; var asmTarget = Assembly.LoadFrom(path); checkSecuredControllers(asmTarget); Console.WriteLine("Press a key..."); Console.Read(); } private static void checkSecuredControllers(Assembly asmTarget) { // یافتن کلیه کنترلرهایی که فیلتر اوتورایز دارند var securedControllers = asmTarget.GetTypes() .Where(type => typeof(IController).IsAssignableFrom(type) && Attribute.IsDefined(type, typeof(AuthorizeAttribute)) && !type.Name.StartsWith("T4MVC")) .ToList(); foreach (var controller in securedControllers) { // یافتن کلیه اکشن متدهای کنترلر جاری var actionMethods = controller.GetMethods(BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly) .Where(method => typeof(ActionResult).IsAssignableFrom(method.ReturnType)) .ToList(); foreach (var method in actionMethods) { // یافتن متدهایی که دارای آوت پوت کش هستند var attributes = method.GetCustomAttributes(typeof(OutputCacheAttribute), true); if (attributes == null || !attributes.Any()) continue; var outputCache = (OutputCacheAttribute)attributes[0]; // AllowMultiple = false if (outputCache.Location == OutputCacheLocation.None) continue; //سبب عدم کش شدن شده است؛ مثلا برای کارهای ایجکسی Console.WriteLine("Detected incorrect usage of OutputCache in:\n {0}-->{1}", controller.FullName, method.Name); } } } } }
ابتدا مسیر اسمبلی کامپایل شده پروژه ASP.NET MVC که حاوی کنترلرهای برنامه است، باید مشخص گردد.
سپس در این اسمبلی کلیه نوعهای تعریف شده، یافت گردیده و آنهایی که پیاده سازی کننده IController هستند (یعنی کلاسهای کنترلر واقعی برنامه) و همچنین دارای ویژگی AuthorizeAttribute نیز میباشند، جدا خواهند شد.
در ادامه، در هر کنترلر امن یافت شده، متدهایی را بررسی خواهیم کرد که دارای خروجی از نوع ActionResult باشند (فقط اکشن متدها مدنظر هستند). اگر این اکشن متد یافت شده دارای ویژگی OutputCacheAttribute بود و همچنین Location آن به None تنظیم نشده بود ... یعنی مشکل امنیتی وجود دارد که باید برطرف شود.
البته برای تکمیل این مطلب باید دو حالت زیر هم پیاده سازی و بررسی شوند:
- کلیه Viewهای برنامه بررسی شوند. اگر در View خاصی که متعلق است به یک کنترلر یا حتی اکشن متد امن، ارجاعی به اکشن متدی کش شده در کنترلری دیگر وجود داشت، این مورد هم یک باگ امنیتی است.
- کلیه کنترلرهای عمومی که دارای اکشن متدی امن هستند نیز باید جهت یافتن OutputCache بررسی شوند.
تغییرات مورد نیاز سمت کلاینت جهت فعال سازی جستجو در jqGrid
در سمت کلاینت، در حین تعریف ستونها، ابتدا باید توسط مقدار دهی خاصیت search، ستونهای مشارکت کنندهی در حین جستجو را مشخص کرد:
colModel: [ { name: 'Name', index: 'Name', align: 'right', width: 200, search: true, stype: 'text', searchoptions: { sopt: searchOptions } }, { name: 'Supplier.Id', index: 'Supplier.Id', align: 'right', width: 200, search: true, stype: 'select', edittype: 'select', searchOperators: true, searchoptions: { sopt: searchOptions, dataUrl: '@Url.Action("SuppliersSelect","Home")' } } ],
- stype، روش مقایسهی مقادیر را مشخص میکند. مقدار پیش فرض آن text است و مقادیری مانند int، integer، float، number، numeric، date و datetime را میپذیرد.
- searchoptions برای تنظیم جزئیات نحوهی جستجوی بر روی فیلدها بکار میرود. توسط sopt میتوان آرایهای با مقادیر ذیل را مقدار دهی کرد:
var searchOptions = ['eq', 'ne', 'lt', 'le', 'gt', 'ge', 'bw', 'bn', 'in', 'ni', 'ew', 'en', 'cn', 'nc'];
البته باید دقت داشت که آرایه فوق کاملترین حالت ممکن است و ضرورتی ندارد تمام حالات را برای یک فیلد تعریف کرد. چون برای مثال جستجو cn یا contains برای مقادیر رشتهای معنا دارد و نه سایر حالات.
- searchoptions گزینههای دیگری را نیز میتواند شامل شود. برای مثال در حین نمایش جستجوی داخل ردیفی یا صفحهی دیالوگ مخصوص آن، قصد داریم فیلد نام تولید کننده را توسط یک drop down نمایش دهیم و نه یک text box پیش فرض. برای این منظور dataUrl مقدار دهی شدهاست.
SuppliersSelect آن به اکشن متد ذیل اشاره میکند که لیست تولید کنندگان را با فرمت لیستی از SelectListItemها به یک partial view تولید کنندهی دراپ داون ارسال میکند:
public ActionResult SuppliersSelect() { var list = ProductDataSource.LatestProducts; var suppliers = list.Select(x => new SelectListItem { Text = x.Supplier.CompanyName, Value = x.Supplier.Id.ToString(CultureInfo.InvariantCulture) }).ToList(); return PartialView("_SelectPartial", suppliers); }
@model IList<SelectListItem> @Html.DropDownList("srch", Model)
- اگر دقت کرده باشید، نام فیلد تولید کننده با Supplier.Id مقدار دهی شدهاست. علت اینجا است که در زمان استفاده از drop down، مقدار Id آیتم انتخابی، به سرور ارسال میشود. به همین جهت کار کردن پویا با Supplier.Id سادهتر خواهد بود.
- برای نمایش دیالوگ و یا نوار ابزار توکار جستجو، میتوان دکمههایی را به فوتر گرید اضافه کرد:
$(document).ready(function () { $('#list').jqGrid({ // ... مانند قبل و توضیحات فوق }) .jqGrid('navGrid', '#pager', { add: false, edit: false, del: false }, {}, // default settings for edit {}, // default settings for add {}, // delete instead that del:false we need this { // search options multipleSearch: true, closeOnEscape: true, closeAfterSearch: true, ignoreCase: true }) .jqGrid('navButtonAdd', "#pager", { caption: "نوار ابزار جستجو", title: "Search Toolbar", buttonicon: 'ui-icon-search', onClickButton: function () { toolbarSearching(); } }); }); function toolbarSearching() { $('#list').filterToolbar({ groupOp: 'OR', defaultSearch: "cn", autosearch: true, searchOnEnter: true, searchOperators: true, // فعال سازی منوی اپراتورها stringResult : true // وجود این سطر سبب میشود تا اپراتورها به سرور ارسال شوند }); }; function singleSearching() { $('#list').searchGrid({ closeAfterSearch: true }); }; function advancedSearching() { $('#list').searchGrid({ multipleSearch: true, closeAfterSearch: true }); };
- با استفاده از متد jqGrid و پارامتر navGrid، در ناحیهی pager گرید، تنظیمات جستجو را فعال کردهایم.
multipleSearch به معنای امکان جستجوی همزمان بر روی بیش از یک فیلد است. closeOnEscape سبب بسته شدن صفحهی دیالوگ جستجو با فشردن دکمهی ESC میشود. اگر closeAfterSearch به true تنظیم نشود، صفحهی دیالوگ جستجو پس از جستجو، در صفحه باقی مانده و بسته نخواهد شد.
- این دکمهی جستجو، جزو موارد توکار jqGrid است. اگر قصد داشته باشیم یک دکمهی سفارشی دیگر را نیز اضافه کنیم، مجددا از متد jqGrid با پارامتر navButtonAdd در ناحیهی pager استفاده خواهیم کرد. کلیک بر روی آن سبب اجرای متد toolbarSearching میشود.
در اینجا حداقل سه نوع جستجو را میتوان فعال کرد:
- filterToolbar که سبب نمایش نوار ابزار جستجو، دقیقا بالای ستونهای جدول میشود.
- searchGrid که صفحهی دیالوگ مستقلی را جهت جستجو به صورت پویا تولید میکند. اگر خاصیت multipleSearch آن به true تنظیم نشود، این جستجو هربار تنها بر روی یک فیلد قابل انجام خواهد بود و برعکس.
- در حالت جستجوی نوار ابزاری، اگر خواص searchOperators و stringResult به true تنظیم شوند، مانند تصویر ذیل، به ازای هر ستون میتوان از عملگرهای مختلفی استفاده کرد. در غیراینصورت جستجوی انجام شده بر اساس groupOp و defaultSearch پیش فرض انجام میشود. یعنی And یا Or تمام موارد تنها در حالت مثلا contains یا تساوی و امثال آن و نه حالت پیشرفتهی انتخاب عملگرها توسط کاربر.
یک نکته
اگر میخواهید صفحهی جستجو در وسط صفحه ظاهر شود، میتوانید از تنظیمات CSS ذیل استفاده کنید:
/* align center search popup in jqgrid */ .ui-jqdialog { display: none; width: 300px; position: absolute; padding: .2em; font-size: 11px; overflow: visible; left: 30% !important; top: 40% !important; }
پردازش سمت سرور جستجوی پویای jqGrid
کدهای سمت سرور، با کدهای استفاده از dynamic LINQ مایکروسافت یکی است. با این تفاوت که اینبار قسمت where این کوئری نیز پویا میباشد. پیشتر قسمت order by را پویا پردازش کرده بودیم. برای ساخت where پویا که در dynamic LINQ به خوبی پشتیبانی میشود، باید ابتدا ساختار اطلاعات ارسالی به سرور را آنالیز کنیم:
//single field search //_search=true&nd=1403935889318&rows=10&page=1&sidx=Id&sord=asc&searchField=Id&searchString=4444&searchOper=eq&filters= //multi-field search //_search=true&nd=1403935941367&rows=10&page=1&sidx=Id&sord=asc&filters=%7B%22groupOp%22%3A%22AND%22%2C%22rules%22%3A%5B%7B%22field%22%3A%22Id%22%2C%22op%22%3A%22eq%22%2C%22data%22%3A%2244%22%7D%2C%7B%22field%22%3A%22SupplierID%22%2C%22op%22%3A%22eq%22%2C%22data%22%3A%221%22%7D%5D%7D&searchField=&searchString=&searchOper= // filters -> {"groupOp":"AND","rules":[{"field":"All","op":"cn","data":"fffff"},{"field":"Price","op":"bn","data":"ffff"}]} //toolbar search //_search=true&nd=1403935593036&rows=10&page=1&sidx=Id&sord=asc&Id=2&Name=333&SupplierID=1&CategoryID=1&Price=44
- در تمام این حالات پارامتر _search مساوی true است (تفاوت آن با درخواست اطلاعات معمولی).
- در حالت جستجوی نوار ابزاری، اگر گزینههای searchOperators و stringResult به true تنظیم نشوند، حالت toolbar search فوق را شاهد خواهیم بود. در غیراینصورت به حالت multi-field search سوئیچ میشود.
- در حالت جستجوی تک فیلدی توسط صفحه دیالوگ جستجوی jqGrid، فیلد در حال جستجو توسط searchField و مقدار آن توسط searchString به سرور ارسال شدهاند. مابقی پارامترها نال هستند.
- در حالت جستجوی چند فیلدی توسط صفحه دیالوگ جستجوی jqGrid، اینبار filters مقدار دهی شدهاست و سایر پارامترها نال هستند. مقدار filters ارسالی، در حقیقت یک شیء JSON است با ساختار کلی ذیل:
{ "groupOp": "AND", "groups" : [ { "groupOp": "OR", "rules": [ { "field": "name", "op": "eq", "data": "England" }, { "field": "id", "op": "le", "data": "5"} ] } ], "rules": [ { "field": "name", "op": "eq", "data": "Romania" }, { "field": "id", "op": "le", "data": "1"} ] }
public class SearchFilter { public string groupOp { set; get; } public List<SearchGroup> groups { set; get; } public List<SearchRule> rules { set; get; } } public class SearchRule { public string field { set; get; } public string op { set; get; } public string data { set; get; } public override string ToString() { return string.Format("'{0}' {1} '{2}'", field, op, data); } } public class SearchGroup { public string groupOp { set; get; } public List<SearchRule> rules { set; get; } }
اگر این موارد را کنار هم قرار دهیم، به متدی عمومی ApplyFilter با امضای ذیل خواهیم رسید.
public IQueryable<T> ApplyFilter<T>(IQueryable<T> query, bool _search, string searchField, string searchString, string searchOper, string filters, NameValueCollection form)
پس از آن، تغییراتی که در کدهای متد GetProducts باید اعمال شوند به صورت ذیل است:
[HttpPost] public ActionResult GetProducts(string sidx, string sord, int page, int rows, bool _search, string searchField, string searchString, string searchOper, string filters) { var list = ProductDataSource.LatestProducts; var pageIndex = page - 1; var pageSize = rows; var totalRecords = list.Count; var totalPages = (int)Math.Ceiling(totalRecords / (float)pageSize); var productsQuery = list.AsQueryable(); productsQuery = new JqGridSearch().ApplyFilter(productsQuery, _search, searchField, searchString, searchOper, filters, this.Request.Form); var productsList = productsQuery.OrderBy(sidx + " " + sord) .Skip(pageIndex * pageSize) .Take(pageSize) .ToList(); var productsData = new JqGridData { Total = totalPages, Page = page, Records = totalRecords, Rows = (productsList.Select(product => new JqGridRowData { Id = product.Id, RowCells = new List<string> { product.Id.ToString(CultureInfo.InvariantCulture), product.Name, product.Supplier.CompanyName, product.Category.Name, product.Price.ToString(CultureInfo.InvariantCulture) } })).ToArray() }; return Json(productsData, JsonRequestBehavior.AllowGet); }
- نوع متد به HttpPost تغییر کردهاست. این مورد برای ارسال اطلاعات حجیم جستجوها به سرور ضروری است و بهتر است از حالت Get استفاده نشود.
این حالت در سمت کلاینت نیز باید تنظیم شود:
$('#list').jqGrid({ //url access method type mtype: 'POST',
productsQuery = new JqGridSearch().ApplyFilter(productsQuery, _search, searchField, searchString, searchOper, filters, this.Request.Form);
برای مطالعه بیشتر
جستجوی تک فیلدی
جستجوی نوار ابزاری
جستجوی چند فیلدی
کدهای کامل این مثال را از اینجا میتوانید دریافت کنید
jqGrid03.zip
پیشنیازهای سمت سرور
- ابتدا یک پروژهی خالی ASP.NET را ایجاد کنید. نوع آن مهم نیست که Web Forms باشد یا MVC.
- سپس قصد داریم مدل کاربران سیستم را توسط یک ASP.NET Web API Controller در اختیار Ember.js قرار دهیم. مباحث پایهای Web API نیز در وب فرمها و MVC یکی است.
مدل سمت سرور برنامه چنین شکلی را دارد:
namespace EmberJS02.Models { public class User { public int Id { set; get; } public string UserName { set; get; } public string Email { set; get; } } }
using System.Collections.Generic; using System.Web.Http; using EmberJS02.Models; namespace EmberJS02.Controllers { public class UsersController : ApiController { // GET api/<controller> public IEnumerable<User> Get() { return UsersDataSource.UsersList; } } }
همچنین فرض بر این است که مسیریابی سمت سرور ذیل را نیز به فایل global.asax.cs، جهت فعال سازی دسترسی به متدهای کنترلر UsersController تعریف کردهاید:
using System; using System.Web.Http; using System.Web.Routing; namespace EmberJS02 { 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 } ); } } }
پیشنیازهای سمت کاربر
پیشنیازهای سمت کاربر این قسمت با قسمت «تهیهی اولین برنامهی Ember.js» دقیقا یکی است.
ابتدا فایلهای مورد نیاز Ember.js به برنامه اضافه شدهاند:
PM> Install-Package EmberJS
App = Ember.Application.create(); App.IndexRoute = Ember.Route.extend({ setupController:function(controller) { controller.set('content', ['red', 'yellow', 'blue']); } });
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <title></title> <script src="Scripts/jquery-2.1.1.js" type="text/javascript"></script> <script src="Scripts/handlebars.js" type="text/javascript"></script> <script src="Scripts/ember.js" type="text/javascript"></script> <script src="Scripts/app.js" type="text/javascript"></script> </head> <body> <script type="text/x-handlebars" data-template-name="application"> <h1>Header</h1> {{outlet}} </script> <script type="text/x-handlebars" data-template-name="index"> Hello, <strong>Welcome to Ember.js</strong>! <ul> {{#each item in content}} <li> {{item}} </li> {{/each}} </ul> </script> </body> </html>
در ادامه قصد داریم به هدر صفحه، دو لینک Home و About را اضافه کنیم؛ به نحوی که لینک Home به مسیریابی index و لینک About به مسیریابی about که صفحهی جدید «دربارهی برنامه» را نمایش میدهد، اشاره کنند.
تعریف صفحهی جدید About
برنامههای Ember.js، برنامههای تک صفحهای وب هستند و صفحات جدید در آنها به صورت یک template جدید تعریف میشوند که نهایتا متناظر با یک مسیریابی مشخص خواهند بود.
به همین جهت ابتدا در فایل app.js مسیریابی about را اضافه خواهیم کرد:
App.Router.map(function() { this.resource('about'); });
بنابراین به صفحهی index.html برنامه مراجعه کرده و صفحهی about را توسط یک قالب جدید تعریف میکنیم:
<script type="text/x-handlebars" data-template-name="about"> <h2>Our about page</h2> </script>
در این حالت اگر برنامه را در حالت معمولی اجرا کنید، خروجی خاصی را مشاهده نخواهید کرد. بنابراین نیاز است تا لینکی را جهت اشاره به این مسیر جدید به صفحه اضافه کنیم:
<script type="text/x-handlebars" data-template-name="application"> <h1>Ember Demo App</h1> <ul class="nav"> <li>{{#linkTo 'index'}}Home{{/linkTo}}</li> <li>{{#linkTo 'about'}}About{{/linkTo}}</li> </ul> {{outlet}} </script>
در اینجا با استفاده از امکان یا directive ویژهای به نام linkTo، لینکهایی به مسیریابیهای index و about اضافه شدهاند. به این ترتیب اگر کاربری برای مثال بر روی لینک About کلیک کند، کتابخانهی Ember.js او را به صورت خودکار به مسیریابی about و سپس نمایش قالب مرتبط با آن (قالب about ایی که پیشتر تعریف کردیم) هدایت خواهد کرد؛ مانند تصویر ذیل:
همانطور که در آدرس صفحه نیز مشخص است، هرچند صفحهی about نمایش داده شدهاست، اما هنوز نیز در همان صفحهی اصلی برنامه قرار داریم. به علاوه در این قسمت جدید، همچنان منوی بالای صفحه نمایان است؛ از این جهت که تعاریف آن به قالب application اضافه شدهاند.
دریافت و نمایش اطلاعات از سرور
اکنون که با نحوهی تعریف یک صفحهی جدید و برپایی سیم کشیهای مرتبط با آن آشنا شدیم، میخواهیم صفحهی دیگری را به نام Users به برنامه اضافه کنیم و در آن لیست کاربران ارائه شده توسط کنترلر Web API سمت سرور ابتدای بحث را نمایش دهیم.
بنابراین ابتدا مسیریابی جدید users را به صفحه اضافه میکنیم تا لیست کاربران، در آدرس users/ قابل دسترسی شود:
App.Router.map(function() { this.resource('about'); this.resource('users'); });
App.UsersLink = Ember.Object.extend({}); App.UsersLink.reopenClass({ findAll: function () { var users = []; $.getJSON('/api/users').then(function(response) { response.forEach(function(item) { users.pushObject(App.UsersLink.create(item)); }); }); return users; } });
پس از اینکه نحوهی دریافت اطلاعات از سرور مشخص شد، باید اطلاعات این مدل را در اختیار مسیریابی Users قرار داد:
App.UsersRoute = Ember.Route.extend({ model: function() { return App.UsersLink.findAll(); } }); App.UsersController = Ember.ObjectController.extend({ customHeader : 'Our Users List' });
همچنین در کنترلری که تعریف شده، صرفا یک خاصیت سفارشی و دلخواه جدید، به نام customHeader برای نمایش در ابتدای صفحه تعریف و مقدار دهی گردیدهاست.
اکنون قالبی که قرار است اطلاعات مدل را نمایش دهد، چنین شکلی را خواهد داشت:
<script type="text/x-handlebars" data-template-name="users"> <h2>{{customHeader}}</h2> <ul> {{#each item in model}} <li> {{item.Id}}-{{item.UserName}} ({{item.Email}}) </li> {{/each}} </ul> </script>
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید:
EmberJS02.zip