بله. درسته. علت هم این است که خروجی RenderSection نهایتا یک رشته است که باید توسط @ در Response درج شود.
۱۲ سال و ۶ ماه قبل، شنبه ۲۶ فروردین ۱۳۹۱، ساعت ۲۰:۳۶
۱۲ سال و ۶ ماه قبل، پنجشنبه ۲۴ فروردین ۱۳۹۱، ساعت ۱۶:۳۳
۱۲ سال و ۵ ماه قبل، دوشنبه ۱۱ اردیبهشت ۱۳۹۱، ساعت ۲۰:۵۵
خواهش می‌کنم. یک مورد دیگر هم هست:
- متدی مانند Html.DisplayFor بر اساس خواص مدل‌های برنامه، به صورت Strongly typed تعریف می‌شود (به کمک همین lambda expressions ایی که مشاهده می‌کنید). اگر مدلی تغییر کند، این View دیگر اجرا نخواهد شد و خطای کامپایل رو دریافت می‌کنید. اما در حالت نوشتن مستقیم و معمولی مثلا یک برچسب یا یک تکست باکس و موارد مشابه، این compile time checking رو از دست خواهید داد.
- متدی مانند Html.DisplayFor بر اساس خواص مدل‌های برنامه، به صورت Strongly typed تعریف می‌شود (به کمک همین lambda expressions ایی که مشاهده می‌کنید). اگر مدلی تغییر کند، این View دیگر اجرا نخواهد شد و خطای کامپایل رو دریافت می‌کنید. اما در حالت نوشتن مستقیم و معمولی مثلا یک برچسب یا یک تکست باکس و موارد مشابه، این compile time checking رو از دست خواهید داد.
۱۲ سال و ۵ ماه قبل، دوشنبه ۱۱ اردیبهشت ۱۳۹۱، ساعت ۱۶:۳۷
- Viewها در ASP.NET MVC پس از اولین بار فراخوانی، کامپایل می‌شوند. البته می‌شود با دستکاری فایل پروژه، آن‌ها را در زمان build هم کامپایل کرد. در قسمت‌های قبل توضیح دادم. بنابراین سربار این مساله بسیار کم است.
- شاید برای مواردی مانند تکست باکس، لینک و امثال آن، آنچنان تفاوتی در این بین نباشد که از اصل آن‌ها استفاده شود، یا یک متد کمکی. اما مثلا در مورد رندر کردن یک گرید پویا بر اساس پارامترهای انتخابی یک گزارش چطور؟ هدف اصلی، بیشتر این نوع موارد است.
- مباحث caching اطلاعات را هم در قسمت‌های بعدی به آن اشاره کردم. این مورد سبب می‌شود تا اصلا کدی در سمت سرور اجرا نشود. البته در مورد بایدها و نبایدهای آن هم بحث شده در همان مطلب.
- شاید برای مواردی مانند تکست باکس، لینک و امثال آن، آنچنان تفاوتی در این بین نباشد که از اصل آن‌ها استفاده شود، یا یک متد کمکی. اما مثلا در مورد رندر کردن یک گرید پویا بر اساس پارامترهای انتخابی یک گزارش چطور؟ هدف اصلی، بیشتر این نوع موارد است.
- مباحث caching اطلاعات را هم در قسمت‌های بعدی به آن اشاره کردم. این مورد سبب می‌شود تا اصلا کدی در سمت سرور اجرا نشود. البته در مورد بایدها و نبایدهای آن هم بحث شده در همان مطلب.
۱۲ سال و ۶ ماه قبل، جمعه ۱ اردیبهشت ۱۳۹۱، ساعت ۱۴:۱۶
می‌تونید داخل templated helper ایی که تعریف می‌کنید یک
Html.TextBox اضافه کنید که پارامتر html attributes آن مقدار دهی شده است. چون برای نمونه این datePicker مثلا به TextBox ایی با class خاص اعمال می‌شود. مثلا: new { @class = "datepicker"
Html.TextBox اضافه کنید که پارامتر html attributes آن مقدار دهی شده است. چون برای نمونه این datePicker مثلا به TextBox ایی با class خاص اعمال می‌شود. مثلا: new { @class = "datepicker"
۱۲ سال و ۶ ماه قبل، دوشنبه ۲۸ فروردین ۱۳۹۱، ساعت ۱۴:۴۴
به صورت خلاصه DisplayTemplates فقط به متد Html.DisplayFor اعمال می‌شوند و نه خارج از آن. زمانیکه مستقلا از String.Format استفاده می‌کنید، یعنی خودتان قصد دارید اطلاعات را پردازش و فرمت کنید.
۱۲ سال و ۶ ماه قبل، دوشنبه ۲۸ فروردین ۱۳۹۱، ساعت ۱۴:۳۸
- اگر قرار است فایل datetime.cshtml فرمت نهایی را اعمال کند، چرا جایی دیگری می‌خواهید آن‌را فرمت کنید که نوع و نحوه نمایش آن کلا عوض شود؟
- اگر علاقمندید از String.Format استفاده کنید، اصلا نیازی به Html.DisplayFor نبوده. برای نمونه در مثال قسمت 12 جاری، فقط کافی است که Model.AddDate را به تابع String.Format ارسال کنید تا 0:g مورد نظر شما اعمال شود. خروجی نهایی هم یک رشته است و دیگر همانند یک DateTime پردازش نمی‌شود.
- در قسمت 13 در مورد ویژگی به نام DisplayFormat توضیح داده شد. توسط آن هم می‌شود DataFormatString را اعمال کرد. در این حالت برای دستیابی به اطلاعات نهایی فرمت شده در یک display template سفارشی باید از ViewData.TemplateInfo.FormattedModelValue استفاده کنید.
- اگر علاقمندید از String.Format استفاده کنید، اصلا نیازی به Html.DisplayFor نبوده. برای نمونه در مثال قسمت 12 جاری، فقط کافی است که Model.AddDate را به تابع String.Format ارسال کنید تا 0:g مورد نظر شما اعمال شود. خروجی نهایی هم یک رشته است و دیگر همانند یک DateTime پردازش نمی‌شود.
- در قسمت 13 در مورد ویژگی به نام DisplayFormat توضیح داده شد. توسط آن هم می‌شود DataFormatString را اعمال کرد. در این حالت برای دستیابی به اطلاعات نهایی فرمت شده در یک display template سفارشی باید از ViewData.TemplateInfo.FormattedModelValue استفاده کنید.
۱۲ سال و ۶ ماه قبل، دوشنبه ۲۸ فروردین ۱۳۹۱، ساعت ۰۵:۴۳
- برای نمایش خودکار تاریخ فارسی می‌تونید از این فایل استفاده کنید (تست شده) : (^)
- برای حالت nullable هم همین فایل کافی است. یعنی در اصل بهتر است DisplayTemplate برای حالت nullable نوشته شود که برای هر دو حالت مورد استفاده قرار خواهد گرفت.
- در مورد validator هم می‌تونید یک attribute سفارشی تهیه کنید. در قسمت 13 راه کلی انجام کار رو توضیح دادم. برای تاریخ شمسی بحث مفصلی است. یک کلاس قبلا در این مورد تهیه کردم : (^) البته این فقط یک ایده برای شروع است که چه فرمت‌هایی می‌تونه وارد بشه و قابل قبول باشه.
- برای حالت nullable هم همین فایل کافی است. یعنی در اصل بهتر است DisplayTemplate برای حالت nullable نوشته شود که برای هر دو حالت مورد استفاده قرار خواهد گرفت.
- در مورد validator هم می‌تونید یک attribute سفارشی تهیه کنید. در قسمت 13 راه کلی انجام کار رو توضیح دادم. برای تاریخ شمسی بحث مفصلی است. یک کلاس قبلا در این مورد تهیه کردم : (^) البته این فقط یک ایده برای شروع است که چه فرمت‌هایی می‌تونه وارد بشه و قابل قبول باشه.
۱۲ سال و ۶ ماه قبل، دوشنبه ۲۱ فروردین ۱۳۹۱، ساعت ۰۴:۵۱
در مورد Refactoring فایل‌های View در قسمت بعدی توضیح دادم.
۱۲ سال و ۶ ماه قبل، یکشنبه ۲۰ فروردین ۱۳۹۱، ساعت ۲۰:۵۱
خلاصه موردی را که عنوان کردید این است:
اگر یک صفحه داریم که از مثلا 4 ویجت نمایش آب و هوا، نمایش اخبار، نمایش تعداد کاربران حاضر در سایت و آمار سایت و نمایش منوی پویای سایت تشکیل شده، تمام این‌ها رو در یک ViewModel قرار ندیدم که اشتباه است. بله این مورد درست است؛ اما ... به معنای نفی استفاده از ViewModel ها نیست.
هر کدام از ویجت‌ها را می‌شود به Partial viewهای مختلفی برای مثال خرد کرد. اما نهایتا هر کدام از این اجزای کلی سیستم اصلی، نیاز به ViewModel دارند که این مورد، بحث اصلی جاری است. یعنی تفاوت قائل شدن بین domain model و view model. پوشه‌ی مدلی که در ساختار پروژه پیش فرض ASP.NET MVC قرار داره در واقع امر یک ViewModel است و نه مدل به معنای تعریف مدل‌های domain سیستم چون قرار است خواص آن مستقیما در View مورد استفاده قرار گیرند.
استفاده از ViewModelها کار را اندکی بیشتر می‌کنند، چون نهایتا خواص آن‌ها باید به مدل اصلی نگاشت شوند اما خوشبختانه برای این مورد هم راه حل هست و روش پیشنهادی، استفاده از کتابخانه‌ی سورس بازی است به نام AutpoMapper : (^)
اگر یک صفحه داریم که از مثلا 4 ویجت نمایش آب و هوا، نمایش اخبار، نمایش تعداد کاربران حاضر در سایت و آمار سایت و نمایش منوی پویای سایت تشکیل شده، تمام این‌ها رو در یک ViewModel قرار ندیدم که اشتباه است. بله این مورد درست است؛ اما ... به معنای نفی استفاده از ViewModel ها نیست.
هر کدام از ویجت‌ها را می‌شود به Partial viewهای مختلفی برای مثال خرد کرد. اما نهایتا هر کدام از این اجزای کلی سیستم اصلی، نیاز به ViewModel دارند که این مورد، بحث اصلی جاری است. یعنی تفاوت قائل شدن بین domain model و view model. پوشه‌ی مدلی که در ساختار پروژه پیش فرض ASP.NET MVC قرار داره در واقع امر یک ViewModel است و نه مدل به معنای تعریف مدل‌های domain سیستم چون قرار است خواص آن مستقیما در View مورد استفاده قرار گیرند.
استفاده از ViewModelها کار را اندکی بیشتر می‌کنند، چون نهایتا خواص آن‌ها باید به مدل اصلی نگاشت شوند اما خوشبختانه برای این مورد هم راه حل هست و روش پیشنهادی، استفاده از کتابخانه‌ی سورس بازی است به نام AutpoMapper : (^)