At Build 2023 back in June, Microsoft announced a new form of storage volume for Windows 11: Dev Drive. In October 2023, support for Dev Drive was shipped as a Windows Update and now available to anyone using the latest version of Windows 11.
در Angular امکان تعریف مسیریابیهایی، درون سایر مسیریابیها نیز پیش بینی شدهاست. با استفاده از مفهوم Child Routes، امکان تعریف سلسله مراتب مسیریابیها جهت ساماندهی و مدیریت مسیریابی درون برنامه، وجود دارد. همچنین lazy loading مسیریابیها را نیز سادهتر کرده و کارآیی آغاز برنامه را بهبود میبخشند.
علت نیاز به Child Routes
در مثال این سری، منوی اصلی آن به صورت ذیل تعریف شدهاست:
سپس از دایرکتیو router-outlet جهت تعریف محل قرارگیری محتوای این مسیریابیها استفاده شدهاست:
هربار که مسیری تغییر میکند، محتوای router-outlet با محتوای قالب آن کامپوننت جایگزین خواهد شد. اما اگر تعداد المانهای صفحهی ویرایش محصولات بیش از اندازه بودند و خواستیم فیلدهای آنرا به دو برگه (tab) تقسیم کنیم چطور؟ برای اینکار نیاز است تا router-outlet ثانویه و مخصوص این قالب را تعریف کنیم. هربار که کاربری بر روی برگهای کلیک میکند، به کمک Child routes، محتوای آن برگه را در این router-outlet ثانویه نمایش میدهیم. به این ترتیب به کمک Child routes میتوان امکان نمایش محتوای مسیریابی دیگری را درون مسیریابی اصلی، میسر کرد.
کاربردهای Child routes
- امکان تقسیم فرمهای طولانی به چند Tab
- امکان طراحی طرحبندیهای Master/Layout
- قرار دادن قالب یک کامپوننت، درون قالب کامپوننتی دیگر
- بهبود کپسوله سازی ماژولهای برنامه
- جزو الزامات Lazy loading هستند
تنظیم کردن Child Routes
مثال جاری این سری، تنها به همراه یک سری primary routes است؛ مانند صفحهی خوشآمد گویی، نمایش لیست محصولات، افزودن و ویرایش محصولات. قالبهای کامپوننتهای اینها نیز در router-outlet اصلی برنامه نمایش داده میشوند. در ادامه میخواهیم کامپوننت ویرایش محصولات را تغییر داده و تعدادی برگه را به آن اضافه کنیم. برای اینکار، نیاز به تعریف Child routes است تا بتوان قالبهای کامپوننتهای هر برگه را در router-outlet کامپوننت والد که در درون router-outlet اصلی برنامه قرار دارد، نمایش داد.
به همین جهت دو کامپوننت جدید ProductEditInfo و ProductEditTags را نیز به ماژول محصولات اضافه میکنیم:
این دستورات سبب به روز رسانی فایل src\app\product\product.module.ts، جهت تکمیل قسمت declarations آن نیز خواهند شد.
به علاوه اینترفیس src\app\product\iproduct.ts را نیز جهت افزودن گروه محصولات و همچنین آرایهی برچسبهای یک محصول تکمیل میکنیم:
در این حالت میتوانید فایل app\product\product-data.ts را نیز ویرایش کرده و به هر محصول، تعدادی گروه و برچسب را نیز انتساب دهید؛ که البته ذکر tags آن اختیاری است. در اینجا فایل src\app\product\product.service.ts نیز باید ویرایش شده و متد initializeProduct آن تعاریف []:category: null, tags را نیز پیدا کنند.
در ادامه برای تنظیم Child Routes، فایل src\app\product\product-routing.module.ts را گشوده و آنرا به نحو ذیل تکمیل کنید:
- Child Routes، در داخل آرایهی خاصیت children تنظیمات یک مسیریابی والد، قابل تعریف هستند. برای نمونه در اینجا Child Routes به تنظیمات مسیریابی ویرایش محصولات اضافه شدهاند و کار توسعهی مسیریابی والد خود را انجام میدهند.
- در اولین Child Route تعریف شده، مقدار path به '' تنظیم شدهاست. به این ترتیب مسیریابی پیش فرض آن (در صورت عدم ذکر صریح آنها در URL) به صورت خودکار به مسیریابی info هدایت خواهد شد. بنابراین درخواست مسیر products/:id/edit به دومین Child Route تنظیم شده هدایت میشود.
- دومین Child Route تعریف شده با مسیری مانند products/:id/edit/info تطابق پیدا میکند.
- سومین Child Route تعریف شده با مسیری مانند products/:id/edit/tags تطابق پیدا میکند.
تعیین محل نمایش Child Views
برای نمایش قالب یک Child Route درون قالب والد آن، نیاز به تعریف یک دایرکتیو router-outlet جدید، درون قالب والد است و نحوهی تعریف آن با primary outlet تعریف شدهی در فایل src\app\app.component.html تفاوتی ندارد.
برای پیاده سازی این مفهوم، نیاز است از قالب ویرایش محصولات و یا فایل src\app\product\product-edit\product-edit.component.html که قالب والد این Child Routes است شروع و آنرا به دو Child View تقسیم کنیم. این قالب، تاکنون حاوی فرمی جهت ویرایش و افزودن محصولات است. در ادامه میخواهیم بجای آن چند برگه را نمایش دهیم. به همین جهت این فرم را حذف کرده و با دو برگهی جدید جایگزین میکنیم. در اینجا نحوهی تعریف لینکهای جدید، به Child Routes و همچنین محل قرارگیری router-outlet ثانویه را نیز مشاهده میکنید:
تا اینجا اگر برنامه را توسط دستور ng s -o اجرا کنید، صفحهی ویرایش محصول اول، چنین شکلی را پیدا کردهاست:
فعالسازی Child Routes
دو روش برای فعالسازی Child Routes وجود دارند:
الف) با ذکر مسیر مطلق
در این حالت تمام URL segments این مسیر باید به عنوان پارامترهای لینک قید شوند.
ب) با ذکر مسیر نسبی
این مسیر از URL segment جاری شروع میشود و نباید در حین تعریف آن از / استفاده کرد. اگر از / استفاده شود، معنای ذکر مسیری مطلق را میدهد.
در این حالت اگر تنظیمات والد این مسیریابی تغییر کنند، نیازی به تغییر مسیر نسبی تعریف شده نیست (برخلاف حالت مطلق که بر اساس قید کامل تمام اجزای مسیریابی والد آن کار میکند).
دقیقا همین پارامترها، قابلیت استفادهی در متد this.route.navigate را نیز دارند:
الف) برای حالت ذکر مسیر مطلق:
ب) و برای حالت ذکر مسیر نسبی:
در حالت ذکر مسیر نسبی، نیاز است پارامتر اضافهی دیگری را جهت مشخص سازی مسیریابی والد نیز قید کرد.
تکمیل Child Viewهای برنامه
تا اینجا لینکهایی نسبی را به مسیریابیهای info و tags اضافه کردیم. در ادامه قالبها و کامپوننتهای آنها را تکمیل میکنیم:
الف) تکمیل کامپوننت ProductEditInfoComponent در فایل src\app\product\product-edit\product-edit.component.ts
با قالب src\app\product\product-edit\product-edit.component.html که در حقیقت همان فرمی است که از کامپوننت والد حذف کردیم و به اینجا منتقل شدهاست:
ب) تکمیل کامپوننت ProductEditTagsComponent در فایل src\app\product\product-edit-tags\product-edit-tags.component.ts
با قالب src\app\product\product-edit-tags\product-edit-tags.component.html
دریافت اطلاعات جهت Child Routes
روشهای متعددی برای دریافت اطلاعات جهت Child Routes وجود دارند:
الف) میتوان از متد this.productService.getProduct جهت دریافت اطلاعات یک محصول استفاده کرد. اما همانطور که در قسمت قبل نیز بررسی کردیم، این روش سبب نمایش ابتدایی یک قالب خالی و پس از مدتی، نمایش اطلاعات آن میشود.
ب) میتوان توسط this.route.snapshot.data['product'] اطلاعات را از Route Resolver، پس از پیش واکشی آنها از وب سرور، دریافت کرد.
ج) اگر قسمتهای مختلف Child Routes قرار است با اطلاعاتی یکسان کار کنند که قرار است بین برگههای مختلف آن به اشتراک گذاشته شوند، این اطلاعات را میتوانند از Route Resolver والد خود به کمک this.route.snapshot.data['product'] دریافت کنند.
در این مثال ما هرچند چندین برگهی مختلف را طراحی کردهایم، اما اطلاعات نمایش داده شدهی توسط آنها متعلق به یک شیء محصول میباشند. بنابراین نیاز است بتوان این اطلاعات را بین کامپوننتهای مختلف این Child Routes به اشتراک گذاشت و تنها با یک وهلهی آن کار کرد. به همین جهت با this.route.parent در هر یک از Child Components تعریف شده کار میکنیم تا بتوان به یک وهلهی شیء محصول، دسترسی یافت.
د) همچنین میتوان از روش this.route.parent.data.subscribe نیز استفاده کرد. البته در اینجا چون صفحهی افزودن محصولات با صفحهی ویرایش محصولات، دارای root URL Segment یکسانی است، نیاز است از این روش استفاده کرد تا بتوان از تغییرات بعدی پارامتر id آن مطلع شد. این مورد روشی است که در کدهای ProductEditInfoComponent مشاهده میکنید.
در اینجا data['product'] به key/value تعریف شدهی resolve: { product: ProductResolverService } در تنظیمات مسیریابی اشاره میکند که آنرا در قسمت قبل تکمیل کردیم.
شبیه به همین روش را در ProductEditTagsComponent نیز بکار گرفتهایم و در آنجا نیز با شیء this.route.parent و دسترسی به اطلاعات دریافتی از Route Resolver، کار میکنیم. به این ترتیب مطمئن خواهیم شد که this.product این دو کامپوننت مختلف، هر دو به یک وهله از شیء product دریافتی از سرور، اشاره میکنند.
به این ترتیب دکمهی Save ذیل هر دو برگه، به درستی عمل کرده و میتواند اطلاعات نهایی یک شیء محصول را ذخیره کند.
رفع مشکلات اعتبارسنجی فرمهای قرار گرفتهی در برگههای مختلف
علت استفادهی از ViewChild در ProductEditInfoComponent
که به فرم قالب آن اشاره میکند:
این است که بتوان متد this.productForm.reset آنرا پس از هربار دریافت اطلاعات از سرور، فراخوانی کرد. این متد نه تنها اطلاعات آنرا پاک میکند، بلکه خطاهای اعتبارسنجی آنرا نیز به حالت نخست برمیگرداند. بنابراین در این حالت اگر سبب بروز یک خطای اعتبارسنجی، در فرم ویرایش اطلاعات شویم و در همان لحظه صفحهی افزودن یک محصول جدید را درخواست کنیم، کاربر همان خطای اعتبارسنجی قبلی را مجددا مشاهده نکرده و یک فرم از ابتدا آغاز شده را مشاهده میکند.
انجام اینکار برای برگههای دوم به بعد ضروری نیست. از این جهت که با اولین بار نمایش این صفحه، تمام آنها از حافظه خارج میشوند و مجددا بازیابی خواهند شد.
مشکل دوم اعتبارسنجی این فرم چند برگهای این است که هرچند خالی کردن نام یا کد محصول، سبب نمایش خطای اعتبارسنجی میشود، اما سبب غیرفعال شدن دکمهی Save نخواهند شد؛ از این جهت که این دکمه در قالب والد قرار دارد و نه در قالب فرزندان.
در اولین بار نمایش Child Routes، کامپوننت ویرایش اطلاعات در router-outlet آن نمایش داده میشود. در این حالت اگر کاربر بر روی لینک نمایش کامپوننت edit tags کلیک کند، قالب کامپوننت edit info به طور کامل از router-outlet حذف میشود و با قالب کامپوننت edit tags جایگزین میشود. این فرآیند به این معنا است که فرم edit info به همراه تمام اطلاعات اعتبارسنجی آن unload میشوند. به همین ترتیب زمانیکه کاربر درخواست نمایش برگهی ویرایش اطلاعات را میکند، قالب edit tags و اطلاعات اعتبارسنجی آن unload میشوند. به این معنا که در یک router-outlet در هر زمان تنها یک فرم، به همراه اطلاعات اعتبارسنجی آن در دسترس هستند.
راه حلهای ممکن:
الف) بدنهی اصلی فرم را در کامپوننت والد قرار دهیم و سپس هر کدام از فرزندان، المانهای فرمهای مرتبط را ارائه دهند. این روش کار نمیکند چون Angular المانهای فرمهای قرار گرفتهی درون router-outlet را شناسایی نمیکند.
ب) قرار دادن فرمها، به صورت مجزا در هر کامپوننت فرزند (مانند روش فعلی) و سپس اعتبارسنجی دستی در کامپوننت والد.
تغییرات مورد نیاز کامپوننت ProductEditComponent را جهت افزودن اعتبارسنجی فرمهای فرزند آنرا در اینجا ملاحظه میکنید:
- در اینجا dataIsValid، به صورت key/value تعریف شدهاست که در آن key، مسیر یک برگه و مقدار آن، معتبر بودن یا غیرمعتبر بودن وضعیت اعتبارسنجی آن است.
- سپس متد validate اضافه شدهاست تا کار اعتبارسنجی را انجام دهد. در اینجا از خود شیء this.product که بین دو برگه به اشتراک گذاشته شدهاست برای انجام اعتبارسنجی استفاده میکنیم. از این جهت که برگهها نیز با استفاده از this.route.parent.data، دقیقا به همین وهله دسترسی دارند. بنابراین هرتغییری که در برگهها بر روی این وهله اعمال شود، به کامپوننت والد نیز منعکس میشود.
- متد isValid، مسیر هر برگه را دریافت میکند و سپس به متغیر dataIsValid مراجعه کرده و وضعیت آن برگه را باز میگرداند. اگر path در اینجا قید نشود، وضعیت تمام برگهها بررسی میشوند؛ مانند if (this.isValid(null)) در متد ذخیره سازی اطلاعات.
- در آخر در فایل product-edit.component.html، وضعیت فعال و غیرفعال دکمهی ثبت را نیز به این متد متصل میکنیم:
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-routing-lab-04.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس از طریق خط فرمان به ریشهی پروژه وارد شده و دستور npm install را صادر کنید تا وابستگیهای آن دریافت و نصب شوند. در آخر با اجرای دستور ng s -o برنامه ساخته شده و در مرورگر پیش فرض سیستم نمایش داده خواهد شد.
علت نیاز به Child Routes
در مثال این سری، منوی اصلی آن به صورت ذیل تعریف شدهاست:
<ul class="nav navbar-nav"> <li><a [routerLink]="['/home']">Home</a></li> <li><a [routerLink]="['/products']">Product List</a></li> <li><a [routerLink]="['/products', 0, 'edit']">Add Product</a></li> </ul>
<div class="container"> <router-outlet></router-outlet> </div>
کاربردهای Child routes
- امکان تقسیم فرمهای طولانی به چند Tab
- امکان طراحی طرحبندیهای Master/Layout
- قرار دادن قالب یک کامپوننت، درون قالب کامپوننتی دیگر
- بهبود کپسوله سازی ماژولهای برنامه
- جزو الزامات Lazy loading هستند
تنظیم کردن Child Routes
مثال جاری این سری، تنها به همراه یک سری primary routes است؛ مانند صفحهی خوشآمد گویی، نمایش لیست محصولات، افزودن و ویرایش محصولات. قالبهای کامپوننتهای اینها نیز در router-outlet اصلی برنامه نمایش داده میشوند. در ادامه میخواهیم کامپوننت ویرایش محصولات را تغییر داده و تعدادی برگه را به آن اضافه کنیم. برای اینکار، نیاز به تعریف Child routes است تا بتوان قالبهای کامپوننتهای هر برگه را در router-outlet کامپوننت والد که در درون router-outlet اصلی برنامه قرار دارد، نمایش داد.
به همین جهت دو کامپوننت جدید ProductEditInfo و ProductEditTags را نیز به ماژول محصولات اضافه میکنیم:
>ng g c product/ProductEditInfo >ng g c product/ProductEditTags
به علاوه اینترفیس src\app\product\iproduct.ts را نیز جهت افزودن گروه محصولات و همچنین آرایهی برچسبهای یک محصول تکمیل میکنیم:
export interface IProduct { id: number; productName: string; productCode: string; category: string; tags?: string[]; }
در ادامه برای تنظیم Child Routes، فایل src\app\product\product-routing.module.ts را گشوده و آنرا به نحو ذیل تکمیل کنید:
import { ProductEditTagsComponent } from './product-edit-tags/product-edit-tags.component'; import { ProductEditInfoComponent } from './product-edit-info/product-edit-info.component'; const routes: Routes = [ { path: 'products', component: ProductListComponent }, { path: 'products/:id', component: ProductDetailComponent, resolve: { product: ProductResolverService } }, { path: 'products/:id/edit', component: ProductEditComponent, resolve: { product: ProductResolverService }, children: [ { path: '', redirectTo: 'info', pathMatch: 'full' }, { path: 'info', component: ProductEditInfoComponent }, { path: 'tags', component: ProductEditTagsComponent } ] } ];
- در اولین Child Route تعریف شده، مقدار path به '' تنظیم شدهاست. به این ترتیب مسیریابی پیش فرض آن (در صورت عدم ذکر صریح آنها در URL) به صورت خودکار به مسیریابی info هدایت خواهد شد. بنابراین درخواست مسیر products/:id/edit به دومین Child Route تنظیم شده هدایت میشود.
- دومین Child Route تعریف شده با مسیری مانند products/:id/edit/info تطابق پیدا میکند.
- سومین Child Route تعریف شده با مسیری مانند products/:id/edit/tags تطابق پیدا میکند.
تعیین محل نمایش Child Views
برای نمایش قالب یک Child Route درون قالب والد آن، نیاز به تعریف یک دایرکتیو router-outlet جدید، درون قالب والد است و نحوهی تعریف آن با primary outlet تعریف شدهی در فایل src\app\app.component.html تفاوتی ندارد.
برای پیاده سازی این مفهوم، نیاز است از قالب ویرایش محصولات و یا فایل src\app\product\product-edit\product-edit.component.html که قالب والد این Child Routes است شروع و آنرا به دو Child View تقسیم کنیم. این قالب، تاکنون حاوی فرمی جهت ویرایش و افزودن محصولات است. در ادامه میخواهیم بجای آن چند برگه را نمایش دهیم. به همین جهت این فرم را حذف کرده و با دو برگهی جدید جایگزین میکنیم. در اینجا نحوهی تعریف لینکهای جدید، به Child Routes و همچنین محل قرارگیری router-outlet ثانویه را نیز مشاهده میکنید:
<div class="panel panel-primary"> <div class="panel-heading"> {{pageTitle}} </div> <div class="panel-body" *ngIf="product"> <div class="wizard"> <a [routerLink]="['info']"> Basic Information </a> <a [routerLink]="['tags']"> Search Tags </a> </div> <router-outlet></router-outlet> </div> <div class="panel-footer"> <div class="row"> <div class="col-md-6 col-md-offset-2"> <span> <button class="btn btn-primary" type="button" style="width:80px;margin-right:10px" [disabled]="!isValid()" (click)="saveProduct()"> Save </button> </span> <span> <a class="btn btn-default" [routerLink]="['/products']"> Cancel </a> </span> <span> <a class="btn btn-default" (click)="deleteProduct()"> Delete </a> </span> </div> </div> </div> <div class="has-error" *ngIf="errorMessage">{{errorMessage}}</div> </div>
فعالسازی Child Routes
دو روش برای فعالسازی Child Routes وجود دارند:
الف) با ذکر مسیر مطلق
<a [routerLink]="['/products',product.id,'edit','info']">Info</a>
ب) با ذکر مسیر نسبی
<a [routerLink]="['info']">Info</a>
در این حالت اگر تنظیمات والد این مسیریابی تغییر کنند، نیازی به تغییر مسیر نسبی تعریف شده نیست (برخلاف حالت مطلق که بر اساس قید کامل تمام اجزای مسیریابی والد آن کار میکند).
دقیقا همین پارامترها، قابلیت استفادهی در متد this.route.navigate را نیز دارند:
الف) برای حالت ذکر مسیر مطلق:
this.router.navigate(['/products', this.product.id,'edit','info']);
this.router.navigate(['info', { relativeTo: this.route }]);
تکمیل Child Viewهای برنامه
تا اینجا لینکهایی نسبی را به مسیریابیهای info و tags اضافه کردیم. در ادامه قالبها و کامپوننتهای آنها را تکمیل میکنیم:
الف) تکمیل کامپوننت ProductEditInfoComponent در فایل src\app\product\product-edit\product-edit.component.ts
import { ActivatedRoute } from '@angular/router'; import { NgForm } from '@angular/forms'; import { Component, OnInit, ViewChild } from '@angular/core'; import { IProduct } from './../iproduct'; @Component({ //selector: 'app-product-edit-info', templateUrl: './product-edit-info.component.html', styleUrls: ['./product-edit-info.component.css'] }) export class ProductEditInfoComponent implements OnInit { @ViewChild(NgForm) productForm: NgForm; errorMessage: string; product: IProduct; constructor(private route: ActivatedRoute) { } ngOnInit(): void { this.route.parent.data.subscribe(data => { this.product = data['product']; if (this.productForm) { this.productForm.reset(); } }); } }
<div class="panel-body"> <form class="form-horizontal" novalidate #productForm="ngForm"> <fieldset> <legend>Basic Product Information</legend> <div class="form-group" [ngClass]="{'has-error': (productNameVar.touched || productNameVar.dirty || product.id !== 0) && !productNameVar.valid }"> <label class="col-md-2 control-label" for="productNameId">Product Name</label> <div class="col-md-8"> <input class="form-control" id="productNameId" type="text" placeholder="Name (required)" required minlength="3" [(ngModel)] = product.productName name="productName" #productNameVar="ngModel" /> <span class="help-block" *ngIf="(productNameVar.touched || productNameVar.dirty || product.id !== 0) && productNameVar.errors"> <span *ngIf="productNameVar.errors.required"> Product name is required. </span> <span *ngIf="productNameVar.errors.minlength"> Product name must be at least three characters. </span> </span> </div> </div> <div class="form-group" [ngClass]="{'has-error': (productCodeVar.touched || productCodeVar.dirty || product.id !== 0) && !productCodeVar.valid }"> <label class="col-md-2 control-label" for="productCodeId">Product Code</label> <div class="col-md-8"> <input class="form-control" id="productCodeId" type="text" placeholder="Code (required)" required [(ngModel)] = product.productCode name="productCode" #productCodeVar="ngModel" /> <span class="help-block" *ngIf="(productCodeVar.touched || productCodeVar.dirty || product.id !== 0) && productCodeVar.errors"> <span *ngIf="productCodeVar.errors.required"> Product code is required. </span> </span> </div> </div> <div class="has-error" *ngIf="errorMessage">{{errorMessage}}</div> </fieldset> </form> </div>
ب) تکمیل کامپوننت ProductEditTagsComponent در فایل src\app\product\product-edit-tags\product-edit-tags.component.ts
import { ActivatedRoute } from '@angular/router'; import { IProduct } from './../iproduct'; import { Component, OnInit } from '@angular/core'; @Component({ //selector: 'app-product-edit-tags', templateUrl: './product-edit-tags.component.html', styleUrls: ['./product-edit-tags.component.css'] }) export class ProductEditTagsComponent implements OnInit { errorMessage: string; newTags = ''; product: IProduct; constructor(private route: ActivatedRoute) { } ngOnInit(): void { this.route.parent.data.subscribe(data => { this.product = data['product']; }); } // Add the defined tags addTags(): void { let tagArray = this.newTags.split(','); this.product.tags = this.product.tags ? this.product.tags.concat(tagArray) : tagArray; this.newTags = ''; } // Remove the tag from the array of tags. removeTag(idx: number): void { this.product.tags.splice(idx, 1); } }
<div class="panel-body"> <form class="form-horizontal" novalidate> <fieldset> <legend>Product Search Tags</legend> <div class="form-group" [ngClass]="{'has-error': (categoryVar.touched || categoryVar.dirty || product.id !== 0) && !categoryVar.valid }"> <label class="col-md-2 control-label" for="categoryId">Category</label> <div class="col-md-8"> <input class="form-control" id="categoryId" type="text" placeholder="Category (required)" required minlength="3" [(ngModel)]="product.category" name="category" #categoryVar="ngModel" /> <span class="help-block" *ngIf="(categoryVar.touched || categoryVar.dirty || product.id !== 0) && categoryVar.errors"> <span *ngIf="categoryVar.errors.required"> A category must be entered. </span> <span *ngIf="categoryVar.errors.minlength"> The category must be at least 3 characters in length. </span> </span> </div> </div> <div class="form-group" [ngClass]="{'has-error': (tagVar.touched || tagVar.dirty || product.id !== 0) && !tagVar.valid }"> <label class="col-md-2 control-label" for="tagsId">Search Tags</label> <div class="col-md-8"> <input class="form-control" id="tagsId" type="text" placeholder="Search keywords separated by commas" minlength="3" [(ngModel)]="newTags" name="tags" #tagVar="ngModel" /> <span class="help-block" *ngIf="(tagVar.touched || tagVar.dirty || product.id !== 0) && tagVar.errors"> <span *ngIf="tagVar.errors.minlength"> The search tag must be at least 3 characters in length. </span> </span> </div> <div class="col-md-1"> <button type="button" class="btn btn-default" (click)="addTags()"> Add </button> </div> </div> <div class="row col-md-8 col-md-offset-2"> <span *ngFor="let tag of product.tags; let i = index"> <button class="btn btn-default" style="font-size:smaller;margin-bottom:12px" (click)="removeTag(i)"> {{tag}} <span class="glyphicon glyphicon-remove"></span> </button> </span> </div> <div class="has-error" *ngIf="errorMessage">{{errorMessage}}</div> </fieldset> </form> </div>
دریافت اطلاعات جهت Child Routes
روشهای متعددی برای دریافت اطلاعات جهت Child Routes وجود دارند:
الف) میتوان از متد this.productService.getProduct جهت دریافت اطلاعات یک محصول استفاده کرد. اما همانطور که در قسمت قبل نیز بررسی کردیم، این روش سبب نمایش ابتدایی یک قالب خالی و پس از مدتی، نمایش اطلاعات آن میشود.
ب) میتوان توسط this.route.snapshot.data['product'] اطلاعات را از Route Resolver، پس از پیش واکشی آنها از وب سرور، دریافت کرد.
ج) اگر قسمتهای مختلف Child Routes قرار است با اطلاعاتی یکسان کار کنند که قرار است بین برگههای مختلف آن به اشتراک گذاشته شوند، این اطلاعات را میتوانند از Route Resolver والد خود به کمک this.route.snapshot.data['product'] دریافت کنند.
در این مثال ما هرچند چندین برگهی مختلف را طراحی کردهایم، اما اطلاعات نمایش داده شدهی توسط آنها متعلق به یک شیء محصول میباشند. بنابراین نیاز است بتوان این اطلاعات را بین کامپوننتهای مختلف این Child Routes به اشتراک گذاشت و تنها با یک وهلهی آن کار کرد. به همین جهت با this.route.parent در هر یک از Child Components تعریف شده کار میکنیم تا بتوان به یک وهلهی شیء محصول، دسترسی یافت.
د) همچنین میتوان از روش this.route.parent.data.subscribe نیز استفاده کرد. البته در اینجا چون صفحهی افزودن محصولات با صفحهی ویرایش محصولات، دارای root URL Segment یکسانی است، نیاز است از این روش استفاده کرد تا بتوان از تغییرات بعدی پارامتر id آن مطلع شد. این مورد روشی است که در کدهای ProductEditInfoComponent مشاهده میکنید.
ngOnInit(): void { this.route.parent.data.subscribe(data => { this.product = data['product']; if (this.productForm) { this.productForm.reset(); } }); }
شبیه به همین روش را در ProductEditTagsComponent نیز بکار گرفتهایم و در آنجا نیز با شیء this.route.parent و دسترسی به اطلاعات دریافتی از Route Resolver، کار میکنیم. به این ترتیب مطمئن خواهیم شد که this.product این دو کامپوننت مختلف، هر دو به یک وهله از شیء product دریافتی از سرور، اشاره میکنند.
به این ترتیب دکمهی Save ذیل هر دو برگه، به درستی عمل کرده و میتواند اطلاعات نهایی یک شیء محصول را ذخیره کند.
رفع مشکلات اعتبارسنجی فرمهای قرار گرفتهی در برگههای مختلف
علت استفادهی از ViewChild در ProductEditInfoComponent
@ViewChild(NgForm) productForm: NgForm;
<form class="form-horizontal" novalidate #productForm="ngForm">
انجام اینکار برای برگههای دوم به بعد ضروری نیست. از این جهت که با اولین بار نمایش این صفحه، تمام آنها از حافظه خارج میشوند و مجددا بازیابی خواهند شد.
مشکل دوم اعتبارسنجی این فرم چند برگهای این است که هرچند خالی کردن نام یا کد محصول، سبب نمایش خطای اعتبارسنجی میشود، اما سبب غیرفعال شدن دکمهی Save نخواهند شد؛ از این جهت که این دکمه در قالب والد قرار دارد و نه در قالب فرزندان.
در اولین بار نمایش Child Routes، کامپوننت ویرایش اطلاعات در router-outlet آن نمایش داده میشود. در این حالت اگر کاربر بر روی لینک نمایش کامپوننت edit tags کلیک کند، قالب کامپوننت edit info به طور کامل از router-outlet حذف میشود و با قالب کامپوننت edit tags جایگزین میشود. این فرآیند به این معنا است که فرم edit info به همراه تمام اطلاعات اعتبارسنجی آن unload میشوند. به همین ترتیب زمانیکه کاربر درخواست نمایش برگهی ویرایش اطلاعات را میکند، قالب edit tags و اطلاعات اعتبارسنجی آن unload میشوند. به این معنا که در یک router-outlet در هر زمان تنها یک فرم، به همراه اطلاعات اعتبارسنجی آن در دسترس هستند.
راه حلهای ممکن:
الف) بدنهی اصلی فرم را در کامپوننت والد قرار دهیم و سپس هر کدام از فرزندان، المانهای فرمهای مرتبط را ارائه دهند. این روش کار نمیکند چون Angular المانهای فرمهای قرار گرفتهی درون router-outlet را شناسایی نمیکند.
ب) قرار دادن فرمها، به صورت مجزا در هر کامپوننت فرزند (مانند روش فعلی) و سپس اعتبارسنجی دستی در کامپوننت والد.
تغییرات مورد نیاز کامپوننت ProductEditComponent را جهت افزودن اعتبارسنجی فرمهای فرزند آنرا در اینجا ملاحظه میکنید:
export class ProductEditComponent implements OnInit { private dataIsValid: { [key: string]: boolean } = {}; isValid(path: string): boolean { this.validate(); if (path) { return this.dataIsValid[path]; } return (this.dataIsValid && Object.keys(this.dataIsValid).every(d => this.dataIsValid[d] === true)); } saveProduct(): void { if (this.isValid(null)) { this.productService.saveProduct(this.product) .subscribe( () => this.onSaveComplete(`${this.product.productName} was saved`), (error: any) => this.errorMessage = <any>error ); } else { this.errorMessage = 'Please correct the validation errors.'; } } validate(): void { // Clear the validation object this.dataIsValid = {}; // 'info' tab if (this.product.productName && this.product.productName.length >= 3 && this.product.productCode) { this.dataIsValid['info'] = true; } else { this.dataIsValid['info'] = false; } // 'tags' tab if (this.product.category && this.product.category.length >= 3) { this.dataIsValid['tags'] = true; } else { this.dataIsValid['tags'] = false; } } }
- سپس متد validate اضافه شدهاست تا کار اعتبارسنجی را انجام دهد. در اینجا از خود شیء this.product که بین دو برگه به اشتراک گذاشته شدهاست برای انجام اعتبارسنجی استفاده میکنیم. از این جهت که برگهها نیز با استفاده از this.route.parent.data، دقیقا به همین وهله دسترسی دارند. بنابراین هرتغییری که در برگهها بر روی این وهله اعمال شود، به کامپوننت والد نیز منعکس میشود.
- متد isValid، مسیر هر برگه را دریافت میکند و سپس به متغیر dataIsValid مراجعه کرده و وضعیت آن برگه را باز میگرداند. اگر path در اینجا قید نشود، وضعیت تمام برگهها بررسی میشوند؛ مانند if (this.isValid(null)) در متد ذخیره سازی اطلاعات.
- در آخر در فایل product-edit.component.html، وضعیت فعال و غیرفعال دکمهی ثبت را نیز به این متد متصل میکنیم:
<button class="btn btn-primary" type="button" style="width:80px;margin-right:10px" [disabled]="!isValid()" (click)="saveProduct()"> Save </button>
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-routing-lab-04.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس از طریق خط فرمان به ریشهی پروژه وارد شده و دستور npm install را صادر کنید تا وابستگیهای آن دریافت و نصب شوند. در آخر با اجرای دستور ng s -o برنامه ساخته شده و در مرورگر پیش فرض سیستم نمایش داده خواهد شد.
In this post I provide an update on the NetEscapades.AspNetCore.SecurityHeaders project. I've just released a preview version of 1.0.0, which addresses some longstanding requests for extra functionality, updates the supported target frameworks, and more. In this post I provide a quick overview of the library, and then discuss the major changes made in this first preview.
مطالب
LocalDB FAQ
SQL Server Express LocalDB یا به صورت خلاصه LocalDB، یک بانک اطلاعاتیاست که به صورت متصل به پروسهی برنامهی جاری اجرا میشود؛ برخلاف رویهی متداول بانکهای اطلاعاتی که به صورت یک سرویس مستقل اجرا میشوند. هدف آن، جایگزین کردن نگارش Express نیست و بیشتر حجم کم و سهولت توزیع آن مدنظر بودهاست. برای مثال نگارش Express به صورت یک سرویس مجزا و مستقل بر روی سیستم نصب میشود؛ اما LocalDB به همراه و متصل به برنامهی نوشته شده، اجرا میشود:
اگر به تصویر فوق دقت کنید، یک child process جدید به نام sqlservr.exe نیز به همراه برنامهی آزمایشی ما به صورت خودکار اجرا شدهاست. این child process به همراه پارامترهای ذیل است (که توسط NET Framework. مقدار دهی میشوند و مدیریت نهایی آن خودکار است):
بنابراین LocalDB برخلاف SQL Server CE، یک بانک اطلاعاتی in-process نیست و به صورت یک پروسهی مجزا اجرا میشود. زمانیکه از SQL Server CE استفاده میشود، موتور این بانک اطلاعاتی چند فایل DLL بیشتر نیستند و نهایتا اجرای آن داخل پروسهی برنامهی ما و همانند اجرای سایر DLLهای متصل و مورد استفادهی به آن است.
اما LocalDB یک بانک اطلاعاتی user-mode است و در پروفایل کاربر جاری سیستم اجرا میشود. این بانک اطلاعاتی یک بار بر روی سیستم نصب میشود و در هر برنامهای که از آن استفاده میکنید، یک child process مجزای خاص خودش را (sqlservr.exe) اجرا خواهد کرد. اجرا و خاتمهی این child processها نیز خودکار هستند و نیازی به دخالت مستقیم برنامه ندارند.
البته به نظر توسعهی SQL Server CE متوقف شدهاست و دیگر پشتیبانی نمیشود. بنابراین گزینهی ترجیح داده شدهی برای کارهایی با حجمهای بانک اطلاعاتی زیر 10 گیگابایت ، میتواند LocalDB باشد. به علاوه اینکه قابلیتهای T-SQL بیشتری را نیز پشتیبانی میکند و همچنین پشتیبانی منظمی نیز از آن وجود دارد. برای مثال پیش نمایش نگارش 2016 آن نیز موجود است.
در ادامه، یک سری پرسش و پاسخ متداول جهت کار با LocalDB را مرور خواهیم کرد.
محل دریافت آخرین نگارش مستقل آن کجاست؟
همانطور که عنوان شد، یکی از مهمترین اهداف LocalDB، سهولت توزیع آن است و عدم نیاز به یک Admin سیستم، برای نصب و نگهداری آن. نگارش 2014 SP1 آنرا از آدرس ذیل میتوانید دریافت کنید:
https://www.microsoft.com/en-us/download/details.aspx?id=46697
در اینجا نسخههای متعددی وجود دارند. برای مثال اگر سیستم شما 64 بیتی است، تنها نیاز است ENU\x64\SqlLocalDB.msi را دریافت و نصب کنید:
پارامترهای نصب خاموش آن برای توزیع سادهی برنامه کدامند؟
اگر میخواهید نصاب LocalDB را به همراه setup برنامهی خود توزیع کنید، میتوانید روش توزیع خاموش را با ذکر پارامترهای ذیل، مورد استفاده قرار دهید:
رشتهی اتصالی مخصوص آن کدام است؟
اگر نگارش 2014 SP1 آنرا نصب کرده باشید، رشتهی اتصالی فوق، تمام آنچیزی است که برای شروع به کار با آن، نیاز دارید و دارای دو قسمت مهم است:
الف) ذکر وهلهی مدنظر
در اینجا وهلهی MSSQLLocalDB ذکر شدهاست؛ اما چه وهلههایی بر روی سیستم نصب هستند و چطور میتوان وهلهی دیگری را ایجاد کرد؟ برای این منظور، به پارامترهای sqlservr.exe ابتدای بحث دقت کنید. اکثر آنها به پوشهی ذیل اشاره میکنند:
با یک چنین محتوایی
به علاوه، این لیست را توسط برنامهی کمکی SqlLocalDB.exe، به همراه پارامتر info یا i نیز میتوانید دریافت و بررسی کنید:
برنامهی کمکی SqlLocalDB.exe به همراه نصاب LocalDB، نصب میشود و توسط آن میتوان نگارشهای مختلف نصب شدهرا با پارامتر v و وهلهی مختلف موجود را با پارامتر i مشاهده کرد.
همچنین اگر میخواهید وهلهی جدیدی را بجز وهلهی پیش فرض MSSQLLocalDB ایجاد کنید، میتوانید از پارامتر create آن به نحو ذیل استفاده نمائید:
ب) ذکر DataDirectory
در رشتهی اتصالی فوق، پارامتر DataDirectory نیز ذکر شدهاست تا بتوان مسیر بانک اطلاعاتی را به صورت نسبی و بدون ذکر عبارت دقیق آن که ممکن است در سیستمهای دیگر متفاوت باشد، پردازش کرد. این پارامتر در برنامههای وب به پوشهی استاندارد app_data اشاره میکند و نیازی به تنظیم اضافهتری ندارد. اما در برنامههای دسکتاپ باید به نحو ذیل به صورت دستی، در آغاز برنامه مقدار دهی شود:
به این ترتیب DataDirectory به محل قرارگیری فایل exe برنامه اشاره میکند. بدیهی است در اینجا هر پوشهی دیگری را نیز میتوانید ذکر کنید:
برای نمونه تنظیم فوق به زیر پوشهی db، در کنار فایل exe برنامه اشاره میکند.
محل نصب بانکهای اطلاعاتی پیش فرض آن کدام است؟
ذکر AttachDbFilename در رشتهی اتصالی فوق، اختیاری است. در صورت عدم ذکر آن، بانک اطلاعاتی ایجاد شده را در یکی از مسیرهای ذیل میتوانید جستجو کنید:
همچنین در این محلها فایلهای log متنی خطاهای این بانک اطلاعاتی را نیز میتوان مشاهده کرد. بنابراین اگر به خطای خاصی برخوردید، بهترین کار، بررسی این فایلها است.
آیا میتوان فایلهای mdf و ldf آنرا به نگارش کامل SQL Server متصل (attach) کرد؟
بله. اما باید دقت داشته باشید که SQL Server به محض اتصال یک بانک اطلاعاتی با نگارش پایینتر به آن، ابتدا شماره نگارش آنرا به روز میکند. یعنی دیگر نخواهید توانست این بانک اطلاعاتی را با نگارش پایینتر LocalDB باز کنید و یک چنین پیام خطایی را دریافت خواهید کرد:
چگونه محتوای بانکهای اطلاعاتی LocalDB را با VS.NET مشاهده کنیم؟
از منوی view گزینهی server explorer را انتخاب کنید. بر روی data connections کلیک راست کرده و گزینهی Add connection را انتخاب کنید.
در صفحهی باز شده، گزینهی Microsoft SQL server را انتخاب کنید. در صفحهی بعد، ذکر server name مطابق data source رشتهی اتصالی بحث شده و سپس انتخاب گزینهی attach a database file کفایت میکند:
پس از کلیک بر روی ok، امکان کار با اجزای این بانک اطلاعاتی را خواهید داشت:
چگونه از LocalDB با EF استفاده کنیم؟
EF 6.x به صورت پیش فرض از بانک اطلاعاتی LocalDB استفاده میکند و تنها داشتن یک چنین تنظیمی در فایل کانفیگ برنامه، برای کار با آن کافی است:
یک قسمت آن ذکر رشتهی اتصالی است که در مورد آن بحث شد و قسمت دوم آن، ذکر connection factory مخصوص localdb است که به صورت فوق میباشد. تنظیم دیگری برای کار با LocalDB و EF 6.x نیازی نیست.
البته باید دقت داشت که اسمبلی EntityFramework.SqlServer نیز به صورت خودکار به همراه بستهی نیوگت EF 6.x به برنامه اضافه میشود که استفادهی از connection factory ذکر شده را میسر میکند.
استفادهی از LocalDB به همراه برنامههای وب چگونه است؟
سه نکته را باید در حین استفادهی از LocalDB، در برنامههای وب اجرا شدهی بر روی IIS مدنظر داشت:
الف) LocalDB یک بانک اطلاعاتی user-mode است و child process آن تحت مجوز اکانت تنظیم شدهی برای آن کار میکند.
ب) همانطور که عنوان شد، در رشتهی اتصالی ذکر شده، پارامتر DataDirectory به پوشهی استاندارد app_data اشاره میکند که فایلهای قرار گرفتهی در آن توسط IIS محافظت میشوند و از طریق وب قابل دسترسی و دانلود نیستند.
ج) child process مربوط به LocalDB، نیاز به دسترسی write، برای کار با فایلهای mdf و ldf خود دارد.
برای مورد الف نیاز است تا به تنظیمات application pool برنامه مراجعه کرده و سپس بر روی آن کلیک راست کرد و گزینهی advanced settings را انتخاب نمود. در اینجا گزینهی load user profile باید true باشد:
تنظیم load user profile ضروری است اما کافی نیست. پس از آن باید setProfileEnvironment را نیز به true تنظیم کرد. تنظیم این مورد در کنسول مدیریتی IIS به صورت زیر است.
ابتدا ریشهی اصلی سرور را انتخاب کنید و سپس به configuration editor آن وارد شوید:
در ادامه از دارپ داون آن، گزینهی system.applicationHost و زیر شاخهی applicationPools آنرا انتخاب کنید:
در اینجا application pool defaults و سپس در آن processModel را نیز باز کنید:
اکنون امکان ویرایش setProfileEnvironment را به true خواهید داشت:
پس از این تنظیم، ابتدا بر روی دکمهی apply سمت راست صفحه کلیک کرده و سپس نیاز است یکبار IIS را نیز ریست کنید تا تنظیمات اعمال شوند.
در ادامه برای تنظیم دسترسی write (موارد ب و ج)، ابتدا بر روی پوشهی app_data برنامه، کلیک راست کرده و برگهی security آنرا باز کنید. سپس بر روی دکمهی edit کلیک کرده و در صفحهی باز شده بر روی دکمهی add کلیک کنید تا بتوان به کاربر application pool برنامه دسترسی write داد:
در اینجا iis apppool\TestLocalDB را وارد کرده و بر روی دکمهی check name کلیک کنید.
iis apppool آن که مشخص است. عبارت TestLocalDB نام application pool ایی است که برای برنامهی وب خود ایجاد کردهایم (بهتر است به ازای هر برنامهی وب، یک application pool مجزا تعریف شود).
در اینجا بر روی OK کلیک کرده و به این کاربر جدید اضافه شده، دسترسی full control را بدهید تا برنامه و یوزر آن بتواند فایلهای mdf و ldf را ایجاد کرده و به روز رسانی کنند.
پس از تنظیم load user profile و همچنین set profile environment و دادن دسترسی write به کاربر application pool برنامه، اکنون child process مربوط به local db را میتوان ذیل پروسهی IIS مشاهده کرد و برنامه قادر به استفادهی از LocalDB خواهد بود:
اگر به تصویر فوق دقت کنید، یک child process جدید به نام sqlservr.exe نیز به همراه برنامهی آزمایشی ما به صورت خودکار اجرا شدهاست. این child process به همراه پارامترهای ذیل است (که توسط NET Framework. مقدار دهی میشوند و مدیریت نهایی آن خودکار است):
"C:\Program Files\Microsoft SQL Server\120\LocalDB\Binn\\sqlservr.exe" -c -SMSSQL12E.LOCALDB -sLOCALDB#5657074F -d"C:\Users\Vahid\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\master.mdf" -l"C:\Users\Vahid\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\mastlog.ldf" -e"C:\Users\Vahid\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\error.log"
اما LocalDB یک بانک اطلاعاتی user-mode است و در پروفایل کاربر جاری سیستم اجرا میشود. این بانک اطلاعاتی یک بار بر روی سیستم نصب میشود و در هر برنامهای که از آن استفاده میکنید، یک child process مجزای خاص خودش را (sqlservr.exe) اجرا خواهد کرد. اجرا و خاتمهی این child processها نیز خودکار هستند و نیازی به دخالت مستقیم برنامه ندارند.
البته به نظر توسعهی SQL Server CE متوقف شدهاست و دیگر پشتیبانی نمیشود. بنابراین گزینهی ترجیح داده شدهی برای کارهایی با حجمهای بانک اطلاعاتی زیر 10 گیگابایت ، میتواند LocalDB باشد. به علاوه اینکه قابلیتهای T-SQL بیشتری را نیز پشتیبانی میکند و همچنین پشتیبانی منظمی نیز از آن وجود دارد. برای مثال پیش نمایش نگارش 2016 آن نیز موجود است.
در ادامه، یک سری پرسش و پاسخ متداول جهت کار با LocalDB را مرور خواهیم کرد.
محل دریافت آخرین نگارش مستقل آن کجاست؟
همانطور که عنوان شد، یکی از مهمترین اهداف LocalDB، سهولت توزیع آن است و عدم نیاز به یک Admin سیستم، برای نصب و نگهداری آن. نگارش 2014 SP1 آنرا از آدرس ذیل میتوانید دریافت کنید:
https://www.microsoft.com/en-us/download/details.aspx?id=46697
در اینجا نسخههای متعددی وجود دارند. برای مثال اگر سیستم شما 64 بیتی است، تنها نیاز است ENU\x64\SqlLocalDB.msi را دریافت و نصب کنید:
پارامترهای نصب خاموش آن برای توزیع سادهی برنامه کدامند؟
اگر میخواهید نصاب LocalDB را به همراه setup برنامهی خود توزیع کنید، میتوانید روش توزیع خاموش را با ذکر پارامترهای ذیل، مورد استفاده قرار دهید:
msiexec /i SqlLocalDB.msi /qn IACCEPTSQLLOCALDBLICENSETERMS=YES
رشتهی اتصالی مخصوص آن کدام است؟
<connectionStrings> <add name="Sample35Context" connectionString="Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\test.mdf;Integrated Security=True;" providerName="System.Data.SqlClient" /> </connectionStrings>
الف) ذکر وهلهی مدنظر
در اینجا وهلهی MSSQLLocalDB ذکر شدهاست؛ اما چه وهلههایی بر روی سیستم نصب هستند و چطور میتوان وهلهی دیگری را ایجاد کرد؟ برای این منظور، به پارامترهای sqlservr.exe ابتدای بحث دقت کنید. اکثر آنها به پوشهی ذیل اشاره میکنند:
C:\Users\your_user_name_here\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances
در این پوشه، وهلههای موجود و نصب شدهی بر روی سیستم شما نمایش داده میشوند که یکی از آنها را میتوانید در رشتهی اتصالی فوق ذکر کنید.
به علاوه، این لیست را توسط برنامهی کمکی SqlLocalDB.exe، به همراه پارامتر info یا i نیز میتوانید دریافت و بررسی کنید:
برنامهی کمکی SqlLocalDB.exe به همراه نصاب LocalDB، نصب میشود و توسط آن میتوان نگارشهای مختلف نصب شدهرا با پارامتر v و وهلهی مختلف موجود را با پارامتر i مشاهده کرد.
همچنین اگر میخواهید وهلهی جدیدی را بجز وهلهی پیش فرض MSSQLLocalDB ایجاد کنید، میتوانید از پارامتر create آن به نحو ذیل استفاده نمائید:
For LocalDB SQL EXPRESS 2014 "C:\Program Files\Microsoft SQL Server\120\Tools\Binn\SqlLocalDB.exe" create "v12.0" 12.0 -s For LocalDB SQL Express 2012 "C:\Program Files\Microsoft SQL Server\110\Tools\Binn\SqlLocalDB.exe" create "v11.0" 11.0 -s
ب) ذکر DataDirectory
در رشتهی اتصالی فوق، پارامتر DataDirectory نیز ذکر شدهاست تا بتوان مسیر بانک اطلاعاتی را به صورت نسبی و بدون ذکر عبارت دقیق آن که ممکن است در سیستمهای دیگر متفاوت باشد، پردازش کرد. این پارامتر در برنامههای وب به پوشهی استاندارد app_data اشاره میکند و نیازی به تنظیم اضافهتری ندارد. اما در برنامههای دسکتاپ باید به نحو ذیل به صورت دستی، در آغاز برنامه مقدار دهی شود:
AppDomain.CurrentDomain.SetData("DataDirectory", AppDomain.CurrentDomain.BaseDirectory);
AppDomain.CurrentDomain.SetData("DataDirectory", Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "db"));
محل نصب بانکهای اطلاعاتی پیش فرض آن کدام است؟
ذکر AttachDbFilename در رشتهی اتصالی فوق، اختیاری است. در صورت عدم ذکر آن، بانک اطلاعاتی ایجاد شده را در یکی از مسیرهای ذیل میتوانید جستجو کنید:
C:\Users\USERNAME\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances C:\Users\USERNAME\AppData\Local\Microsoft\VisualStudio\SSDT
آیا میتوان فایلهای mdf و ldf آنرا به نگارش کامل SQL Server متصل (attach) کرد؟
بله. اما باید دقت داشته باشید که SQL Server به محض اتصال یک بانک اطلاعاتی با نگارش پایینتر به آن، ابتدا شماره نگارش آنرا به روز میکند. یعنی دیگر نخواهید توانست این بانک اطلاعاتی را با نگارش پایینتر LocalDB باز کنید و یک چنین پیام خطایی را دریافت خواهید کرد:
The database xyz cannot be opened because it is version 706. This server supports version 663 and earlier. A downgrade path is not supported.
چگونه محتوای بانکهای اطلاعاتی LocalDB را با VS.NET مشاهده کنیم؟
از منوی view گزینهی server explorer را انتخاب کنید. بر روی data connections کلیک راست کرده و گزینهی Add connection را انتخاب کنید.
در صفحهی باز شده، گزینهی Microsoft SQL server را انتخاب کنید. در صفحهی بعد، ذکر server name مطابق data source رشتهی اتصالی بحث شده و سپس انتخاب گزینهی attach a database file کفایت میکند:
پس از کلیک بر روی ok، امکان کار با اجزای این بانک اطلاعاتی را خواهید داشت:
چگونه از LocalDB با EF استفاده کنیم؟
EF 6.x به صورت پیش فرض از بانک اطلاعاتی LocalDB استفاده میکند و تنها داشتن یک چنین تنظیمی در فایل کانفیگ برنامه، برای کار با آن کافی است:
<?xml version="1.0" encoding="utf-8"?> <configuration> <configSections> <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /> </configSections> <connectionStrings> <add name="Sample35Context" connectionString="Data Source=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|\test.mdf;Integrated Security=True;" providerName="System.Data.SqlClient" /> </connectionStrings> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" /> </startup> <entityFramework> <defaultConnectionFactory type="System.Data.Entity.Infrastructure.LocalDbConnectionFactory, EntityFramework"> <parameters> <parameter value="mssqllocaldb" /> </parameters> </defaultConnectionFactory> <providers> <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" /> </providers> </entityFramework> </configuration>
البته باید دقت داشت که اسمبلی EntityFramework.SqlServer نیز به صورت خودکار به همراه بستهی نیوگت EF 6.x به برنامه اضافه میشود که استفادهی از connection factory ذکر شده را میسر میکند.
استفادهی از LocalDB به همراه برنامههای وب چگونه است؟
سه نکته را باید در حین استفادهی از LocalDB، در برنامههای وب اجرا شدهی بر روی IIS مدنظر داشت:
الف) LocalDB یک بانک اطلاعاتی user-mode است و child process آن تحت مجوز اکانت تنظیم شدهی برای آن کار میکند.
ب) همانطور که عنوان شد، در رشتهی اتصالی ذکر شده، پارامتر DataDirectory به پوشهی استاندارد app_data اشاره میکند که فایلهای قرار گرفتهی در آن توسط IIS محافظت میشوند و از طریق وب قابل دسترسی و دانلود نیستند.
ج) child process مربوط به LocalDB، نیاز به دسترسی write، برای کار با فایلهای mdf و ldf خود دارد.
برای مورد الف نیاز است تا به تنظیمات application pool برنامه مراجعه کرده و سپس بر روی آن کلیک راست کرد و گزینهی advanced settings را انتخاب نمود. در اینجا گزینهی load user profile باید true باشد:
تنظیم load user profile ضروری است اما کافی نیست. پس از آن باید setProfileEnvironment را نیز به true تنظیم کرد. تنظیم این مورد در کنسول مدیریتی IIS به صورت زیر است.
ابتدا ریشهی اصلی سرور را انتخاب کنید و سپس به configuration editor آن وارد شوید:
در ادامه از دارپ داون آن، گزینهی system.applicationHost و زیر شاخهی applicationPools آنرا انتخاب کنید:
در اینجا application pool defaults و سپس در آن processModel را نیز باز کنید:
اکنون امکان ویرایش setProfileEnvironment را به true خواهید داشت:
پس از این تنظیم، ابتدا بر روی دکمهی apply سمت راست صفحه کلیک کرده و سپس نیاز است یکبار IIS را نیز ریست کنید تا تنظیمات اعمال شوند.
در ادامه برای تنظیم دسترسی write (موارد ب و ج)، ابتدا بر روی پوشهی app_data برنامه، کلیک راست کرده و برگهی security آنرا باز کنید. سپس بر روی دکمهی edit کلیک کرده و در صفحهی باز شده بر روی دکمهی add کلیک کنید تا بتوان به کاربر application pool برنامه دسترسی write داد:
در اینجا iis apppool\TestLocalDB را وارد کرده و بر روی دکمهی check name کلیک کنید.
iis apppool آن که مشخص است. عبارت TestLocalDB نام application pool ایی است که برای برنامهی وب خود ایجاد کردهایم (بهتر است به ازای هر برنامهی وب، یک application pool مجزا تعریف شود).
در اینجا بر روی OK کلیک کرده و به این کاربر جدید اضافه شده، دسترسی full control را بدهید تا برنامه و یوزر آن بتواند فایلهای mdf و ldf را ایجاد کرده و به روز رسانی کنند.
پس از تنظیم load user profile و همچنین set profile environment و دادن دسترسی write به کاربر application pool برنامه، اکنون child process مربوط به local db را میتوان ذیل پروسهی IIS مشاهده کرد و برنامه قادر به استفادهی از LocalDB خواهد بود:
اشتراکها
کتابی در مورد Angular و Firebase
What you will learn in this eBook?
We will cover the following Angular concepts in this book:
- Using Cloud Firestore with an Angular application
- Angular Material and Bootstrap
- Template-driven forms
- Form validation
- Custom pipes
- Auth-guards in Angular
- Authentication and Authorization
- Login with Google using Firebase
- Social share option using ngx-share
- Client-Side pagination using ngx-pagination
- Deploying an Angular app in Firebase
اشتراکها
نگاهی به Angular 2.0 Core
مطلبی را در مورد شبیه سازی ارسال ایمیل جهت بررسی خروجی واقعی یک برنامه قبلا نوشته بودم. در تکمیل این مبحث، برنامه رایگان و سورس بازی به نام Antix SMTP Server for Developers نیز وجود دارد که از آدرس زیر قابل دریافت است:
این برنامه به صورت یک پروسه پس زمینه اجرا شده و تواناییهای یک SMTP Server واقعی را شبیه سازی میکند؛ بدون اینکه ایمیلی را ارسال نماید. پس از اجرا، منتظر دریافت ایمیلهای ارسالی از طریق SMTP Client برنامهی شما شده و پس از دریافت ایمیلها، آنها را در پوشهای مشخص ذخیره میکند. همچنین توسط این برنامه میتوان عنوان ایمیلهای ارسالی را نیز مشاهده نمود (مزیت اصلی نسبت به روش قبلی معرفی شده). با دوبار کلیک بر روی ایمیلهای لیست شده، میتوان آنها را در mail client نصب شده مانند آوت لوک، مشاهده نمود. به این صورت یک برنامه نویس میتواند متن و فرمت ایمیلهای ارسالی توسط برنامه خود را پیش از بکارگیری آن در یک محیط واقعی کاری، کاملا بررسی و آزمایش نماید. بدیهی است که این برنامه حتی میتواند بر روی کامپیوتری دیگر در شبکه نیز قرار داشته باشد. همچنین با توجه به نحوهی توزیع ClickOnce این برنامه، هر بار که بسته شود، بررسی خواهد کرد که آیا نگارش جدیدتری از آن آماده شده است یا خیر (اگر نصاب ClickOnce آن را دریافت و نصب کنید).
اگر از دات نت فریم ورک استفاده میکنید، جهت استفاده از این شبیه ساز کافی است app.config و یا web.config برنامه شما به صورت زیر تنظیم شده باشد:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<mailSettings>
<smtp>
<network port="25" host="127.0.0.1"/>
</smtp>
</mailSettings>
</system.net>
</configuration>
پ.ن.
همانطور که در تصویر مشخص است این برنامه قادر به تفسیر عنوان ایمیل فارسی نیست (اولین عنوان بررسی شده فارسی است). اگر وقت کردید در این پروژه سورس باز شرکت کنید و نکته زیر را به آن اعمال نمائید (زیبایی یک کار سورس باز ...):
رمزگشایی عنوان یک ایمیل فارسی دریافت شده