اشتراکها
71 Loaders زیبا
Detecting the end of CSS animation and transition could be useful if you
want to back up some of your JavaScript behavior on CSS. Demo
در همان callback اعتبارسنجی (function (value, element, param به element در حال بررسی، دسترسی وجود دارد. اما اینجا کاربردی ندارد، چون مخفی است (تصویر اول). یعنی focus بر روی آن، یا تغییر CSS آن قابل مشاهده نخواهد بود. اما داخل همین رویداد گردان میتوان نوشت:
$(".froala-element").focus(); $(".froala-element").css({"border-color": "red"});
خیر. احتمالا به این علت که آنچنان مرسوم نیست از چندین قلم در وب استفاده شود، منهای CSS اصلی سایت و تعریف قلمهای اصلی برای هدرها و امثال آن. به علاوه قلم متن نمایش داده شده در صفحات باید تابع CSS سایت باشد نه ادیتور آن.
ولی در کل میتونید براش افزونه بنویسید تا اینکار را انجام دهد.
ولی در کل میتونید براش افزونه بنویسید تا اینکار را انجام دهد.
نظرات مطالب
استفاده از reCAPTCHA در ASP.NET
این مورد بیشتر به تداخل css کلی سایت با این کنترل مربوط میشود. بهترین کار استفاده از firebug است. ابتدا در برگه net آن بررسی کنید پیام 404 ایی مشاهده میشود؟ ممکن است چیزی از قلم افتاده باشد. سپس به وسیله firebug به صورت live شروع به ویرایش css المان انتخاب شده کنید تا به نتیجه برسید.
احتمالا فایرفاکس 4 رو تازه نصب کردید:
یکی از موارد جالب توجه آن منهای مورد فوق، امکان تغییر سایز TextArea در آن به صورت "سر خود" میباشد (همانند مرورگر کروم) :
برای غیرفعال کردن این قابلیت باید css سایت یا عنصر مورد نظر را به صورت ذیل تغییر داد:
<style type="text/css">
textarea {
resize:none;
}
</style>
یک نکته تکمیلی: امکان انتقال کدهای #C یک کامپوننت، به یک فایل مجزای code behind نیز وجود دارد
روال متداول کار با کامپوننتهای Razor، قرار دادن کدهای #C مربوط به آنها، در قسمت {}code@ همان فایل، با پسوند razor. است. میتوان جهت بالا بردن قابلیت نگهداری کدهای کامپوننتها، برخوردار شدن از intellisense بهتری و همچنین کاهش حجم فایلهای razor. که در نهایت به خوانایی بیشتر و سادهتر آنها منتهی میشود، قطعهی {}code@ را به یک فایل سیشارپ مجزا منتقل کرد؛ با این شرایط و نکات خاص:
- اگر برای مثال نام یک کامپوننت، login.razor است، فایل code behind آن باید با همان نام شروع شود و ختم به cs. شود؛ یعنی در این مثال باید دقیقا نام login.razor.cs را داشته باشد و محتوای ابتدایی آن اکنون به صورت زیر خواهد بود:
- پس از آن، یک چنین قطعه کدی، کامپایل نخواهد شد؛ چون کامپوننت login.razor که در پوشهی folder1/folder2 واقع شدهاست نیز توسط کامپایلر به یک چنین کلاسی ترجمه میشود. برای رفع این مشکل، باید کلاس را به صورت partial تعریف کرد تا کدهای آن جزئی از کدهای کامپوننت login.razor شوند:
- اکنون جهت انتقال کدهای قطعه {}code@، فقط کافی است آنها را انتخاب و cut کرده و سپس در بدنهی کلاس فوق، paste کنیم. در این حالت نیازی نیست سطوح دسترسی قسمتهای مختلف کد، مانند private و protected را تغییر داد و همه چیز مانند قبل خواهد بود.
چند نکته:
- سرویسهایی که با دایرکتیو inject@ تعریف میشوند، در اینجا به صورت زیر توسط Attributes تعریف خواهند شد:
- فایل سراسری Imports.razor_ که جهت تعریف فضاهای نام تکراری مورد استفاده قرار میگرفت، در اینجا کاربردی نداشته و نیاز است فضاهای نام را همانند کدهای متداول #C، در ابتدای فایل cs. جاری ذکر کرد.
- جهت بهبود Intellisense متناظر با قابلیتهای Blazor، بهتر است کلاس partial تعریف شده، از کلاس پایه ComponentBase نیز ارث بری کند:
روال متداول کار با کامپوننتهای Razor، قرار دادن کدهای #C مربوط به آنها، در قسمت {}code@ همان فایل، با پسوند razor. است. میتوان جهت بالا بردن قابلیت نگهداری کدهای کامپوننتها، برخوردار شدن از intellisense بهتری و همچنین کاهش حجم فایلهای razor. که در نهایت به خوانایی بیشتر و سادهتر آنها منتهی میشود، قطعهی {}code@ را به یک فایل سیشارپ مجزا منتقل کرد؛ با این شرایط و نکات خاص:
- اگر برای مثال نام یک کامپوننت، login.razor است، فایل code behind آن باید با همان نام شروع شود و ختم به cs. شود؛ یعنی در این مثال باید دقیقا نام login.razor.cs را داشته باشد و محتوای ابتدایی آن اکنون به صورت زیر خواهد بود:
namespace ProjectName.Folder1.Folder2 { public class Login { } }
namespace ProjectName.Folder1.Folder2 { public partial class Login { } }
چند نکته:
- سرویسهایی که با دایرکتیو inject@ تعریف میشوند، در اینجا به صورت زیر توسط Attributes تعریف خواهند شد:
namespace ProjectName.Folder1.Folder2 { public partial class Login { [Inject] public NavigationManager NavigationManager { set; get; } // ... } }
- جهت بهبود Intellisense متناظر با قابلیتهای Blazor، بهتر است کلاس partial تعریف شده، از کلاس پایه ComponentBase نیز ارث بری کند:
namespace ProjectName.Folder1.Folder2 { public partial class Login : ComponentBase { [Inject] public NavigationManager NavigationManager { set; get; } // ... } }
قسمت اول
4. فشرده سازی HTTP را فعال کنید
اطمینان حاصل کنید که HTTP Compression در تمامی بخشهای اصلی برنامه شما فعال است. حداقل کاری که میتوانید در این رابطه بکنید این است که خروجی HTML که توسط برنامه شما تولید میشود را فشرده سازی کنید. جهت فعال سازی فشرده سازی در برنامه خود بهتر است در اولویت اول از ماژول ویژه ای که جهت این کار در IIS در نظر گرفته شده استفاده کنید. این ماژول تمامی کارها را به صورت خودکار برای شما انجام میدهد. اگر دسترسی به IIS جهت فعال سازی آن را ندارید، میتوانید از ماژولهای ASP.NET که جهت این کار تهیه شده استفاده کنید. میتوانید کمی جستجو کنید و یا خودتان یکی تهیه کنید!
5.تنظیم CacheControlMaxAge
مقدار CacheControlMaxAge را در فایل web.config را طوری تنظیم کنید تا هیچ کاربری هیچ فایل static را دیگر درخواست نکند. مثلا میتوانید این مقدار را بر روی چند ماه تنظیم کنید و البته فراموش نکنید این مقدار را در صفحات پویای خود بازنویسی (override) کنید تا مشکلی در رابطه با کش شدن فرمهای اصلی برنامه (همانطور که در نکته اول بخش اول ذکر شد) پدید نیاید. البته کش کردن فایلهای استاتیک برنامه بار مالی نیز برای شما و کاربرانتان خواهد داشت. دیگر هزینه پهنای باند اضافی جهت دانلود این فایلها در هر درخواست برای شما (در سمت سرور) و کاربرانتان (در سمت کاربر) پرداخت نخواهد شد!
6. استفاده از OutputCache
اگر از MVC استفاده میکنید، فراموش نکنید که از OutputCache در کنترلهای MVC استفاده نمایید. اگر سرور شما بتواند اطلاعات را از رم خود بازیابی کند بهتر از آن است که آن را مجدد از دیتابیس واکشی نماید و عملیاتی نیز بر روی آن انجام دهد. البته مدیریت حافظه .NET به صورت خودکار کمبود حافظه را مدیریت کرده و از نشت حافظه جلوگیری خواهد کرد. برای توضیحات بیشتر در این رابطه میتوانید از این مقاله کمک بگیرید.
7. بهره برداری از ORM Profiler
ORM Profiler ها تمامی فعالیتهای ORM تحت نظر گرفته، دستورات T-SQL ارسالی به بانک اطلاعاتی را واکشی کرده و برای شما نمایش میدهند. تعدادی از آنها نیز این دستورات را آنالیز کرده پیشنهاداتی در رابطه با بهبود کارایی به شما ارائه میدهند. برای مثال به جای اینکه شما 2000 رکورد را یکی یکی از بانک بازیابی کنید، میتوانید آن را به صورت یک query به بانک ارسال کنید. این موضوع به سادگی توسط ORM Profilerها قابل بررسی است. نمونه ای از این نرم افزارها را میتوانید در این سایت یا این سایت پیدا کنید. البته در صورتی که نمیخواهید از نرم افزارهای جانبی استفاده کنید، میتوانید از ابزارهای توکار بانکهای اطلاعاتی مانند SQL Profiler نیز استفاده کنید (راهنمایی).
از دقت کردن در نحوه اداره پروژههای خوب و بزرگ در سطح دنیا، میتوان به نکات آموزندهای رسید. برای مثال NHibernate را درنظر بگیرید. این پروژه شاید روز اول کپی مطابق اصل نمونه جاوای آن بوده، اما الان از خیلی از جهات یک سر و گردن از آن بالاتر است. پشتیبانی LINQ را اضافه کرده، خودش Syntax جدیدی را به نام QueryOver ارائه داده و همچنین معادلی را جهت حذف فایلهای XML به کمک امکانات جدید زبانهای دات نتی مانند lambda expressions ارائه کرده. خلاصه این تیم، فقط یک کپی کار نیست. پایه رو از یک جایی گرفته اما سبب تحول در آن شده. از اهداف پروژههای سورس باز هم همین است: برای هر کاری چرخ را از صفر ابداع نکنید.
اگر به نحوه اداره کلی پروژه NHibernate دقت کنید یک مورد مشهود است:
- تمام گزارشهای باگ بدون Unit test ندید گرفته میشوند.
- از کلیه بهبودهای ارائه شده (وصلهها یا patch ها) بدون Unit test صرفنظر میشود.
- از کلیه موارد جدید ارائه شده بدون Unit test هم صرفنظر خواهد شد.
بنابراین اگر در issue tracker این تیم رفتید و گفتید: «سلام، اینجا این مشکل هست»، خیالتان راحت باشد که ندید گرفته خواهید شد.
سؤال : چرا اینها اینطور رفتار میکنند؟!
- وجود Unit test دقیقا مشخص میکند که چه قسمت یا قسمتهایی به گزارش باگ شما مرتبط هستند. نیازی نیست حتما بتوانید یک خطا را با جملات ساده شرح دهید. این مساله خصوصا در پروژههای بین المللی حائز اهمیت است. ضعف زبان انگلیسی همه جا هست. همینقدر که توانستهاید برای آن یک Unit test بنویسید که مثلا در این عملیات با این ورودی، نتیجه قرار بوده بشود 10 و مثلا شده 5 یا حتی این Exception صادر شده که باید کنترل شود، یعنی مشکل را کاملا مشخص کردهاید.
- وجود Unit tests ، انجام Code review و همچنین Refactoring را تسهیل میبخشند. در هر دو حالت یاد شده، هدف تغییر کارکرد سیستم نیست؛ هدف بهبود کیفیت کدهای موجود است. بنابراین دست به یک سری تغییرات زده خواهد شد. اما سؤال اینجا است که از کجا باید مطمئن شد که این تغییرات، سیستم را به هم نریختهاند. پروژهی جاری چند سال است که در حال توسعه است. قسمتهای زیادی به آن اضافه شده. با نبود Unit tests ممکن است بعضی از قسمتها زاید یا احمقانه به نظر برسند.
- بهترین مستندات کدهای تهیه شده، Unit tests آن هستند. برای مثال علاقمند هستید که NHibernate را یاد بگیرید؟ هرچه میگردید مثالهای کمی را در اینترنت در این زمینه پیدا میکنید؟ وقت خودتان را تلف نکنید! این پروژه بالای 2000 آزمون واحد دارد. هر کدام از این آزمونها نحوهی بکارگیری قسمتهای مختلف را به نحوی کاربردی بیان میکنند.
- وجود Unit tests از پیدایش مجدد باگها جلوگیری میکنند. اگر آزمون واحدی وجود نداشته باشد، امروز کدی اضافه میشود. فردا همین کد توسط عدهای دیگر زاید تشخیص داده شده و حذف میشود! بنابراین احتمال بروز مجدد این خطا در آینده وجود خواهد داشت. با وجود Unit tests، فلسفه وجودی هر قسمتی از کدهای موجود پروژه دقیقا مشخص میشود و در صورت حذف آن، با اجرای آزمونهای خودکار سریعا میتوان به کمبودهای حاصل پیبرد.