اشتراکها
اشتراکها
نگاهی به 5 الگوی طراحی نرم افزار
اشتراکها
منظور شما از Event Driven چیست ؟
اشتراکها
Event Aggregator یک بار برای همیشه
یک نکتهی تکمیلی
دقت داشته باشید در حالت استفاده از schedule event (مخصوصاً بازههای کوتاه (حداقل باید ۵ دقیقه باشد)) workflowها ممکن است با تاخیر اجرا شوند (چند دقیقه، چند ساعت) یا حتی اصلاً اجرا نشوند؛ در اینحالت بهتر است یک مکانیزم پشتیبان هم در نظر بگیرید (مثلاً استفاده از cloudflare workers یا AWS lambda یا سرویس IFTTT ) به عنوان مثال من یک schedule بر روی موبایل تنظیم کردهام که هر روز در یک تایم مشخصی workflowها را به صورت اجرا کند چون تقریباً تنها دیوایسی که همیشه مطمئنم به اینترنت دسترسی دارد گوشی همراهم است.
البته نکات بالا با فرض اینکه این موارد ابتدا بررسی شده باشند:
- عبارت CRON به درستی تنظیم شده باشد
- تایمزون به درستی در نظر گرفته شده باشد (UTC حالت پیشفرض است)
- مسیر workflowها صحیح باشند (.github/workflows)
- workflow روی برنچ دیفالت باشد (مگر اینکه به صورت صریح برنچ را مشخص کرده باشید)
- اکشن برای ریپوزیتوری فعال شده باشد (در قسمت تنظیمات)
- از میزان مجاز استفاده از GitHub Actions عبور نکرده باشید؛ این مورد احتمالش خیلی کم است.
- روی ریپوزیتوری fork شده نباشید؛ در اینجالت workflowها به secrets دسترسی ندارند.
یکی از مزایای مهم فریم ورک ASP.NET MVC، توسعه پذیری کنترلرهای آن است. با مرور قسمتهایی از مسیر پردازش درخواست که منجر به اجرای یک اکشن متد میشود، شروع میکنیم و روشهای مختلفی را که میتوان بر روی این پردازش، کنترل داشت، بررسی میکنیم. شکل ذیل مسیر یک درخواست را مابین کامپوننتهای مختلف فریم ورک نشان میدهد:
ابتدا پروژهی جدیدی را از نوع MVC و با الگوی Empty به نام ControllerExtensibility ایجاد میکنیم. در پوشهی Models یک فایل را به نام Result.cs ساخته و از آن برای معرفی کلاس Result مطابق کدهای ذیل استفاده میکنیم:
در مسیر /Views/Shared ویویی را به نام Result.cshtml اضافه میکنیم. این ویویی است که در این مثال، همهی اکشن متدهای کنترلرهایمان، آن را رندر خواهند کرد:
در خط اول، مدل ویو را از نوع کلاس Result تعیین کردهایم.
دو کنترلر را نیز حاوی کدهای زیر ایجاد میکنیم:
کنترلر product
کنترلر customer
اکشنهای این دو کنترلر حاوی کد خاصی نبوده و صرفا ویوی Result.cshtml را صدا میزنند. ولی در این مرحله این همهی آن چیزی است که برای نشان دادن نحوهی سفارشی کردن کنترلرها بدان نیاز داریم.
ایجاد یک Controller Factory سفارشی بهترین راه برای درک نحوهی وهله سازی کنترلرها توسط MVC است. ولی این کار صرفا جنبهی آموزشی داشته و در یک پروژهی واقعی این نوع پیاده سازیها پیشنهاد نمیشود؛ زیرا راههای مفیدتر و سادهتری با پیاده سازی توکار Controller Factory وجود دارند.
Controller Factoryها با پیاده سازی اینترفیس IControllerFactory معرفی میشوند. کدهای این اینترفیس را در ذیل میبینید:
پوشهای را به نام Infrastructure ساخته و فایلی را به نام CustomControllerFactory.cs ، حاوی کدهای زیر اضافه کنید:
مهمترین متد کدهای فوق، CreateController است که فریم ورک، بر حسب نیاز، جهت سرویس دهی به درخواست واصله آن را صدا خواهد زد. پارامتر ورودی این متد، شیء RequestContext است که جزئیاتی در خصوص درخواست واصله را در اختیار factory خواهد گذاشت. همچنین یک رشته که نام کنترلر را بر حسب URL واصله تعیین میکند:
یکی از دلایلی که عنوان شد Controller factory سفارشی بدین روش در یک پروژهی عملی به کار گرفته نشود این است که یافتن کلاسهایی از نوع Controller در سراسر برنامه و وهله سازی آنها کار دشواری است. چرا که لازم خواهد بود بتوانید به صورت پویا کنترلر را مکان یابی کرده و بین کلاسهای هم نام در دیگر فضاهای نام تمییز قائل شوید و خطاهای محتمل در حین وهله سازی را کنترل کنید.
در این مثال تنها دو کنترلر داریم و آنها را به صورت مستقیم در Controller Factory وهله سازی میکنیم که در یک پروژهی واقعی مطلوب نیست. ولی آنچه را که این روش آشکارتر میسازد، انعطاف پذیری بالای فریم ورک MVC است که دست ما را برای نفوذ و دخل و تصرف در اعمال و رفتاریهای پیش فرض خود باز گذاشته است و برای مثال در مباحث تزریق وابستگیها و تنظیمات ابتدایی IoC Containers کاربرد دارد.
متد CreateController لازم است وهلهای از کلاسی که اینترفیس IController را پیاده سازی کرده برگرداند؛ در غیر اینصورت کار با خطا متوقف خواهد شد. لذا برای زمانی که درخواست کاربر، هیچ کدام از کنترلرها را مشمول عنایت قرار نمیدهد، باید چارهای اندیشیده شود.
میتوان آن را به کنترلر خاصی که پیغام خطایی را رندر میکند، هدایت کنیم. به عبارت بهتر باید درخواست را به کنترلری که مطمئن هستیم وجود دارد (اصطلاحا کنترلر جانشین) هدایت نماییم. همان طور که در کد فوق در قسمت default میبینید:
در صورت عدم تطابق با هیچ کدام از حالات تعیین شده، درخواست را به کنترلر ProductController جهت رسیدگی هدایت کردهایم.
در MVC انتخاب ویوی مناسب، بر حسب مقدار RouteData.Values صورت میگیرد؛ نه نام کلاس Controller و این سبب خواهد شد فریم ورک، ویوهای مرتبط با کنترلر جانشین شدهی توسط ما را جستجو کند و نه کنترلری که کاربر از طریق URL ورودی آن را درخواست کرده است.
لذا Controller Factory صرفا وظیفه مپ کردن درخواستهای واصله به کنترلرها را ندارد، بلکه توانایی دخل و تصرف در درخواست واصله بر حسب مورد را نیز خواهد داشت.
در نهایت هم نحوهی استفاده از DependencyResolver را برای وهله سازی کلاسهای کنترلر میبینید. متد استاتیک Current یک پیاده سازی از اینترفیس IDependencyResolver را که حاوی متد GetService است، برگشت داده و سپس یک شیء System.Type را به عنوان ورودی گرفته و یک وهلهی ساخته شدهی از آن را به عنوان خروجی برمیگرداند.
متد GetControllerSessionBehavior نیز توسط MVC جهت تعیین اینکه Session data برای کنترلر نیاز است یا خیر به کار گرفته میشود.
متد ReleaseController نیز هر گاه به شیء کنترلر ساخته شده در متد CreateController دیگر نیازی نبود، صدا زده خواهد شد. در کدهای ما ابتدا بررسی میشود آیا اینترفیس IDisposable توسط کلاس، پیاده سازی شده است یا خیر؟ اگر بلی متد Dispose آن جهت آزاد سازی منابعی که میتوانند آزاد شوند، صدا زده میشود.
جهت ثبت Controller Factory ساخته شده در متد Application_Start موجود در فایل global.asax.cs بوسیله کلاس ControllerBuilder و مطابق کدهای ذیل عمل مینماییم:
پس از ثبت به شیوهی فوق، controller factory ساخته شده، مسئول هندل کردن تمامی درخواستهای واصلهی به برنامه خواهد بود. پس از اولین اجرا، مرورگر ریشهی سایت را هدف قرار خواهد داد که توسط سیستم مسیر یابی به کنترلر Home، نگاشت شده و بر اساس تعاریف و کدهای ما، چون با هیچ کدام از کنترلرهای Product و Customer تطابق نخواهد داشت، به کنترلر جایگزین تنظیم شده، یعنی Product هدایت خواهد شد.
Controller Factory و Action Invoker وظیفهای مطابق نامشان را عهده دار هستند. اولی برای وهله سازی کنترلرهای مرتبط با درخواست و دومی برای پیدا کردن و تریگر نمودن یک اکشن متد به کار گرفته میشوند. فریم ورک MVC پیاده سازی پیش فرضی را از این دو کامپوننت، به صورت توکار دارد. در طی مقالاتی نحوهی کنترل کردن رفتار پیش فرض این Controller Factory و هم نحوهی جایگزین کرن کامل این کامپوننت را بررسی میکنیم.
ابتدا پروژهی جدیدی را از نوع MVC و با الگوی Empty به نام ControllerExtensibility ایجاد میکنیم. در پوشهی Models یک فایل را به نام Result.cs ساخته و از آن برای معرفی کلاس Result مطابق کدهای ذیل استفاده میکنیم:
namespace ControllerExtensibility.Models { public class Result { public string ControllerName { get; set; } public string ActionName { get; set; } } }
@model ControllerExtensibility.Models.Result @{ Layout = null; } <!DOCTYPE html> <html> <head> <meta name="viewport" content="width=device-width" /> <title>Result</title> </head> <body> <div>Controller: @Model.ControllerName</div> <div>Action: @Model.ActionName</div> </body> </html>
دو کنترلر را نیز حاوی کدهای زیر ایجاد میکنیم:
کنترلر product
using ControllerExtensibility.Models; using System.Web.Mvc; namespace ControllerExtensibility.Controllers { public class ProductController : Controller { public ViewResult Index() { return View("Result", new Result { ControllerName = "Product", ActionName = "Index" }); } public ViewResult List() { return View("Result", new Result { ControllerName = "Product", ActionName = "List" }); } } }
کنترلر customer
using System.Web.Mvc; namespace ControllerExtensibility.Controllers { public class CustomerController : Controller { public ViewResult Index() { return View("Result", new Result { ControllerName = "Customer", ActionName = "Index" }); } public ViewResult List() { return View("Result", new Result { ControllerName = "Customer", ActionName = "List" }); } } }
ایجاد یک Controller Factory سفارشی بهترین راه برای درک نحوهی وهله سازی کنترلرها توسط MVC است. ولی این کار صرفا جنبهی آموزشی داشته و در یک پروژهی واقعی این نوع پیاده سازیها پیشنهاد نمیشود؛ زیرا راههای مفیدتر و سادهتری با پیاده سازی توکار Controller Factory وجود دارند.
Controller Factoryها با پیاده سازی اینترفیس IControllerFactory معرفی میشوند. کدهای این اینترفیس را در ذیل میبینید:
using System.Web.Routing; using System.Web.SessionState; namespace System.Web.Mvc { public interface IControllerFactory { IController CreateController(RequestContext requestContext, string controllerName); SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName); void ReleaseController(IController controller); } }
using System; using System.Web.Mvc; using System.Web.Routing; using System.Web.SessionState; using ControllerExtensibility.Controllers; namespace ControllerExtensibility.Infrastructure { public class CustomControllerFactory : IControllerFactory { public IController CreateController(RequestContext requestContext, string controllerName) { Type targetType = null; switch (controllerName) { case "Product": targetType = typeof (ProductController); break; case "Customer": targetType = typeof (CustomerController); break; default: requestContext.RouteData.Values["controller"] = "Product"; targetType = typeof (ProductController); break; } return targetType == null ? null : (IController) DependencyResolver.Current.GetService(targetType); } public SessionStateBehavior GetControllerSessionBehavior(RequestContext requestContext, string controllerName) { return SessionStateBehavior.Default; } public void ReleaseController(IController controller) { IDisposable disposable = controller as IDisposable; if (disposable != null) { disposable.Dispose(); } } } }
نام | نوع | توضیحات |
HttpContext | HttpContextBase | حاوی اطلاعاتی در خصوص درخواست است. |
RouteData | RouteData | حاوی اطلاعاتی در خصوص Rout است که با درخواست رسیده همخوانی دارد. |
یکی از دلایلی که عنوان شد Controller factory سفارشی بدین روش در یک پروژهی عملی به کار گرفته نشود این است که یافتن کلاسهایی از نوع Controller در سراسر برنامه و وهله سازی آنها کار دشواری است. چرا که لازم خواهد بود بتوانید به صورت پویا کنترلر را مکان یابی کرده و بین کلاسهای هم نام در دیگر فضاهای نام تمییز قائل شوید و خطاهای محتمل در حین وهله سازی را کنترل کنید.
در این مثال تنها دو کنترلر داریم و آنها را به صورت مستقیم در Controller Factory وهله سازی میکنیم که در یک پروژهی واقعی مطلوب نیست. ولی آنچه را که این روش آشکارتر میسازد، انعطاف پذیری بالای فریم ورک MVC است که دست ما را برای نفوذ و دخل و تصرف در اعمال و رفتاریهای پیش فرض خود باز گذاشته است و برای مثال در مباحث تزریق وابستگیها و تنظیمات ابتدایی IoC Containers کاربرد دارد.
متد CreateController لازم است وهلهای از کلاسی که اینترفیس IController را پیاده سازی کرده برگرداند؛ در غیر اینصورت کار با خطا متوقف خواهد شد. لذا برای زمانی که درخواست کاربر، هیچ کدام از کنترلرها را مشمول عنایت قرار نمیدهد، باید چارهای اندیشیده شود.
میتوان آن را به کنترلر خاصی که پیغام خطایی را رندر میکند، هدایت کنیم. به عبارت بهتر باید درخواست را به کنترلری که مطمئن هستیم وجود دارد (اصطلاحا کنترلر جانشین) هدایت نماییم. همان طور که در کد فوق در قسمت default میبینید:
default: requestContext.RouteData.Values["controller"] = "Product"; targetType = typeof(ProductController); break;
در MVC انتخاب ویوی مناسب، بر حسب مقدار RouteData.Values صورت میگیرد؛ نه نام کلاس Controller و این سبب خواهد شد فریم ورک، ویوهای مرتبط با کنترلر جانشین شدهی توسط ما را جستجو کند و نه کنترلری که کاربر از طریق URL ورودی آن را درخواست کرده است.
لذا Controller Factory صرفا وظیفه مپ کردن درخواستهای واصله به کنترلرها را ندارد، بلکه توانایی دخل و تصرف در درخواست واصله بر حسب مورد را نیز خواهد داشت.
در نهایت هم نحوهی استفاده از DependencyResolver را برای وهله سازی کلاسهای کنترلر میبینید. متد استاتیک Current یک پیاده سازی از اینترفیس IDependencyResolver را که حاوی متد GetService است، برگشت داده و سپس یک شیء System.Type را به عنوان ورودی گرفته و یک وهلهی ساخته شدهی از آن را به عنوان خروجی برمیگرداند.
متد GetControllerSessionBehavior نیز توسط MVC جهت تعیین اینکه Session data برای کنترلر نیاز است یا خیر به کار گرفته میشود.
متد ReleaseController نیز هر گاه به شیء کنترلر ساخته شده در متد CreateController دیگر نیازی نبود، صدا زده خواهد شد. در کدهای ما ابتدا بررسی میشود آیا اینترفیس IDisposable توسط کلاس، پیاده سازی شده است یا خیر؟ اگر بلی متد Dispose آن جهت آزاد سازی منابعی که میتوانند آزاد شوند، صدا زده میشود.
جهت ثبت Controller Factory ساخته شده در متد Application_Start موجود در فایل global.asax.cs بوسیله کلاس ControllerBuilder و مطابق کدهای ذیل عمل مینماییم:
using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Http; using System.Web.Mvc; using System.Web.Routing; using ControllerExtensibility.Infrastructure; namespace ControllerExtensibility { public class MvcApplication : System.Web.HttpApplication { protected void Application_Start() { AreaRegistration.RegisterAllAreas(); WebApiConfig.Register(GlobalConfiguration.Configuration); FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters); RouteConfig.RegisterRoutes(RouteTable.Routes); ControllerBuilder.Current.SetControllerFactory(new CustomControllerFactory()); } } }
اشتراکها
کتابخانه SmartWizard
Smart Wizard is a flexible and heavily customizable jQuery step wizard plugin with Bootstrap support. It is easy to implement and gives a neat and stylish interface for your forms, checkout screen, registration steps etc. Based on the feedback from our users over the past years we have come up with the best ever built jQuery wizard plugin of all time. Demo
Features:
- Bootstrap support
- Responsive themes
- Heavily customizable toolbar, option to add extra buttons
- Theme support with various themes included
- Customizable css styles
- Url navigation and step selection
- Public methods for external function call
- Enhanced event support
- In-built wizard reset method
- Ajax content loading with option to specify individual url for steps
- Keyboard navigation
یک نکتهی تکمیلی: امکان داشتن متدهایی با خروجی تگدار در برنامههای Blazor (یا تعریف کامپوننتهای پویا)
اگر با React کار کرده باشید، یک چنین کدهایی اساس آنرا تشکیل میدهند:
در اینجا کامپوننتی به نام Rentals تعریف شدهاست که خروجی آن ... یک تگ HTML ای است و برای تشکیل آن نیازی به استفاده از "" و چسباندن رشتهها نبودهاست. دقیقا شبیه به یک چنین کاری را میتوان در برنامههای Blazor نیز انجام داد که به آن «Razor template syntax» و یا «templated components» هم گفته میشود:
در اینجا همانطور که مشاهده میکنید، امکان انتساب یک قالب HTML ای شروع شدهی با @ به یک RenderFragment وجود دارد که حتی میتواند جنریک هم باشد و وهلهای از این شیء جنریک را به صورت یک lambda expression دریافت کند. روش درج آنها را در صفحه نیز مشاهده میکنید که همانند فراخوانی متدها است و برای نمونه ItemTemplate جنریک، وهلهای از فیلد emp تعریف شدهی در قسمت code را دریافت کرده و در صفحه نمایش میدهد.
یا حتی میتوان از RenderFragment برای وهله سازی پویای یک کامپوننت مانند SurveyPrompt، مقدار دهی خاصیت Title آن و درج آن در صفحه به صورت زیر هم استفاده کرد:
اگر با React کار کرده باشید، یک چنین کدهایی اساس آنرا تشکیل میدهند:
import React from "react"; const Rentals = () => { return <h1>Rentals</h1>; }; export default Rentals;
@page "/razor" @template @ItemTemplate(emp) @code { RenderFragment template = @<p>The time is @DateTime.Now.</p>; RenderFragment<Employee> ItemTemplate = (item) => @<p>Employee name is @item.Name.</p>; Employee emp = new Employee { Name = "Test" }; public class Employee { public string Name; } }
یا حتی میتوان از RenderFragment برای وهله سازی پویای یک کامپوننت مانند SurveyPrompt، مقدار دهی خاصیت Title آن و درج آن در صفحه به صورت زیر هم استفاده کرد:
@page "/" @CreateDynamicComponent() @code { RenderFragment CreateDynamicComponent() => builder => { builder.OpenComponent(0, typeof(SurveyPrompt)); builder.AddAttribute(1, "Title", "Some title"); builder.CloseComponent(); }; }
نظرات مطالب
شروع کار با Angular Material ۲
برای اضافه کردن tab کافیه کد زیر رو در html داشته باشید.
منبع: انگیولار متریال 2
<md-tab-group> <md-tab label="Tab 1">Content 1</md-tab> <md-tab label="Tab 2">Content 2</md-tab> </md-tab-group>
در مورد ریسپانسیو بودن صفحات نیز، بنده قصد دارم در آموزشهای جداگانهای این مورد رو برسی قرار بدم. ولی فعلا میتوانید مستندات مربوط به flex-layout رو مطالعه کنید. البته لازم به ذکر است نسخه نهایی این ماژول فعلا منتشر نشده است و همچنان در حال توسعه میباشد.