اشتراک‌ها
معرفی DevDocs
DevDocs مستندات API‌های متعددی را در یک اینترفیس سریع، منظم و قابل جستجو تلفیق می‌کند. چیزهایی که باید پیش از شروع بدانید:

  1. برای انتخاب مستندات خود Select documentation را در گوشه سمت چپ کلیک کنید
  2. لازم نیست حتما از ماوس خود استفاده کنید. به لیست کلیدهای میانبر مراجعه شود
  3. جستجوی سایت از fuzzy searching پشتیبانی می‌کند. مثلا جستجوی عبارت "bgcp" مطالب "background-clip" را جستجو می‌کند
  4. برای اینکه در مستندات خاصی جستجو کنید، نام یا مخفف آن را وارد کرده سپس Tab را فشار دهید
  5. برای جستجو از مرورگر خود هم می‌توانید استفاده کنید. پروتکل Open Search پشتیبانی می‌شود
  6. از طریق موبایل هم می‌توانید به این سایت دسترسی داشته باشید. افزونه ای هم برای کروم وجود دارد
  7. برای دریافت خبرنامه‌ها یا عضو شوید یا @DevDocs را در توییتر دنبال کنید
  8. DevDocs رایگان و متن باز است
برخی از مستندات موجود در DevDocs:
  • CSS
  • DOM
  • DOM Events
  • HTML
  • HTTP
  • JavaScript
همین! از برنامه نویسی لذت ببرید :)
معرفی DevDocs
نظرات مطالب
Highlight کردن لینک صفحه جاری در ASP.NET MVC
سلام مهندس (تبریک سال نو با تاخیر)
روشی که گفتین به نظر من یه ایراد کوچک داره و اونم اینه که در صورتی لینک رنگی می‌شه که حتما آدرس مورد نظر با آدرس لینک برابر باشه، در صورتی که لینک موردنظر یک صفحه فرعی باشه و ان لینک در لیست منو وجود نداشته باشه هیچ لینکی رنگی نمی‌شه، مثلا در سایت دات نت تیپس در صورتی که کاربر روی لینک جزئیات یک پروژه کلیک کنه لینک پروژه‌ها رنگی میشه در صورتی که ادرسش توی منوها موجود نیست، من وقتی کدهای سایت مذکور بررسی کردم فهمیدم به جای اون شما از تابع startsWith (تعریف شده توسط شما) استفاده کردین، در این صورت لینکهایی که با قسمتی از آدرس مذکور شروع بشه تغییرات رنگ (استایل مورد نظر) رو اون اعمال میشه.
اگر اشتباه می‌کنم لطفا تصحیح بفرمایید.
 
نظرات مطالب
سازماندهی برنامه‌های Angular توسط ماژول‌ها
چند نکته‌ی تکمیلی در مورد بهبود تعاریف Shared Module و Core Module

الف) چگونه از import ثانویه‌ی Core Module در سایر ماژول‌ها جلوگیری کنیم؟
Core Module فقط باید در AppModule برنامه import شود و نه در هیچ‌جای دیگری. برای جلوگیری اتفاقی از این مساله می‌توان سازنده‌ای را به شکل زیر به آن اضافه کرد:
@NgModule({
  imports: [CommonModule, RouterModule],
  exports: [], // components that are used in app.component.ts will be listed here.
  declarations: [], // components that are used in app.component.ts will be listed here.
  providers: [BrowserStorageService, AppConfigService] // global singleton services of the whole app will be listed here.
})
export class CoreModule {
  constructor( @Optional() @SkipSelf() core: CoreModule) {
    if (core) {
      throw new Error("CoreModule should be imported ONLY in AppModule.");
    }
  }
};
روش کار به این صورت است که خود CoreModule را به سازنده‌ی همان کلاس تزریق می‌کنیم! اگر وهله‌ای از آن قابل دسترسی بود، یعنی Angular پیشتر این ماژول را import کرده‌است. در این حالت با صدور خطایی این مشکل را گوشزد می‌کنیم.
از همین روش برای تشخیص singleton بودن یک سرویس نیز می‌توان استفاده کرد. خودش را به خودش تزریق می‌کنیم! اگر تزریقی صورت گرفت، یک خطا را صادر می‌کنیم.


ب) چگونه از وهله سازی مجدد سرویس‌های تعریف شده‌ی در Shared Module در سایر ماژول‌ها جلوگیری کنیم؟
هدف از قسمت providers در Shared Module تنها ارائه‌ی سرویس‌هایی جهت کامپوننت‌های اشتراکی آن است؛ وگرنه سرویس‌های سراسری برنامه در CoreModule تعریف می‌شوند و این ماژول ویژه نیز تنها یکبار و آن‌هم در AppModule برنامه import خواهد شد. اما در مورد Shared Module اینطور نیست و اگر این ماژول در یک lazy loaded module استفاده شود، سرویس‌های آن طول عمر متفاوتی را پیدا خواهند کرد (هر lazy loaded module یک injector و یک طول عمر خاص خودش را تعریف می‌کند).
در این حالت برای اینکه سرویس‌های Shared Module فقط در AppModule وهله سازی شوند و نه در هیچ‌جای دیگری، روش کار به صورت ذیل است:
- ابتدا آرایه‌ی providers را از تعاریف NgModule آن حذف می‌کنیم.
- سپس متد ویژه‌ای را به نام forRoot، به کلاس آن اضافه خواهیم کرد:
@NgModule({
  imports: [CommonModule],
  declarations: [], // common and shared components/directives/pipes between more than one module and components will be listed here.
  exports: [CommonModule], // common and shared components/directives/pipes between more than one module and components will be listed here.
  /* No providers here! Since they’ll be already provided in AppModule. */
})
export class SharedModule {
  static forRoot(): ModuleWithProviders {
    // Forcing the whole app to use the returned providers from the AppModule only.
    return {
      ngModule: SharedModule,
      providers: [ /* All of your services here. It will hold the services needed by `itself`. */]
    };
  }
};
متد forRoot به صورت استاتیک تعریف می‌شود و همچنین خروجی از نوع ModuleWithProviders دارد. توسط ModuleWithProviders سبب خواهیم شد، AppModule، این ماژول را به همراه آرایه‌ی providers آن import کند؛ اما سایر ماژول‌ها خیر.
سایر ماژول‌ها چون دسترسی به آرایه‌ی حذف شده‌ی providers این ماژول را ندارند، دیگر نمی‌توانند سرویس‌های آن‌را وهله سازی کنند. اما AppModule با فراخوانی ()SharedModule.forRoot در لیست import خود، تنها یکبار سبب وهله سازی سرویس‌های آن می‌گردد.
بنابراین در اینجا AppModule باید ()SharedModule.forRoot را import کند. سایر ماژول‌ها فقط SharedModule را import می‌کنند (بدون ذکر متد forRoot). به این ترتیب سرویس‌های آن تنها یکبار توسط AppModule در طول عمر برنامه به اشتراک گذاشته می‌شوند و در این حالت تفاوتی نمی‌کند که SharedModule در یک lazy loaded module استفاده شده‌است یا خیر.

روش تعریف متد forRoot توسط سیستم مسیریابی Angular نیز استفاده می‌شود و یک الگوی پذیرفته شده در بین توسعه دهندگان Angular است. برای مثال ()RouterModule.forRoot در AppModule تعریف می‌شود و ()RouterModule.forChild برای سایر ماژول‌ها.

نمونه‌ای از AppModule ، ShardModule و CoreModule
نظرات مطالب
Blazor 5x - قسمت 34 - توزیع برنامه‌های Blazor بر روی IIS
یک نکته: استفاده از base href و url‌های برنامه
اگر قرار است base href را مقدار دهی کنید، در کدهای برنامه هیچ مسیری را با / شروع نکنید. شروع با / به معنای پردازش از ریشه‌ی سایت خواهد بود و نه از زیر پوشه‌ی برنامه. برای مثال اگر قرار است برنامه در مسیر http://site/app ارائه شود، اگر url ای را با / شروع کردید، به http://site اشاره می‌کند و نه http://site/app. این مورد حتی برای urlهای api‌ها هم باید رعایت شود و آن‌ها هم نباید با مثلا api/ شروع شوند که به ریشه‌ی سایت اشاره می‌کند. این مورد را باید به عنوان یک best practice، در حین توسعه‌ی برنامه‌های blazor رعایت کرد.
نظرات مطالب
ASP.NET MVC #10
در متن توضیح دادم: « همچنین با توجه به مشخص بودن نوع model که در ابتدای فایل تعریف شده، خاصیت‌هایی را که قرار است اطلاعات ارسالی به آن‌ها بایند شوند نیز به نحو strongly typed تعریف شده‌اند و تحت نظر کامپایلر خواهند بود»
به این معنا که استفاده از Html@‌ها سبب خواهد شد، اگر نام خاصیتی را در کدهای خود تغییر دادید، بتوان پیش از اجرای سایت و در حین کامپایل، دقیقا تشخیص داد که کدام Viewهای یک برنامه‌ی بزرگ دیگر کار نخواهند کرد. همچنین این HTML helperها، مسیرها را بر اساس اطلاعات routing سایت به صحیح‌ترین نحو ممکن تولید می‌کنند به همراه اعمال encoding و بسیاری از مسایل امنیتی توکار دیگر. درباره‌ی این موارد در قسمت‌های بعدی بیشتر بحث شده.
نظرات مطالب
نقدی بر کتاب «مرجع کامل entity framework 4.1»
- نگهداری این‌ها باید در مغز باشد ! :) به علاوه هستند یک سری برنامه مانند این: http://wordsremind.codeplex.com/
- می‌تونید با کمیته‌ی فیلترینگ در این زمینه هماهنگ کنید که چرا تمام آدرس‌های بلاگر را فیلتر کرده. از فید نظرات تا خود وبلاگ‌ها تا همه چیز در همه جا ... چند هزار یا چند صد هزار وبلاگ. مشکل از اینجا است.
- اطلاعی ندارم (کار پخش با انتشارات بود). لطفا با انتشارات ناقوس تماس بگیرید (یا درخواست خرید آنلاین بدید ... در سایت آن‌ها).


درخواست:
لطفا از موضوع بحث خارج نشوید. طبق عادت متداول این سایت کلیه مطالب خارج از عنوان حذف می‌شوند.
نظرات مطالب
معرفی پروژه Orchard
ممکن است چند سایت را که توسط orchard  ساخته شده است اعلام کنید