جزئیات روش خودتان را با روش یکی از اعضای تیم دات نت مطابقت بدید (مربوط به ASP.NET 4.5 است):
Adding Bundling and Minification to Web Forms
Adding Bundling and Minification to Web Forms
- بررسی ویرویس Stuxnet | www.idevcenter.com
- تایپ متن فارسی در Gmail | googlepersianblog.blogspot.com
- خصوصیات جدید در ASP.NET 4.5 - خصوصیت HTML Editor Smart Tasks and Event Handler Generation | mojtabasahraei.blogfa.com
- دیتابیس رنگی | www.dotnetdev.info
- شما مرغابی هستید یا عقاب؟ | hrnews.blogfa.com
- نقد فیلم "one flew over the cuckoos nest - دیوانه از قفس پرید( پرواز بر فراز آشیانه فاخته)" | filmhafteh.blogfa.com
- Addressing Visual Studio performance | blogs.msdn.com
- BUILD conference–day 3 | lostechies.com
- BUILD: WinRT, Silverlight, WPF, XAML | www.japf.fr
- C# and Visual Basic on the WinRT API | www.infoq.com
- Multi Monitor in VS.NET 2010 & SQL Server 2011 | www.nikamooz.com
- My List of Must-See Build 2011 Videos | 10rem.net
- New CSS editor features in Visual Studio 11 Developer Preview | blogs.msdn.com
- New Tools and New Content - ASP.NET, Visual Studio 11 Web and .NET 4.5 Developer Preview (with commentary) | www.hanselman.com
- Prototype xUnit.net Visual Studio 11 Unit Testing Plugin | bradwilson.typepad.com
- RIA Services updates for //build | feeds.jeffhandley.com
- Using WinRT from .NET | ermau.com
- Windows 8 and WinRT: Links, News and Resources | ajlopez.wordpress.com
- Windows 8 Replaces the Win32 API | www.infoq.com
- Windows 8: What you Need to Know | csharperimage.jeremylikness.com
- WinRT: An Object Orientated Replacement for Win32 | www.infoq.com
در قسمت قبل، در حین بررسی رفتار جزیرههای تعاملی Blazor Server، نکتهی زیر را هم دربارهی راهبری صفحات SSR مرور کردیم:
« اگر دقت کنید، جابجایی بین صفحات، با استفاده از fetch انجام شده؛ یعنی با اینکه این صفحات در اصل static HTML خالص هستند، اما ... کار full reload صفحه مانند ASP.NET Web forms قدیمی انجام نمیشود (و یا حتی برنامههای MVC و Razor pages) و نمایش صفحات، Ajax ای است و با fetch استاندارد آن صورت میگیرد تا هنوز هم حس و حال SPA بودن برنامه حفظ شود. همچنین اطلاعات DOM کل صفحه را هم بهروز رسانی نمیکند؛ فقط موارد تغییر یافته در اینجا به روز رسانی خواهند شد.»
در این قسمت، نکات تکمیلی این قابلیت را که به آن enhanced navigation هم گفته میشود، بررسی میکنیم.
روش غیرفعال کردن راهبری بهبودیافته برای بعضی از لینکها
ویژگی راهبری بهبودیافته فقط در حین هدایت بین صفحات مختلف یک برنامهی Blazor 8x SSR، فعال است. اگر در این بین، کاربری به یک صفحهی غیر بلیزری هدایت شود، راهبری بهبود یافته شکست خورده و سعی میکند حالت full document load را پیاده سازی و اجرا کند. مشکل اینجاست که در این حالت دو درخواست ارسال میشود: ابتدا حالت راهبری بهبودیافته فعال میشود و در ادامه پس از شکست این راهبری، هدایت مستقیم صورت میگیرد. برای رفع این مشکل میتوان ویژگی جدید data-enhance-nav را با مقدار false، به لینکهای خارجی مدنظر اضافه کرد تا برای این حالتها دیگر ویژگی راهبری بهبودیافته فعال نشود:
<a href="/not-blazor" data-enhance-nav="false">A non-Blazor page</a>
فعالسازی مدیریت بهبودیافتهی فرمهای SSR
در قسمت چهارم این سری با فرمهای جدید SSR مخصوص Blazor 8x آشنا شدیم. این فرمها هم میتوانند از امکانات راهبری بهبود یافته استفاده کنند (یعنی مدیریت ارسال آن، توسط fetch API انجام شده و به روز رسانی قسمتهای تغییریافتهی صفحه را Ajax ای انجام دهند)؛ برای نمونه اینبار همانند تصویر زیر، از fetch استاندارد برای ارسال اطلاعات به سمت سرور کمک گرفته میشود (یعنی عملیات Ajax ای شده؛ بجای یک post-back معمولی):
اما ... این قابلیت به صورت پیشفرض در فرمهای تعاملی SSR غیرفعال است. چون همانطور که عنوان شد، اگر مقصد این فرم، یک آدرس غیربلیزری باشد، دوبار ارسال فرم صورت خواهد گرفت؛ یکبار با استفاده از fetch API و بار دیگر پس از شکست، به صورت معمولی. اما اگر مطمئن هستید که endpoint این فرم، قطعا یک کامپوننت بلیزری است، بهتر است این قابلیت را در یک چنین فرمهایی نیز به صورت زیر فعال کنید:
<form method="post" @onsubmit="() => submitted = true" @formname="name" data-enhance> <AntiforgeryToken /> <InputText @bind-Value="Name" /> <button>Submit</button> </form> @if (submitted) { <p>Hello @Name!</p> } @code { bool submitted; [SupplyParameterFromForm] public string Name { get; set; } = ""; }
<EditForm method="post" Model="NewCustomer" OnValidSubmit="() => submitted = true" FormName="customer" Enhance> <DataAnnotationsValidator /> <ValidationSummary/> <p> <label> Name: <InputText @bind-Value="NewCustomer.Name" /> </label> </p> <button>Submit</button> </EditForm> @if (submitted) { <p id="pass">Hello @NewCustomer.Name!</p> } @code { bool submitted = false; [SupplyParameterFromForm] public Customer? NewCustomer { get; set; } protected override void OnInitialized() { NewCustomer ??= new(); } public class Customer { [StringLength(3, ErrorMessage = "Name is too long")] public string? Name { get; set; } } }
نکتهی مهم: در این حالت فرض بر این است که هیچگونه هدایتی به یک Non-Blazor endpoint صورت نمیگیرید؛ وگرنه با یک خطا مواجه خواهید شد.
غیرفعال کردن راهبری بهبودیافته برای قسمتی از صفحه
اگر با استفاده از جاواسکریپت و خارج از کدهای بیلزر، اطلاعات DOM را بهروز رسانی میکنید، ویژگی راهبری بهبودیافته، از آن آگاهی نداشته و به صورت خودکار تمام تغییرات شما را بازنویسی میکند. به همین جهت اگر نیاز است قسمتی از صفحه را که مستقیما توسط کدهای جاواسکریپتی تغییر میدهید، از بهروز رسانیهای این قابلیت مصون نگهدارید، میتوانید ویژگی جدید data-permanent را به آن قسمت اضافه کنید:
<div data-permanent> Leave me alone! I've been modified dynamically. </div>
امکان آگاه شدن از بروز راهبری بهبودیافته در کدهای جاواسکریپتی
اگر به هردلیلی در کدهای جاواسکریپتی خودنیاز به آگاه شدن از وقوع یک هدایت بهبودیافته را دارید (برای مثال جهت بازنویسی تغییرات ایجاد شدهی توسط آن)، میتوانید به نحو زیر، مشترک رخدادهای آن شوید:
<script> Blazor.addEventListener('enhancedload', () => { console.log('enhanced load event occurred'); }); </script>
ویژگی جدید Named Element Routing در Blazor 8x
Blazor 8x از ویژگی مسیریابی سمت کلاینت به کمک تعریف URL fragments پشتیبانی میکند. به این صورت رسیدن (اسکرول) به یک قسمت از صفحهای طولانی، بسیار ساده میشود.
برای مثال المان h2 با id مساوی targetElement را درنظر بگیرید:
<div class="border border-info rounded bg-info" style="height:500px"></div> <h2 id="targetElement">Target H2 heading</h2> <p>Content!</p>
<a href="/counter#targetElement"> <NavLink href="/counter#targetElement"> Navigation.NavigateTo("/counter#targetElement");
معرفی متد جدید Refresh در Blazor 8x
در Blazor 8x، امکان بارگذاری مجدد صفحه با فراخوانی متد جدید NavigationManager.Refresh(bool forceLoad = false) میسر شدهاست. این متد در حالت پیشفرض از قابلیت راهبری بهبودیافته برای به روز رسانی صفحه استفاده میکند؛ مگر اینکه اینکار میسر نباشد. اگر آنرا با پارامتر true فراخوانی کنید، full-page reload رخ خواهد داد.
همین اتفاق در مورد متد Navigation.NavigateTo نیز رخدادهاست. این متد نیز در Blazor 8x به صورت پیشفرض بر اساس قابلیت راهبری بهبود یافته کار میکند؛ مگر اینکه اینکار میسر نباشد و یا پارامتر forceLoad آنرا به true مقدار دهی کنید.
فرمهای Blazor به همراه پشتیبانی از ویژگی Remote که به همراه ASP.NET Core ارائه میشود، نیستند. هرچند میتوان در حین ارسال فرم به سرور، نتیجهی اعتبارسنجی از راه دور و سمت سرور را به کاربر نمایش داد، اما تجربهی کاربری آن در حد Remote validation نیست. یعنی میخواهیم در حین ورود اطلاعات و یا انتقال focus به کنترل دیگری، اعتبارسنجی سمت سرور صورت گیرد و نه فقط در زمان ارسال کل اطلاعات به سرور، در پایان کار. در این مطلب روشی را جهت پیاده سازی این عملیات بررسی خواهیم کرد.
ایجاد یک پروژهی ابتدایی Blazor WASM
پروژهای را که در این مطلب تکمیل خواهیم کرد، از نوع Blazor WASM هاست شدهاست. بنابراین در پوشهی فرضی BlazorAsyncValidation، دستور «dotnet new blazorwasm --hosted» را صادر میکنیم تا ساختار ابتدایی پروژه که به همراه یک کلاینت Blazor WASM و یک سرور ASP.NET Core Web API است، تشکیل شود. از قسمت Web API، برای پیاده سازی اعتبارسنجی سمت سرور استفاده خواهیم کرد.
مدل ثبت نام برنامه
مدل ثبت نام برنامه تنها از یک خاصیت نام تشکیل شده و در پروژهی Shared قرار میگیرد تا هم در کلاینت و هم در سرور قابل استفاده باشد:
این نام است که میخواهیم عدم تکراری بودن آنرا حین ثبت نام در سمت سرور، بررسی کنیم. به همین جهت کنترلر API زیر را برای آن تدارک خواهیم دید.
کنترلر API ثبت نام برنامه
کنترلر زیر که در پوشهی BlazorAsyncValidation\Server\Controllers قرار میگیرد، منطق بررسی تکراری نبودن نام دریافتی از برنامهی کلاینت را شبیه به منطق remote validation استاندارد MVC، پیاده سازی میکند که در نهایت یک true و یا false را باز میگرداند.
در اینجا خروجی بازگشت داده کاملا در اختیار شما است و نیازی نیست تا حتما ارتباطی با MVC داشته باشد؛ چون مدیریت سمت کلاینت بررسی آنرا خودمان انجام خواهیم داد و نه یک کتابخانهی از پیش نوشته شده و مشخص.
غنی سازی فرم استاندارد Blazor جهت انجام Remote validation
اگر بخواهیم از EditForm استاندارد Blazor در حالت متداول آن و بدون هیچ تغییری استفاده کنیم، مانند مثال زیر که InputText متصل به خاصیت Name مربوط به Dto برنامه را نمایش میدهد:
تنها رخدادی که در اختیار ما قرار میگیرد، رخداد submit (در حالت موفقیت اعتبارسنجی سمت کلاینت و یا تنها submit معمولی) است. بنابراین برای دسترسی به رخدادهای بیشتر EditForm، نیاز است با EditContext آن کار کنیم:
به همین جهت EditContext را در سطح کامپوننت جاری تعریف کرده و همچنین سرویس HttpClient را جهت ارسال اطلاعات Name و دریافت پاسخ true/false از سرور و یک ValidationMessageStore را برای نگهداری تعاریف خطاهای سفارشی که قرار است در فرم نمایش داده شوند، معرفی میکنیم.
ValidationMessageStore به همراه متد Add است و اگر به آن نام فیلد مدنظر را به همراه پیامی، اضافه کنیم، این اطلاعات را به صورت خطای اعتبارسنجی توسط کامپوننت ValidationMessage نمایش میدهد.
محل مقدار دهی اولیهی این اشیاء نیز در روال رویدادگردان OnInitialized به صورت زیر است:
در اینجا ابتدا یک نمونهی جدید از EditContext، بر اساس Model فرم، تشکیل میشود. سپس ValidationMessageStore سفارشی که قرار است خطاهای اعتبارسنجی remote ما را نمایش دهد نیز نمونه سازی میشود. در ادامه امکان دسترسی به رخدادهای OnFieldChanged ، OnValidationStateChanged و OnValidationRequested را خواهیم داشت که در حالت معمولی کار با EditForm میسر نیستند.
برای مثال اگر فیلدی تغییر کند، رویداد OnFieldChanged صادر میشود. در همینجا است که کار فراخوانی متد OnValidateFieldAsync که در ادامه معرفی میشود را انجام میدهیم تا کار اعتبارسنجی Async سمت سرور را انجام دهد. اگر نتیجهای به همراه آن بود، توسط messageStore به صورت یک خطای اعتبارسنجی نمایش داده خواهد شد و همچنین EditContext نیز با فراخوانی متد NotifyValidationStateChanged، وادار به بهروز رسانی وضعیت اعتبارسنجی خود میگردد.
متد سفارشی OnValidateFieldAsync که کار اعتبارسنجی سمت سرور را انجام میدهد، به صورت زیر تعریف شدهاست:
در اینجا درخواستی به سمت آدرس api/Register/IsUserNameUnique ارسال شده و سپس بر اساس مقدار true و یا false آن، پیامی را بازگشت میدهد. اگر نال را بازگشت دهد یعنی مشکلی نبوده.
یک نکته: InputText استاندارد در حالت معمول آن، پس از تغییر focus به یک کنترل دیگر، سبب بروز رویداد OnFieldChanged میشود و نه در حالت فشرده شدن کلیدها. به همین جهت اگر برنامه پیوستی را میخواهید آزمایش کنید، نیاز است فقط focus را تغییر دهید و یا یک کنترل سفارشی را برای اینکار توسعه دهید.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: BlazorAsyncValidation.zip
ایجاد یک پروژهی ابتدایی Blazor WASM
پروژهای را که در این مطلب تکمیل خواهیم کرد، از نوع Blazor WASM هاست شدهاست. بنابراین در پوشهی فرضی BlazorAsyncValidation، دستور «dotnet new blazorwasm --hosted» را صادر میکنیم تا ساختار ابتدایی پروژه که به همراه یک کلاینت Blazor WASM و یک سرور ASP.NET Core Web API است، تشکیل شود. از قسمت Web API، برای پیاده سازی اعتبارسنجی سمت سرور استفاده خواهیم کرد.
مدل ثبت نام برنامه
مدل ثبت نام برنامه تنها از یک خاصیت نام تشکیل شده و در پروژهی Shared قرار میگیرد تا هم در کلاینت و هم در سرور قابل استفاده باشد:
using System.ComponentModel.DataAnnotations; namespace BlazorAsyncValidation.Shared; public class UserDto { [Required] public string Name { set; get; } = default!; }
کنترلر API ثبت نام برنامه
کنترلر زیر که در پوشهی BlazorAsyncValidation\Server\Controllers قرار میگیرد، منطق بررسی تکراری نبودن نام دریافتی از برنامهی کلاینت را شبیه به منطق remote validation استاندارد MVC، پیاده سازی میکند که در نهایت یک true و یا false را باز میگرداند.
در اینجا خروجی بازگشت داده کاملا در اختیار شما است و نیازی نیست تا حتما ارتباطی با MVC داشته باشد؛ چون مدیریت سمت کلاینت بررسی آنرا خودمان انجام خواهیم داد و نه یک کتابخانهی از پیش نوشته شده و مشخص.
using BlazorAsyncValidation.Shared; using Microsoft.AspNetCore.Mvc; namespace BlazorAsyncValidation.Server.Controllers; [ApiController, Route("api/[controller]/[action]")] public class RegisterController : ControllerBase { [HttpPost] public IActionResult IsUserNameUnique([FromBody] UserDto userModel) { if (string.Equals(userModel?.Name, "Vahid", StringComparison.OrdinalIgnoreCase)) { return Ok(false); } return Ok(true); } }
غنی سازی فرم استاندارد Blazor جهت انجام Remote validation
اگر بخواهیم از EditForm استاندارد Blazor در حالت متداول آن و بدون هیچ تغییری استفاده کنیم، مانند مثال زیر که InputText متصل به خاصیت Name مربوط به Dto برنامه را نمایش میدهد:
@page "/" <PageTitle>Index</PageTitle> <h2>Register</h2> <EditForm EditContext="@EditContext" OnValidSubmit="DoSubmitAsync"> <DataAnnotationsValidator/> <div class="row mb-2"> <label class="col-form-label col-lg-2">Name:</label> <div class="col-lg-10"> <InputText @bind-Value="Model.Name" class="form-control"/> <ValidationMessage For="@(() => Model.Name)"/> </div> </div> <button class="btn btn-secondary" type="submit">Submit</button> </EditForm>
public partial class Index { private const string UserValidationUrl = "/api/Register/IsUserNameUnique"; private ValidationMessageStore? _messageStore; [Inject] private HttpClient HttpClient { set; get; } = default!; private EditContext? EditContext { set; get; } private UserDto Model { get; } = new();
ValidationMessageStore به همراه متد Add است و اگر به آن نام فیلد مدنظر را به همراه پیامی، اضافه کنیم، این اطلاعات را به صورت خطای اعتبارسنجی توسط کامپوننت ValidationMessage نمایش میدهد.
محل مقدار دهی اولیهی این اشیاء نیز در روال رویدادگردان OnInitialized به صورت زیر است:
protected override void OnInitialized() { EditContext = new EditContext(Model); _messageStore = new ValidationMessageStore(EditContext); EditContext.OnFieldChanged += (sender, eventArgs) => { var fieldIdentifier = eventArgs.FieldIdentifier; _messageStore?.Clear(fieldIdentifier); _ = InvokeAsync(async () => { var errors = await OnValidateFieldAsync(fieldIdentifier.FieldName); if (errors?.Any() != true) { return; } foreach (var error in errors) { _messageStore?.Add(fieldIdentifier, error); } EditContext.NotifyValidationStateChanged(); }); StateHasChanged(); }; EditContext.OnValidationStateChanged += (sender, eventArgs) => StateHasChanged(); EditContext.OnValidationRequested += (sender, eventArgs) => _messageStore?.Clear(); }
برای مثال اگر فیلدی تغییر کند، رویداد OnFieldChanged صادر میشود. در همینجا است که کار فراخوانی متد OnValidateFieldAsync که در ادامه معرفی میشود را انجام میدهیم تا کار اعتبارسنجی Async سمت سرور را انجام دهد. اگر نتیجهای به همراه آن بود، توسط messageStore به صورت یک خطای اعتبارسنجی نمایش داده خواهد شد و همچنین EditContext نیز با فراخوانی متد NotifyValidationStateChanged، وادار به بهروز رسانی وضعیت اعتبارسنجی خود میگردد.
متد سفارشی OnValidateFieldAsync که کار اعتبارسنجی سمت سرور را انجام میدهد، به صورت زیر تعریف شدهاست:
private async Task<IList<string>?> OnValidateFieldAsync(string fieldName) { switch (fieldName) { case nameof(UserDto.Name): var response = await HttpClient.PostAsJsonAsync( UserValidationUrl, new UserDto { Name = Model.Name }); var responseContent = await response.Content.ReadAsStringAsync(); if (string.Equals(responseContent, "false", StringComparison.OrdinalIgnoreCase)) { return new List<string> { $"`{Model.Name}` is in use. Please choose another name." }; } // TIP: It's better to use the `DntDebounceInputText` component for this case to reduce the network round-trips. break; } return null; }
یک نکته: InputText استاندارد در حالت معمول آن، پس از تغییر focus به یک کنترل دیگر، سبب بروز رویداد OnFieldChanged میشود و نه در حالت فشرده شدن کلیدها. به همین جهت اگر برنامه پیوستی را میخواهید آزمایش کنید، نیاز است فقط focus را تغییر دهید و یا یک کنترل سفارشی را برای اینکار توسعه دهید.
کدهای کامل این مطلب را از اینجا میتوانید دریافت کنید: BlazorAsyncValidation.zip
مطالب
خواندنیهای 4 شهریور
آفیس
اس کیوال سرور
الگوهای طراحی برنامه نویسی شیءگرا
توسعه وب
دات نت فریم ورک
متفرقه
محیطهای مجتمع توسعه
مرورگرها
ویندوز
نظرات مطالب
نرمال سازی اطلاعات کاربران در حین ثبت نام
نکتهای در مورد طراحی دیتابیس ASP.NET Core Identity
به جدول کاربران نگارش سوم ASP.NET Identity، دو فیلد NormalizedEmail و NormalizedUserName هم اضافه شدهاند:
علت وجود این فیلدهای اضافی سه مورد است:
- الف) کاربران پس از ویرایش ایمیلهای خود، متوجه نرمالسازی نشوند. چون اصل ایمیل در فیلد Email ذخیره میشود.
- ب) با نرمال سازی بتوان جلوی مشکلات مطرح شدهی در مطلب جاری را گرفت و از ثبت چندین ایمیل یکسان و یا نام کاربری یکسان جلوگیری کرد.
- ج) برنامه نویس دیگر نیازی ندارد تا توابع نرمالسازی را همواره به صورت دستی، در حین ویرایش اطلاعات کاربران اعمال کند. اکنون این نرمالسازی به صورت خودکار از سرویس ILookupNormalizer دریافت و اعمال میشود.
به جدول کاربران نگارش سوم ASP.NET Identity، دو فیلد NormalizedEmail و NormalizedUserName هم اضافه شدهاند:
که الگوریتم پیش فرض نرمال سازی آنها که فقط to upper case است، قابلیت سفارشی سازی هم دارد (برای مثال جهت اعمال نکات مطلب فوق).
علت وجود این فیلدهای اضافی سه مورد است:
- الف) کاربران پس از ویرایش ایمیلهای خود، متوجه نرمالسازی نشوند. چون اصل ایمیل در فیلد Email ذخیره میشود.
- ب) با نرمال سازی بتوان جلوی مشکلات مطرح شدهی در مطلب جاری را گرفت و از ثبت چندین ایمیل یکسان و یا نام کاربری یکسان جلوگیری کرد.
- ج) برنامه نویس دیگر نیازی ندارد تا توابع نرمالسازی را همواره به صورت دستی، در حین ویرایش اطلاعات کاربران اعمال کند. اکنون این نرمالسازی به صورت خودکار از سرویس ILookupNormalizer دریافت و اعمال میشود.