مطالب
معرفی کتابخانه Loader برای بارگذاری JS و CSS
در طراحی صفحات وب، معمولا از فایل‌های JS و CSS مختلفی استفاده می‌شود؛ از کتابخانه‌ها گرفته تا فایل‌ها اصلی برنامه. به صورت خیلی ساده ما تمام این فایل‌ها را به صفحه‌ی لینک می‌کنیم. اما این روش درست نیست و حجم صفحه و تعداد درخواست‌ها به سرور برای بارگذاری فایل‌ها خیلی بیشتر می‌شود. در زمان اجرای یک صفحه‌ی وب مسلما قسمت‌هایی از صفحه وجود دارند که شاید در شرایط خاصی، کاربر این صفحات را ببیند و یا نیاز باشد تا منطقی، توسط یک فایل JS خاص انجام شود. کتابخانه‌های زیادی برای حل این موضوع درست شده‌اند که راهکار آنها به این صورت است که شما در مواقعی که نیاز به این فایل‌ها دارید، آنها را بارگذاری می‌کنید. کتابخانه‌ی Loader یک فایل JS ساده می‌باشد که توسط اینجانب نوشته شده است و در یک پروژه‌ی بزرگ در حال استفاده است. این کتابخانه تا همین الان که 4 سال از عمر پروژه می‌گذرد در حال کار کردن هست و بدون هیچ مشکلی تا الان جواب داده است. بنابراین تصمیم گرفتم تا این کتابخانه را به صورت عمومی منتشر کنم تا شما هم از این کتابخانه استفاده کنید. در زیر کد Core این کتابخانه و نحوه‌ی استفاده از آن را نوشته‌ام و لینک GitHub هم در زیر می‌باشد.

نحوه‌ی استفاده از این کتابخانه بعد از اینکه فایل JS آن‌را به صفحه وصل کردیم، به صورت زیر است که می‌توانید بر حسب نیاز، این تابع را صدا بزنید. کد زیر نحوه‌ی استفاده از این کتابخانه هست. فرض کنید در شرایطی نیاز داریم تا کتابخانه‌ی JSTree را بارگذری کنیم. به جای اینکه از اول فایل‌های JS و CSS آن‌را در صفحه داشته باشیم، خیلی ساده از تابع زیر استفاده می‌کنیم. در این کتابخانه تابع Promise وقتی Fire می‌شود که تمام فایل‌هایی که به صورت پارامتر در تابع Load مشخص شده‌اند، بارگذاری شوند.
loader.load([
  'plugin/dropdowntree/css/style.min.css',  
  'plugin/dropdowntree/js/jstree.js',  
  'plugin/dropdowntree/js/jstree.checkbox.js',  
]).promise(function () {
  // run this code promise  
});
کد هسته‌ی اصلی کتابخانه Loader به صورت زیر هست:
/*     
    loader version 0.2.1 2015    
    loader design by Behnam Mohammadi (http://itten.ir)
*/
window.loader = {  
    load: function (urls) {
        var loadCounter = 0;
        var promise = null;
        var ext = '';
        this.promise = function (fun) {
            promise = fun;
        };
        for (var i = 0; i < urls.length; i++) {
            ext = urls[i].substring(urls[i].length - 3);
            if (ext == '.js') {
                var script = document.createElement('script');
                script.src = urls[i];
                script.onload = function () {
                    loadCounter += 1;
                    if (loadCounter == urls.length) {
                        promise();
                    }
                };
                document.body.appendChild(script);
            } else if (ext == 'css') {
                var link = document.createElement('link');
                link.href = urls[i];
                link.rel = 'stylesheet';
                link.type = 'text\css';
                link.onload = function () {
                    loadCounter += 1;
                    if (loadCounter == urls.length) {
                        promise();
                    }
                };
                document.body.appendChild(link);
            }
        }
        return this;
    }
}
حجم این کتابخانه در صورت فشرده سازی کمتر از نیم کیلوبایت هست. لینک GitHub این پروژه را در زیر مشاهده میکنید.
نظرات مطالب
OpenCVSharp #18
- مرحله‌ی اول، بیرون کشیدن مستطیل شماره پلاک خودرو از داخل یک عکس کلی است؛ چیزی شبیه به مطلب «تشخیص چهره». اگر به پوشه‌ی دیتا OpenCV مراجعه کنید، فایل xml تشخیص مستطیل شماره پلاک خودروهای روسی را دارد؛ فایل‌های haarcascade_licence_plate_rus_16stages.xml و haarcascade_russian_plate_number.xml. نحوه‌ی استفاده‌ی از این فایل‌ها، دقیقا همانند مطلب تشخیص چهره‌است. برای تشخیص شماره پلاک‌های ایرانی، باید از روش کلی مطرح شده در مطلب «طراحی classifier سفارشی تشخیص خودروها» استفاده کنید. یک سری عکس تهیه کنید و بعد فایل XML آن‌را استخراج کنید.
- مرحله‌ی دوم، با مطلب جاری تفاوتی ندارد:

ابتدا اصل پلاک باید تشخیص داده شود (همان مطلب تشخیص چهره با یک فایل XML مناسب). بعد بهبود کیفیت تصویر پلاک و آماده سازی آن برای استخراج کانتورها است. سپس این اشیاء یافت شده را به الگویتم مثلا CvKNearest ارسال و شمار‌ه‌ی گروه هر کانتور را دریافت می‌کنید (روش OCR مطلب جاری).

یک نکته‌ی تکمیلی
فایل‌های XML یافتن مستطیل شماره پلاک‌های چند کشور مختلف را در پروژه‌ی openalpr می‌توانید پیدا کنید. این پروژه از OpenCV برای تشخیص پلاک و سپس از Tesseract OCR برای انجام کار OCR نهایی استفاده می‌کند (Tesseract OCR یک OCR سورس باز تهیه شده توسط گوگل است).
مطالب
آشنایی با M.A.F - قسمت دوم

قسمت قبل بیشتر آشنایی با یک سری از اصطلاحات مرتبط با فریم ورک MAF بود و همچنین نحوه‌ی کلی استفاده از آن. در این قسمت یک مثال ساده را با آن پیاده سازی خواهیم کرد و فرض قسمت دوم بر این است که افزونه‌ی Visual Studio Pipeline Builder را نیز نصب کرده‌اید.

یک نکته پیش از شروع:
- اگر افزونه‌ی Visual Studio Pipeline Builder پس از نصب به منوی Tools اضافه نشده است، یک پوشه‌ی جدید را به نام Addins در مسیر Documents\Visual Studio 2008 ایجاد کرده و سپس فایل‌های آن‌را در این مسیر کپی کنید.

ساختار اولیه یک پروژه MAF

- پروژ‌ه‌هایی که از MAF استفاده می‌کنند، نیاز به ارجاعاتی به دو اسمبلی استاندارد System.AddIn.dll و System.AddIn.Contract.dll دارند (مطابق شکل زیر):



- ساختار آغازین یک پروژه MAF از سه پروژه تشکیل می‌شود که توسط افزونه‌ی Visual Studio Pipeline Builder به 7 پروژه بسط خواهد یافت.
این سه پروژه استاندارد آغازین شامل موارد زیر هستند:



- هاست: همان برنامه‌ی اصلی که قرار است از افزونه استفاده کند.
- قرار داد: نحو‌ه‌ی تعامل هاست و افزونه در این پروژه تعریف می‌شود. (یک پروژه از نوع class library)
- افزونه: کار پیاده سازی قرار داد را عهده دار خواهد شد. (یک پروژه از نوع class library)

- همچنین مرسوم است جهت مدیریت بهتر خروجی‌های حاصل شده یک پوشه Output را نیز به این solution اضافه کنند:



اکنون با توجه به این محل خروجی، به خواص Build سه پروژه موجود مراجعه کرده و مسیر Build را اندکی اصلاح خواهیم کرد (هر سه مورد بهتر است اصلاح شوند)، برای مثال:



نکته‌ی مهم هم اینجا است که خروجی host باید به ریشه این پوشه تنظیم شود و سایر پروژه‌ها هر کدام خروجی خاص خود را در پوشه‌ای داخل این ریشه باید ایجاد کنند.



تا اینجا قالب اصلی کار آماده شده است. قرارداد ما هم به شکل زیر است (ویژگی AddInContract آن نیز نباید فراموش شود):

using System.AddIn.Pipeline;
using System.AddIn.Contract;

namespace CalculatorConract
{
[AddInContract]
public interface ICalculatorContract : IContract
{
double Operate(string operation, double a, double b);
}
}

به عبارت دیگر برنامه‌ای محاسباتی داریم (هاست) که دو عدد double را در اختیار افزونه‌های خودش قرار می‌دهد و سپس این افزونه‌ها یک عملیات ریاضی را بر روی آن‌ها انجام داده و خروجی را بر می‌گردانند. نوع عملیات توسط آرگومان operation مشخص می‌شود. این آرگومان به کلیه افزونه‌های موجود ارسال خواهد شد و احتمالا یکی از آن‌ها این مورد را پیاده سازی کرده است. در غیر اینصورت یک استثنای عملیات پیاده سازی نشده صادر می‌شود.
البته روش بهتر طراحی این افزونه، اضافه کردن متد یا خاصیتی جهت مشخص کردن نوع و یا انواع عملیات پشتیبانی شده توسط افزونه‌ است که جهت سادگی این مثال، به این طراحی ساده اکتفا می‌شود.

ایجاد pipeline

اگر قسمت قبل را مطالعه کرده باشید، یک راه حل مبتنی بر MAF از 7 پروژه تشکیل می‌شود که عمده‌ترین خاصیت آن‌ها مقاوم کردن سیستم در مقابل تغییرات نگارش قرارداد است. در این حالت اگر قرار داد تغییر کند، نه هاست و نه افزونه‌ی قدیمی، نیازی به تغییر در کدهای خود نخواهند داشت و این پروژه‌های میانی هستند که کار وفق دادن (adapters) نهایی را برعهده می‌گیرند.


برای ایجاد خودکار View ها و همچنین Adapters ، از افزونه‌ی Visual Studio Pipeline Builder که پیشتر معرفی شد استفاده خواهیم کرد.



سه گزینه‌ی آن هم مشخص هستند. نام پروژه‌ی قرارداد، مسیر پروژه‌ی هاست و مسیر خروجی نهایی معرفی شده. پیش از استفاده از این افزونه نیاز است تا یکبار solution مورد نظر کامپایل شود. پس از کلیک بر روی دکمه‌ی OK، پروژه‌های ذکر شده ایجاد خواهند شد:


پس از ایجاد این پروژه‌ها، نیاز به اصلاحات مختصری در مورد نام اسمبلی و فضای نام هر کدام می‌باشد؛ زیرا به صورت پیش فرض هر کدام به نام template نامگذاری شده‌اند:



پیاده سازی افزونه

قالب کاری استفاده از این فریم ورک آماده است. اکنون نوبت به پیاده سازی یک افزونه می‌باشد. به پروژه AddIn مراجعه کرده و ارجاعی را به اسمبلی AddInView خواهیم افزود. به این صورت افزونه‌ی ما به صورت مستقیم با قرارداد سروکار نداشته و ارتباطات، در راستای همان pipeline تعریف شده، جهت مقاوم شدن در برابر تغییرات صورت می‌گیرد:
using System;
using CalculatorConract.AddInViews;
using System.AddIn;

namespace CalculatorAddIn
{
[AddIn]
public class MyCalculatorAddIn : ICalculator
{
public double Operate(string operation, double a, double b)
{
throw new NotImplementedException();
}
}
}

در اینجا افزونه‌ی ما باید اینترفیس ICalculator مربوط به AddInView را پیاده سازی نماید که برای مثال خواهیم داشت:

using System;
using CalculatorConract.AddInViews;
using System.AddIn;

namespace CalculatorAddIn
{
[AddIn("افزونه یک", Description = "توضیحات", Publisher = "نویسنده", Version = "نگارش یک")]
public class MyCalculatorAddIn : ICalculator
{
public double Operate(string operation, double a, double b)
{
switch (operation)
{
case "+":
return a + b;
case "-":
return a - b;
case "*":
return a * b;
default:
throw new NotSupportedException("عملیات مورد نظر توسط این افزونه پشتیبانی نمی‌شود");
}
}
}
}

همانطور که در قسمت قبل نیز ذکر شد، این کلاس باید با ویژگی AddIn مزین شود که توسط آن می‌توان توضیحاتی در مورد نام ، نویسنده و نگارش افزونه ارائه داد.


استفاده از افزونه‌ی تولید شده

هاست برای استفاده از افزونه‌هایی با قرارداد ذکر شده، مطابق pipeline پروژه، نیاز به ارجاعی به اسمبلی HostView دارد و در اینجا نیز هاست به صورت مستقیم با قرارداد کاری نخواهد داشت. همچنین هاست هیچ ارجاع مستقیمی به افزونه‌ها نداشته و بارگذاری و مدیریت آن‌ها به صورت پویا انجام خواهد شد.

نکته‌ی مهم!
در هر دو ارجاع به HostView و یا AddInView باید خاصیت Copy to local به false تنظیم شود، در غیر اینصورت افزونه‌ی شما بارگذاری نخواهد شد.



پس از افزودن ارجاعی به HostView، نمونه‌ای از استفاده از افزونه‌ی تولید شده به صورت زیر می‌تواند باشد که توضیحات مربوطه به صورت کامنت آورده شده است:

using System;
using System.AddIn.Hosting;
using CalculatorConract.HostViews;

namespace Calculator
{
class Program
{
private static ICalculator _calculator;

static void doOperation()
{
Console.WriteLine("1+2: {0}", _calculator.Operate("+", 1, 2));
}

static void Main(string[] args)
{
//مسیر پوشه ریشه مربوطه به خط لوله افزونه‌ها
string path = Environment.CurrentDirectory;

//مشخص سازی مسیر خواندن و کش کردن افزونه‌ها
AddInStore.Update(path);

//یافتن افزونه‌هایی سازگار با شرایط قرارداد پروژه
//در اینجا هیچ افزونه‌ای بارگذاری نمی‌شود
var addIns = AddInStore.FindAddIns(typeof(ICalculator), path);

//اگر افزونه‌ای یافت شد
if (addIns.Count > 0)
{
var addIn = addIns[0]; //استفاده از اولین افزونه
Console.WriteLine("1st addIn: {0}", addIn.Name);

//فعال سازی افزونه و همچنین مشخص سازی سطح دسترسی آن
_calculator = addIn.Activate<ICalculator>(AddInSecurityLevel.Intranet);

//یک نمونه از استفاده آن
doOperation();
}

Console.WriteLine("Press a key...");
Console.ReadKey();
}
}
}

چند نکته جالب توجه در مورد قابلیت‌های ارائه شده:
- مدیریت load و unload پویا
- امکان تعریف سطح دسترسی و ویژگی‌های امنیتی اجرای یک افزونه
- امکان ایزوله سازی پروسه اجرای افزونه از هاست (در ادامه توضیح داده خواهد شد)
- مقاوم بودن پروژه به نگارش‌های مختلف قرارداد


اجرای افزونه در یک پروسه مجزا

حتما با امکانات مرورگر کروم و یا IE8 در مورد اجرای هر tab آن‌ها در یک پروسه‌ی مجزا از پروسه اصلی هاست مطلع هستید. به این صورت پروسه‌ی هاست از رفتار tab ها محافظت می‌شود، همچنین پروسه‌ی هر tab نیز از tab دیگر ایزوله خواهد بود. یک چنین قابلیتی در این فریم ورک نیز پیش بینی شده است.

//فعال سازی افزونه و همچنین مشخص سازی سطح دسترسی آن
//همچنین جدا سازی پروسه اجرایی افزونه از هاست
_calculator = addIn.Activate<ICalculator>(
new AddInProcess(),
AddInSecurityLevel.Intranet);

در این حالت اگر پس از فعال شدن افزونه، یک break point قرار دهیم و به task manager ویندوز مراجعه نمائیم، پروسه‌ی مجزای افزونه قابل مشاهده است.



برای مطالعه بیشتر + ، + ، + و +

مطالب
ایجاد قابلیت قالب یا Theme در ASP.NET MVC
در این مقاله قصد داریم قابلیت ایجاد قالب را در پروژه‌های ASP.NET MVC، فراهم کنیم تا ظاهر سایت یا به اصطلاح  قالب سایت از طریق فایل کانفیگ تغییر کند. همانطور که می‌دانید معماری ASP.NET MVC براساس قراردادهای پیش فرض، قابل تعویض و تغییر طراحی شده است. یکی از این قراردادها، نحوه‌ی پیدا کردن یک view برای کنترلر و اکشن‌های آن است که به صورت زیر در ViewEngine تعریف شده‌است: 
ViewEngine.ViewLocationFormats= "~/Views/{controller}/{action}.cshtml"
در ادامه قصد داریم این مسیر یابی پیش فرض را طوری تغییر دهیم تا در پوشه‌ی themes پروژه و زیرپوشه‌ای با نام قالب که از فایل کانفیگ خوانده می‌شود نیز به دنبال view مرتبط با کنترلر و اکشن بگردد: 
"~/Themes/{ThemeName}/Views/{controller}/{action}.cshtml"
 برای راحتی کار، یک Extension Method برای اینترفیس پایه viewEngin  تعریف می‌کنیم: 
   public static void Themeable(this VirtualPathProviderViewEngine engine)
        {
            var ThemePath = "~/Themes";
            var ThemeName = WebConfigurationManager.AppSettings["MvcTheme"];
            if (string.IsNullOrEmpty(ThemeName))
                return;

            var themeFolder = HttpContext.Current.Server.MapPath(string.Format("{0}/{1}/", ThemePath, ThemeName));
            if (!Directory.Exists(themeFolder))
                throw new DirectoryNotFoundException(string.Format("Theme folder not exists: {0}/{1}}", ThemePath,
                    ThemeName));

            var newViewLocations = new[]
            {
                string.Format("{0}/{1}/Views/{2}/{3}.cshtml", ThemePath, ThemeName, "{1}", "{0}"),
                string.Format("{0}/{1}/Views/Shared/{2}.cshtml", ThemePath, ThemeName, "{0}"),
                 
                // vb.net :
                // string.Format("{0}/{1}/Views/{2}/{3}.vbhtml", ThemePath, ThemeName, "{1}", "{0}"),
                // string.Format("{0}/{1}/Views/Shared/{2}.vbhtml", ThemePath, ThemeName, "{0}"),
            };
            engine.ViewLocationFormats = newViewLocations;
            engine.PartialViewLocationFormats = newViewLocations;
        }
سپس در فایل کانفیگ، نام قالب را وارد کنید: 
  <appSettings>
 ...
    <add key="MvcTheme" value="Test1" />
  </appSettings>
و در فایل Global.asax، قابلیت فراخوانی قالب را فعال کنید:
ViewEngines.Engines.OfType<RazorViewEngine>().Single().Themeable();
حالا کافی است محتویات views اصلی را به پوشه‌ی views  قالب مورد نظر کپی کرده و فایل _ViewStart.cshtml را اصلاح کنید، بطوریکه که به فایل layout  داخل پوشه قالب اشاره کند: 
@{
    // Layout = "~/Views/Shared/_Layout.cshtml";
    Layout = "~/themes/test1/Views/Shared/_Layout.cshtml";
}
تا اینجای کار را اگر امتحان کنید، همه چیز درست است؛ مگر اینکه بخواهید از Bundling استفاده کنید. اگر بخواهید از css و اسکریپت‌های اصلی پروژه استفاده کنید، می‌توانید از همان  bundle‌های اصلی، در داخل layout و سایر viewهای قالب استفاده کنید. ولی اینکار نمی‌تواند کاربردی باشد؛ چون ساختار و اجزای هر قالب می‌تواند کاملا مجزا باشد. مثلا در یک قالب از  بوت استرپ استفاده می‌کنیم و در قالبی دیگر از UI Fabric مایکروسافت استفاده می‌کنیم. به همین دلیل، دست به کار می‌شویم و یک Bundling داینامیک را طراحی می‌کنیم:
ابتدا مدل زیر را تعریف کنید:
    public class ThemeBundle
    {
        public BundleType BundleType { get; set; }
        public string VirtualPath { get; set; }
        public string[] Urls { get; set; }
    }

    public enum BundleType
    {
        Style, Script
    }
در داخل هر پوشه‌ی قالب، به دنبال فایل ThemeBundle.json می‌گردیم تا تعاریف Bundling را از آن بخوانیم و در داخل پروژه استفاده کنیم.
توسط کد زیر bundleها را از محل پوشه‌ی قالب، فراخوانی می‌کنیم:
public static void RegisterThemeBundels(BundleCollection bundles)
        {
            var ThemePath = "~/Themes";
            var ThemeName = WebConfigurationManager.AppSettings["MvcTheme"];
            var ThemeBundleFileName = "ThemeBundle.json";

        List<ThemeBundle> list;

            try
            {
                JavaScriptSerializer jss = new JavaScriptSerializer();
                var jsonaddress =
                    System.Web.HttpContext.Current.Server.MapPath(string.Format("{0}/{1}/{2}", ThemePath, ThemeName, ThemeBundleFileName));
                var json = System.IO.File.ReadAllText(jsonaddress);
                  list = jss.Deserialize<List<ThemeBundle>>(json);
            }
            catch (Exception ex)
            {
                throw new Exception(string.Format("Cannot read {0}. see more error in inner exception.", ThemeBundleFileName), ex);
            }

            foreach (var themeBundle in list)
            {
                switch (themeBundle.BundleType)
                {
                    case BundleType.Script:
                        bundles.Add(new ScriptBundle(themeBundle.VirtualPath).Include(
                            themeBundle.Urls));
                        break;
                    case BundleType.Style:
                        bundles.Add(new StyleBundle(themeBundle.VirtualPath).Include(
                            themeBundle.Urls));
                        break;
                    default:
                        throw new ArgumentOutOfRangeException(nameof(themeBundle.BundleType));
                }
            }
        }
دستور فراخوانی bundle‌ها در صورتیکه نام قالب در فایل کانفیگ تعریف شده باشد:
    public class BundleConfig
    {        
        public static void RegisterBundles(BundleCollection bundles)
        {
            if (MvcTheme.ThemeName != null)
            {
                MvcTheme.RegisterThemeBundels(bundles); 
                return;
            }

            bundles.Add(new ScriptBundle("~/bundles/jquery").Include(
                        "~/Scripts/jquery-{version}.js"));

            bundles.Add(new ScriptBundle("~/bundles/jqueryval").Include(
                        "~/Scripts/jquery.validate*"));
...
}
}
فایل ThemeBundle.json قالب test1 را بصورت زیر تعریف می‌کنیم:
[
  {
    "BundleType": "Script",
    "VirtualPath": "~/themes/test1/js/jquery",
    "Urls": [ "~/themes/test1/js/jquery-1.10.2.js" ]
  },
  {
    "BundleType": "Script",
    "VirtualPath": "~/themes/test1/js/jqueryval",
    "Urls": [ "~/themes/test1/js/jquery.validate.js",
               "~/themes/test1/js/jquery.validate.unobtrusive.js" ]
  },
  {
    "BundleType": "Script",
    "VirtualPath": "~/themes/test1/js/modernizr",
    "Urls": [ "~/themes/test1/js/modernizr-2.6.2.js" ]
  },
  {
    "BundleType": "Script",
    "VirtualPath": "~/themes/test1/js/bootstrap",
    "Urls": [ "~/themes/test1/js/bootstrap.js",
              "~/themes/test1/js/respond.js" ]
  },
  {
    "BundleType": "Style",
    "VirtualPath": "~/themes/test1/css/css",
    "Urls": [ "~/themes/test1/css/bootstrap.css",
              "~/themes/test1/css/site.css" ]
  }
]
در نهایت ساختار پوشه‌ی قالب به صورت زیر می‌باشد:
 Themes
├───Test1
│    │ThemeBundle.json
│    ├───Css
│    ├───Fonts
│    ├───Images
│    ├───Js
│    └───Views
├───Test2
│    │ThemeBundle.json
│    ├───Css
│    ├───Fonts
│    ├───Images
│    ├───Js
│    └───Views
 کد کامل و نهایی :
  public static class MvcTheme
    {
 
        public static string ThemeName { get; }
        public static string ThemePath { get; set; }
        private const string AppSettingName = "MvcTheme";
        private const string ThemeBundleFileName = "ThemeBundle.json";

        static MvcTheme()
        {
            ThemePath = "~/Themes";
            ThemeName = WebConfigurationManager.AppSettings[AppSettingName];
        }

        public static void Themeable(this VirtualPathProviderViewEngine engine)
        {
            if (string.IsNullOrEmpty(ThemeName))
                return;

            var themeFolder = HttpContext.Current.Server.MapPath(string.Format("{0}/{1}/", ThemePath, ThemeName));
            if (!Directory.Exists(themeFolder))
                throw new DirectoryNotFoundException(string.Format("Theme folder not exists: {0}/{1}}", ThemePath,
                    ThemeName));

            var newViewLocations = new[]
            { 
                string.Format("{0}/{1}/Views/{2}/{3}.cshtml", ThemePath, ThemeName, "{1}", "{0}"), 
                string.Format("{0}/{1}/Views/Shared/{2}.cshtml", ThemePath, ThemeName, "{0}"),
                              
                // vb.net :
                // string.Format("{0}/{1}/Views/{2}/{3}.vbhtml", ThemePath, ThemeName, "{1}", "{0}"),
                // string.Format("{0}/{1}/Views/Shared/{2}.vbhtml", ThemePath, ThemeName, "{0}"),

            };
            engine.ViewLocationFormats = newViewLocations;
            engine.PartialViewLocationFormats = newViewLocations; 
        }

        public static void RegisterThemeBundels(BundleCollection bundles)
        {
            if(ThemeName == null)
                return;

            var list = ReadThemeBundles();

            foreach (var themeBundle in list)
            {
                switch (themeBundle.BundleType)
                {
                    case BundleType.Script:
                        bundles.Add(new ScriptBundle(themeBundle.VirtualPath).Include(
                            themeBundle.Urls));
                        break;
                    case BundleType.Style:
                        bundles.Add(new StyleBundle(themeBundle.VirtualPath).Include(
                            themeBundle.Urls));
                        break;
                    default:
                        throw new ArgumentOutOfRangeException(nameof(themeBundle.BundleType));
                }
            }
        }

        public static List<ThemeBundle> ReadThemeBundles()
        {
            try
            {
                JavaScriptSerializer jss = new JavaScriptSerializer();
                var jsonaddress =
                    System.Web.HttpContext.Current.Server.MapPath(string.Format("{0}/{1}/{2}", ThemePath, ThemeName, ThemeBundleFileName));
                var json = System.IO.File.ReadAllText(jsonaddress);
                var list = jss.Deserialize<List<ThemeBundle>>(json);

                return list;
            }
            catch (Exception ex)
            {
                throw new Exception(string.Format("Cannot read {0}. see more error in inner exception.", ThemeBundleFileName), ex);
            }
        }
    }

    public class ThemeBundle
    {
        public BundleType BundleType { get; set; }
        public string VirtualPath { get; set; }
        public string[] Urls { get; set; }
    }

    public enum BundleType
    {
        Style, Script
    }
- نکته یک: با حذف مقدار نام قالب در فایل کانفیگ، به راحتی به حالت پیش فرض asp.net mvc بر میگردید.
- نکته دو: نام bundle را حتما هم عمق با آدرس قالب تعریف کنید تا وقتی فایل css  به پوشه‌ی images  یا فونت مجاور خود اشاره می‌کند، آدرس دهی معتبر باشد.
- نکته سه: اگر از RazorGenerator استفاده می‌کنید، در فایل RazorGeneratorMvcStart متد ()Themeable را بر روی engine آن صدا بزنید. 
نظرات مطالب
بررسی مشکلات AngularJS 1.x
بنده قصد خراب کردن این فریمورک را نداشتم. اشکالات بیان شده همگی مربوط به مقالاتی هستند که توسعه دهندگان به اشتراک گذاشتند. من هم آن‌ها را تایید نکردم ولی وقتی می‌بینید که angular 2 همان اشکالات وارد شده به نسخه 1 را برطرف کرده است می‌توان نتیجه  گرفت که اشکالات نسخه 1 صحیح بوده اند و باید اصلاح می‌شدند.
بنده هم نگفتم که انگولار را یاد نگیرید، گفتم "حداقل یادگیری آن را تا انتشار نسخه‌ی 2 آن به تعویق بیندازید."
نکته بحث "الان" هست نه گذشته. الان که قرار هست نسخه‌ی 2 منتشر شه و تغییرات زیادی داره چه دلیلی داره پروژه جدیدی را با آن شروع کنیم و بعد شروع به تغییر کدهایمان کنیم.
بله راهنمایی برای مهاجرت از نسخه‌ی 1 به نسخه 2 وجود دارد: 
اگر با این روش با آپگرید پروژتون که ممکن است چند هزار خط داشته باشد مشکلی ندارید، معطل نکنید همین امروز پروژه جدیدتون را با انگولار آغاز کنید.
باز هم نمی‌گویم انگولار بد است، همین الان میشود مقاله ای برای مزیت‌های نوشت. فقط قصدم این بود که به هنگام استفاده از انگولار و توسعه spa این موارد را هم در نظر داشته باشید.


مسیرراه‌ها
React 16x
پیش نیاز ها
کامپوننت ها
ترکیب کامپوننت ها
طراحی یک گرید
مسیریابی 
کار با فرم ها
ارتباط با سرور
احراز هویت و اعتبارسنجی کاربران 
React Hooks  
توزیع برنامه

مدیریت پیشرفته‌ی حالت در React با Redux و Mobx   

       Redux
       MobX  

مطالب تکمیلی 
    مطالب
    استفاده از افزونه‌های Owin مخصوص سایر نگارش‌های ASP.NET در ASP.NET Core
    همانطور که اطلاع دارید یکسری از کتابخانه‌های کمکی و ثالث ASP.NET Core همچون OData و SignalR ، Thinktecture IdentityServer هنوز در حال تکمیل هستند و از آنجایی که هر روزه محبوبیت ASP.NET Core در بین برنامه نویسان در حال افزایش است و خیلی از پروژه‌های نرم افزاری که امروزه start میخورند، از این فریم ورک جدید استفاده میکنند، پس خیلی به اهمیت این مقوله افزوده میشود که بتوان از تکنولوژی‌های فوق در پروژه‌های جدید نیز استفاده کرد و یکی از معقول‌ترین راه‌های ممکن آن، پیاده سازی Owin  در کنار ASP.NET Core Pipeline میباشد. بدین معنا که ما قصد نداریم owin pipeline را جایگزین آن نماییم؛ همانطور که در ادامه‌ی این مقاله گفته خواهد شد، از هر دو معماری (افزونه‌های Owin مخصوص نگارش کامل دات نت و همچنین خود ASP.NET Core) در کنار هم استفاده خواهیم کرد.
    پیشنیاز این مقاله آشنایی با ASP.NET Core و MiddleWare و همچنین آشنایی با Owin میباشد. همانطور که عرض کردم اگر مقاله‌ی پیاده سازی OData را مطالعه کرد‌ه‌اید و هم اکنون قصد و یا علاقه‌ی به استفاده‌ی از آن را در پروژه‌ی ASP.NET Core خود دارید، میتوانید این مقاله را دنبال نمایید.
    پس تا کنون متوجه شدیم که هدف از این کار، توانایی استفاده از ابزارهایی است که با Owin سازگاری کامل را دارند و همچنین به نسخه‌ی پایدار خود رسیده‌اند. بطور مثال IdentityServer 4 در حال تهیه است که با ASP.NET Core سازگار است. اما هنوز چند نسخه‌ی beta از آن بیرون آمده و به پایداری کامل نرسیده است. همچنین زمان توزیع نهایی آن نیز دقیقا مشخص نیست.
    شما برای استفاده از ASP.NET Core RTM 1.0 احتیاج به Visual studio 2015 update 3 دارید. ابتدا یک پروژه‌ی #C از نوع Asp.Net Core Web Application  را «به همراه full .Net Framework» به نام OwinCore میسازیم.
    در حال حاضر بدلیل اینکه پکیج‌هایی مانند OData, SignalR هنوز به نسخه‌ی Net Coreی خود آماده نشده‌اند (در حال پیاده سازی هستند)، پس مجبور به استفاده از full .Net framework هستیم و خوب مسلما برنامه در این حالت چند سکویی نخواهد بود. اما به محض اینکه آن‌ها آماده شدند، میتوان full .Net را کنار گذاشته و از NET Core. استفاده نمود و از آنجایی که Owin فقط یک استاندارد هست، هیچ مشکلی با NET Core. نداشته و برنامه را میتوان بدان منتقل کرد و از مزایای چند سکویی بودن آن نیز بهره برد. پس مشکل در حال حاضر Owin نبوده و مجبور به منتظر بودن برای آماده شدن این پکیج‌ها خواهیم بود. مثال عملی این قضیه نیز Nancy است که نسخه‌ی NET Core.ی آن با استفاده از Owin در ASP.NET Core پیاده سازی شده است. در اینجا مثال عملی آن را میتوانید پیدا کنید.


    در قسمت بعد، قالب را هم از نوع empty انتخاب مینماییم.


    در ادامه فایل project.json را باز کرده و در قسمت dependencies، تغییرات زیر را اعمال نمایید.

    قبل از اینکه شما را از این همه وابستگی نگران کنم، باید عرض کنم فقط Microsoft.Owin , Microsoft.AspNetCore.Owin، پکیج‌های اجباری هستند؛ باقی آن‌ها برای نشان دادن انعطاف پذیری بالای این روش میباشند:

    "dependencies": {
        "Microsoft.AspNet.OData": "5.9.1",
        "Microsoft.AspNet.SignalR": "2.2.1",
        "Microsoft.AspNet.WebApi.Client": "5.2.3",
        "Microsoft.AspNet.WebApi.Core": "5.2.3",
        "Microsoft.AspNet.WebApi.Owin": "5.2.3",
        "Microsoft.AspNetCore.Diagnostics": "1.0.0",
        "Microsoft.AspNetCore.Hosting": "1.0.0",
        "Microsoft.AspNetCore.Mvc": "1.0.0",
        "Microsoft.AspNetCore.Owin": "1.0.0",
        "Microsoft.AspNetCore.Server.IISIntegration": "1.0.0",
        "Microsoft.AspNetCore.Server.Kestrel": "1.0.0",
        "Microsoft.Extensions.Logging.Console": "1.0.0",
        "Microsoft.Net.Http": "2.2.29",
        "Microsoft.Owin": "3.0.1",
        "Microsoft.Owin.Diagnostics": "3.0.1",
        "Microsoft.Owin.FileSystems": "3.0.1",
        "Microsoft.Owin.StaticFiles": "3.0.1",
        "Newtonsoft.Json": "9.0.1"
      },
    //etc...

    بعد از ذخیره کردن این فایل، در پنجره‌ی Output خود شاهد دانلود شدن این پکیج‌ها خواهید بود. در اینجا پکیج‌های مربوط به Owin, Odata, SignalR را مشاهد می‌کنید. ضمن اینکه در کنار آن، AspNetCore.Mvc را نیز مشاهده میفرمایید. دلیل این کار این است که این دو نوع متفاوت قرار است در کنار هم کار کنند و هیچ مشکلی با دیگری ندارند.

    در مسیر اصلی پروژه‌ی خود کلاسی به نام OwinExtensions را با محتوای زیر بسازید:

    namespace OwinCore
    {
        public static class OwinExtensions
        {
            public static IApplicationBuilder UseOwinApp(
                this IApplicationBuilder aspNetCoreApp,
                Action<IAppBuilder> configuration)
            {
                return aspNetCoreApp.UseOwin(setup => setup(next =>
                {
                    AppBuilder owinAppBuilder = new AppBuilder();
    
                    IApplicationLifetime aspNetCoreLifetime = (IApplicationLifetime)aspNetCoreApp.ApplicationServices.GetService(typeof(IApplicationLifetime));
    
                    AppProperties owinAppProperties = new AppProperties(owinAppBuilder.Properties);
    
                    owinAppProperties.OnAppDisposing = aspNetCoreLifetime?.ApplicationStopping ?? CancellationToken.None;
    
                    owinAppProperties.DefaultApp = next;
    
                    configuration(owinAppBuilder);
    
                    return owinAppBuilder.Build<Func<IDictionary<string, object>, Task>>();
                }));
            }
        }
    }

    یک Extension Method به نام UseOwinApp اضافه شده به IApplicationBuilder که مربوط به ASP.NET Core میباشد و درون آن نیز AppBuilder را که مربوط به Owin pipeline میباشد، نمونه سازی کرده‌ایم که باعث میشود Owin pipeline بر روی ASP.NET Core pipeline سوار شود.

    حال میخواهیم یک Middleware سفارشی را با استفاده از Owin نوشته و در Startup پروژه، آن را فراخوانی نماییم. کلاسی به نام AddSampleHeaderToResponseHeadersOwinMiddleware را با محتوای زیر تولید مینماییم:

    namespace OwinCore
    {
        public class AddSampleHeaderToResponseHeadersOwinMiddleware : OwinMiddleware
        {
            public AddSampleHeaderToResponseHeadersOwinMiddleware(OwinMiddleware next)
                : base(next)
            {
            }
            public async override Task Invoke(IOwinContext context)
            {
                //throw new InvalidOperationException("ErrorTest");
    
                context.Response.Headers.Add("Test", new[] { context.Request.Uri.ToString() });
    
                await Next.Invoke(context);
            }
        }
    }

    کلاسی است که از owinMiddleware ارث بری کرده و در متد override شده‌ی Invoke نیز با استفاده از IOwinContext، به پیاده سازی Middleware خود میپردازیم. Exception مربوطه را comment کرده (بعدا در مرحله‌ی تست از آن نیز استفاده مینماییم) و در خط بعدی در هدر response هر request، یک شیء را به نام Test و با مقدار Uri آن request، میسازیم.

    خط بعدی هم اعلام میدارد که به Middleware بعدی برود.

    در ادامه فایل Startup.cs را باز کرده و اینگونه متد Configure را تغییر دهید:

    public void Configure(IApplicationBuilder aspNetCoreApp, IHostingEnvironment env)
            {
                aspNetCoreApp.UseOwinApp(owinApp =>
                {
                    if (env.IsDevelopment())
                    {
                        owinApp.UseErrorPage(new ErrorPageOptions()
                        {
                            ShowCookies = true,
                            ShowEnvironment = true,
                            ShowExceptionDetails = true,
                            ShowHeaders = true,
                            ShowQuery = true,
                            ShowSourceCode = true
                        });
                    }
    
                    owinApp.Use<AddSampleHeaderToResponseHeadersOwinMiddleware>();
                });
            }

    مشاهده میفرمایید با استفاده از UserOwinApp میتوانیم Middleware‌های Owinی خود را register نماییم و نکته‌ی قابل توجه این است که در کنار آن نیز می‌توانیم از IHostingEnviroment مربوط به ASP.NET core استفاده نماییم. owinApp.UseErrorPage از Microsoft.Owin.Diagnostics گرفته شده است و در خط بعدی نیز Middleware شخصی خود را register کرده‌ایم. پروژه را run کرده و در response این را مشاهد مینمایید.

    اکنون اگر در Middleware سفارشی خود، آن Exception را از حالت comment در بیاوریم، در صورتیکه در حالت development باشیم، با این صفحه مواجه خواهیم شد:

    Exception مربوطه را به حالت comment گذاشته و ادامه میدهیم.

    برای اینکه نشان دهیم Owin و ASP.NET Core pipeline در کنار هم میتوانند کار کنند، یک Middleware را از نوع ASP.NET Core نوشته و آن را register مینماییم. کلاسی جدیدی را به نام AddSampleHeaderToResponseHeadersAspNetCoreMiddlware با محتوای زیر میسازیم:

    namespace OwinCore
    {
        public class AddSampleHeaderToResponseHeadersAspNetCoreMiddlware
        {
            private readonly RequestDelegate Next;
    
            public AddSampleHeaderToResponseHeadersAspNetCoreMiddlware(RequestDelegate next)
            {
                Next = next;
            }
    
            public async Task Invoke(HttpContext context)
            {
                //throw new InvalidOperationException("ErrorTest");
    
                context.Response.Headers.Add("Test2", new[] { "some text" });
    
                await Next.Invoke(context);
            }
        }
    }

    متد Configure در Startup.cs را نیز اینگونه تغییر میدهیم

    public void Configure(IApplicationBuilder aspNetCoreApp, IHostingEnvironment env)
            {
                aspNetCoreApp.UseOwinApp(owinApp =>
                {
                    if (env.IsDevelopment())
                    {
                        owinApp.UseErrorPage(new ErrorPageOptions()
                        {
                            ShowCookies = true,
                            ShowEnvironment = true,
                            ShowExceptionDetails = true,
                            ShowHeaders = true,
                            ShowQuery = true,
                            ShowSourceCode = true
                        });
                    }
    
                    owinApp.Use<AddSampleHeaderToResponseHeadersOwinMiddleware>();
                });
    
                aspNetCoreApp.UseMiddleware<AddSampleHeaderToResponseHeadersAspNetCoreMiddlware>();
            }

    اکنون AddSampleHeaderToResponseHeadersAspNetCoreMiddlware رجیستر شده است و بعد از run کردن پروژه و بررسی header response باید این را ببینیم

    میبینید که به ترتیب اجرای Middleware‌ها، ابتدا Test مربوط به Owin و بعد آن Test2 مربوط به ASP.NET Core تولید شده است.

    حال اجازه دهید Odata را با استفاده از Owin پیاده سازی نماییم. ابتدا کلاسی را به نام Product با محتوای زیر تولید نمایید:

    namespace OwinCore
    {
        public class Product
        {
            public int Id { get; set; }
            public string Name { get; set; }
            public decimal Price { get; set; }
        }
    }

    حال کلاسی را به نام ProductsController با محتوای زیر میسازیم:

    namespace OwinCore
    {
        public class ProductsController : ODataController
        {
            [EnableQuery]
            public IQueryable<Product> Get()
            {
                return new List<Product>
                {
                     new Product { Id = 1, Name = "Test" , Price = 10 }
                }
                .AsQueryable();
            }
        }
    }

    اگر مقاله‌ی پیاده سازی Crud با استفاده از OData را مطالعه کرده باشید، قاعدتا با این کد‌ها آشنا خواهید بود. ضمن اینکه پرواضح است که OData هیچ وابستگی به entity framework ندارد.

    برای config آن نیز در Startup.cs پروژه و متد Configure، تغییرات زیر را اعمال مینماییم.

    public void Configure(IApplicationBuilder aspNetCoreApp, IHostingEnvironment env)
            {
                //aspNetCoreApp.UseMvc();
    
                aspNetCoreApp.UseOwinApp(owinApp =>
                {
                    if (env.IsDevelopment())
                    {
                        owinApp.UseErrorPage(new ErrorPageOptions()
                        {
                            ShowCookies = true,
                            ShowEnvironment = true,
                            ShowExceptionDetails = true,
                            ShowHeaders = true,
                            ShowQuery = true,
                            ShowSourceCode = true
                        });
                    }
                    // owinApp.UseFileServer(); as like as asp.net core static files middleware
                    // owinApp.UseStaticFiles(); as like as asp.net core static files middleware
                    // owinApp.UseWebApi(); asp.net web api / odata / web hooks
    
                    HttpConfiguration webApiConfig = new HttpConfiguration();
                    ODataModelBuilder odataMetadataBuilder = new ODataConventionModelBuilder();
                    odataMetadataBuilder.EntitySet<Product>("Products");
                    webApiConfig.MapODataServiceRoute(
                        routeName: "ODataRoute",
                        routePrefix: "odata",
                        model: odataMetadataBuilder.GetEdmModel());
                    owinApp.UseWebApi(webApiConfig);
    
                    owinApp.MapSignalR();
    
                    //owinApp.Use<AddSampleHeaderToResponseHeadersOwinMiddleware>();
                });
    
                //aspNetCoreApp.UseMiddleware<AddSampleHeaderToResponseHeadersAspNetCoreMiddlware>();
            }

    برای config مخصوص Odata، به HttpConfiguration نیاز داریم. بنابراین instanceی از آن گرفته و برای مسیریابی Odata از آن استفاده مینماییم.

    با استفاده از پیاده سازی که از استاندارد Owin انجام دادیم، مشاهده کردید که Odata را همانند یک پروژه‌ی معمولی asp.netی، config نمودیم. در خط بعدی هم SignalR را مشاهده مینمایید.

    اکنون اگر آدرس زیر را در مرورگر خود وارد نمایید، پاسخ زیر را از Odata دریافت خواهید کرد:

    http://localhost:YourPort/odata/Products

    بعد از فرستادن request فوق، باید response زیر را دریافت نمایید:

    { 
     "@odata.context":"http://localhost:4675/odata/$metadata#Products","value":[
        {
          "Id":1,"Name":"Test","Price":10
        }
      ]
    }

    تعداد زیادی Owin Middleware موجود همانند Thinktecture IdentityServer, NWebSec, Nancy, Facebook OAuth , ... هم با همان آموزش راه اندازی بر روی Owin که دارند میتوانند در ASP.NET Core نیز استفاده شوند و زمانی که نسخه‌ی ASP.NET Core اینها به آمادگی کامل رسید، با کمترین تغییری میتوان از آنها استفاده نمود.
    اگر در پیاده سازی مقاله‌ی فوق با مشکل رو به رو شدید (اگر مراحل به ترتیب اجرا شوند، مشکلی نخواهید داشت) میتوانید از Github ، کل این پروژه را clone کرده و همچنین طبق commit‌های منظم از طریق history آن، مراحل جلو رفتن پروژه را دنبال نمایید.
    مطالب
    آشنایی با CLR: قسمت سوم
    در اینجا ما زیاد بر روی جزئیات یک اسمبلی مانور نمی‌دهیم و آن را به آینده موکول می‌کنیم و فقط مقداری از مباحث اصلی را ذکر می‌کنیم.

    ترکیب ماژول‌های مدیریت شده به یک اسمبلی

    اگر حقیقت را بخواهید CLR نمی‌تواند با ماژول‌ها کار کند، بلکه با اسمبلی‌ها کار می‌کند. اسمبلی یک مفهوم انتزاعی است که به سختی میتوان برای بار اول آن را درک کرد.
    اول از همه: اسمبلی یک گروه منطقی از یک یا چند ماژول یا فایل‌های ریسورس (منبع) است.
    دوم: اسمبلی کوچکترین واحد استفاده مجدد، امنیت و نسخه بندی است.
    بر اساس انتخابی که شما در استفاده از کامپایلرها و ابزارها کرده‌اید، نسخه‌ی نهایی شامل یک یا چند فایل اسمبلی خواهد شد. در دنیای CLR ما یک اسمبلی را کامپوننت صدا می‌زنیم.

    شکل زیر در مورد اسمبلی‌ها توضیح می‌دهد. آنچه که شکل زیر توضیح می‌دهد تعدادی از ماژول‌های مدیریت شده به همراه فایل‌های منابع یا دیتا توسط ابزارهایی که مورد پردازش قرار گرفته‌اند به فایل‌های 32 یا 64 بیتی تبدیل شده‌اند که داخل یک گروه بندی منطقی از فایل‌ها قرار گرفته‌اند. آنچه که اتفاق می‌افتد این هست که این فایل‌های 32 یا 64 بیتی شامل بلوکی از داده‌هایی است که با نام manifest شناخته می‌شوند. manifest یک مجموعه دیگر از جداول متادیتا‌ها است. این جداول به توصیف فایل‌های تشکیل دهنده اسمبلی می‌پردازد.

    همه کارهای تولید اسمبلی به صورت خودکار اتفاق می‌افتد. ولی در صورتیکه قصد دارید فایلی را به اسمبلی به طور دستی اضافه کنید نیاز است که به دستورات و ابزارهای کامپایلر آشنایی داشته باشید.

    یک اسمبلی به شما اجازه می‌دهد تا مفاهیم فیزیکی و منطقی کامپوننت را از هم جدا سازید. اینکه چگونه کد و منابع خود را از یکدیگر جدا کنید به خود شما بر می‌گردد. برای مثال اگر قصد دارید منابع یا نوع داده‌ای را که به ندرت مورد استفاده قرار می‌گیرد، در یک فایل جدا از اسمبلی نگهداری کنید، این فایل جدا میتواند بر اساس تقاضای کاربر در زمان اجرای برنامه از اینترنت دریافت شود. حال اگر همین فایل هیچگاه استفاده نشود، در زمان نصب برنامه و مقدار حافظه دیسک سخت صرفه جویی خواهد شد. اسمبلی‌ها به شما اجازه می‌دهند که فایل‌های توزیع برنامه را به چندین قسمت بشکنید، در حالی که همه‌ی آن‌ها متعلق به یک مجموعه هستند.

    یک ماژول اسمبلی شامل اطلاعاتی در رابطه با ارجاعاتش است؛ به علاوه ورژن خود اسمبلی. این اطلاعات سبب می‌شوند که یک اسمبلی خود تعریف self-describing شود که به بیان ساده‌تر باعث می‌شود CLR وابستگی‌های یک اسمبلی را تشخیص داده تا ترتیب اجرای آن‌ها را پیدا کند. نه دیگر نیازی به اطلاعات اضافی در ریجستری است و نه در Active Directory Domain Service یا به اختصار ADDS.

    از آنجایی که هیچ اطلاعاتی اضافی نیست، توزیع ماژول‌های مدیریت شده راحت‌تر از ماژول‌های مدیریت نشده است.

    مطلب مشابهی نیز در وبلاگ آقای شهروز جعفری برای توصیف اسمبلی‌ها وجود دارد که خیلی خوب هست به قسمت مطالب مرتبط آن هم نگاهی داشته باشید.