اشتراکها
تا اینجا با روشهای مختلف جمع آوری اطلاعات آماری مرتبط با کوئریهای اجرا شدهی در SQL Server آشنا شدیم. در این قسمت قصد داریم بررسی کنیم این اطلاعات جمع آوری شده، چه مفاهیمی را در بر دارند و مهمترینهای آنها کدامند؟
شاخصهای مهم بررسی کارآیی کوئریها
در ابتدای بررسی هر کوئری، باید 4 شاخص بسیار مهم، مدنظر باشند:
- مدت زمان اجرای کوئری: هرچند بررسی مدت زمان اجرای کوئری، شاخص مهمیاست، اما الزاما حاوی اطلاعات مفیدی در مورد آن کوئری نیست. برای مثال اگر یک کوئری زیاد طول میکشد، حتما به معنای وجود مشکلی با آن نیست؛ ممکن است اطلاعات زیادی را واکشی میکند یا ممکن است توسط عاملی سد شدهاست. در این موارد هرچند مشکلاتی وجود دارند، اما مستقیما مرتبط با آن کوئری نیستند.
- میزان مصرف CPU: میزان کاری که باید توسط CPU انجام شود تا کوئری به نتیجه برسد.
- I/O: در SQL Server میتوان هم physical I/O و هم logical I/O را بررسی کرد. برای مثال اگر اطلاعات مورد درخواست توسط کوئری هم اکنون در حافظه موجود باشند، نیازی به physical I/O پرهزینه نخواهد بود و در مقابل آن logical I/O کم هزینهتر است.
- میزان مصرف حافظه
در کل هر کدام از این شاخصها اگر دارای مقدار بالایی باشند، بیانگر وجود مشکلی است.
مروری بر ابزارهای مختلف اندازهگیری شاخصهای کارآیی
Management studio
درون Management studio میتوان اطلاعات مرتبط با یک کوئری را به صورت زنده مشاهده کرد. البته این اطلاعات صرفا مرتبط با یک کوئری و یا تعدادی مشخص هستند؛ چون باید کوئری را به صورت دستی درون این برنامه اجرا کرد و سپس اطلاعات اجرای کوئریها را دریافت نمود. اطلاعات آماری که توسط آن نیز ارائه میشود محدودیتهایی دارد. برای مثال مدت زمان اجرای کوئری و یا تعداد رکوردهای تحت تاثیر قرار گرفته شده را میتوان مشاهده کرد. اما به اندازهی اطلاعات ارائه شدهی در یک execution plan کامل نیست. به علاوه بازگشت اطلاعات حاصل از اجرای کوئریها درون این برنامه، سربار خودش را داشته و سبب کند شدن برنامه میشود. در آخر اطلاعات ارائه شدهی توسط آنرا نیز باید از قسمتهای مختلفی جمع آوری و به صورت دستی ذخیره کرد.
Extended Events
توسط Extended Events نیز میتوان همانند Management studio، اطلاعات آماری یک تک کوئری و یا یک batch را جمع آوری کرد؛ اما پس از ایجاد و تنظیم آن، به صورت خودکار اجرا میشود. در حین تعریف یک سشن Extended Events میتوان شاخصهای خاصی را انتخاب کرد و یا شرطهای دقیقی را اعمال کرد. خروجی آن نیز به صورت خودکار در یک فایل ذخیره میشود.
Dynamic management objects
با استفاده از DMO's از نتایج آماری مرتبط با تک کوئریها، به نتایج تجمعی حاصل از اجرای آنها میرسیم. این نتایج نیز در plan cache ذخیره میشوند. به این معنا که اگر کش، تخلیه (با اجرای دستور DBCC FREEPROCCACHE) و یا سرور ریاستارت شود، این اطلاعات از دست خواهند رفت. هدف آن بیشتر رفع اشکال کوئریهایی است که هم اکنون در حال اجرا هستند. اگر نیاز به اطلاعات دورهای را داشته باشید، نیاز خواهید داشت تا با تهیهی snapshotهایی از بانک اطلاعاتی، این تاریخچه را تکمیل کنید. به همین جهت Query Store ارائه شدهاست تا نیازی به اینکار نباشد.
Query Store
Query Store کار ذخیره سازی متن plan و آمار تجمعی مرتبط با آنرا به صورت خودکار انجام میدهد و آنرا درون بانک اطلاعاتی کاربر ذخیره میکند. به همین جهت با خالی شدن کش، برخلاف DMO's، اطلاعات آن حذف نمیشود.
مثالی از روشهای مختلف جمع آوری اطلاعات آماری حاصل از اجرای کوئریها در SQL Server
در ادامه قصد داریم با مثالی، خلاصهای را از سه قسمتی که تاکنون بررسی کردیم، ارائه دهیم. برای این منظور ابتدا رویهی ذخیره شدهی زیر را ایجاد میکنیم:
کار آن دریافت اطلاعات یک کاربر بر اساس ID او میباشد.
سپس یک سشن Extended event را با نام QueryPerf ایجاد میکنیم:
این سشن به رخدادهای sql_statement_completed، sp_statement_completed و query_post_execution_showplan، اگر طول مدت آن کوئری بیش از 1 میلی ثانیه باشد، واکنش نشان میدهد. نتیجهی نهایی را نیز در پوشهی C:\Temp\QueryPerf ذخیره میکند (این پوشه را باید به صورت دستی ایجاد کنید).
در ادامه Query Store را نیز بر روی بانک اطلاعاتی WideWorldImporters فعال کرده و همچنین اگر اطلاعاتی از پیش در آن وجود دارند، پاک میشود.
سپس هر آنچه را که در plan cache نیز وجود دارد، حذف میکنیم:
اکنون سشن QueryPerf را که پیشتر ایجاد کردیم، آغاز میکنیم:
نتیجهی آنرا در قسمت management->extended events، با سبز شدن آیکن QueryPerf میتوانید مشاهده کنید.
در ادامه چون میخواهیم نتایج آماری را در management studio نیز مشاهده کنیم، ابتدا جمع آوری شاخصهای آماری را در یک پنجرهی جدید new query، فعال میکنیم:
همچنین در منوی Query، گزینهی Include client statistics را نیز انتخاب میکنیم تا مشخص شود که آیا عملیات insert/update/delete انجام شدهاست. چه تعداد ردیف تحت تاثیر اجرای این کوئری قرار گرفتهاند. چه تعداد تراکنش انجام شدهاست. همچنین اطلاعات آماری شبکه و زمان نیز ارائه شوند.
پس از این تنظیمات، اکنون نوبت به اجرای کوئریهای زیر رسیدهاست که یکی پارامتری است و دیگری AdHoc:
با اجرای آن، در management studio، برگههای messages و client statistics ظاهر میشوند که هر کدام اینبار اطلاعات آماری اجرای این کوئری را به همراه دارند. همچنین در قسمت results، امکان مشاهدهی query plan، به علت فعال بودن اطلاعات آماری XML، وجود دارد.
سپس سشن QueryPerf را متوقف و حذف میکنیم:
فایل خروجی با پسوند xel آن را که در پوشهی C:\Temp\QueryPerf ذخیره شدهاست، میتوان در management studio مشاهده کرد. البته در ابتدای نمایش آن، صرفا دو ستون name و timestamp را نمایش میدهد که میتوان با انتخاب هر ردیف آن و سپس انتخاب و کلیک راست بر روی ردیفهای details آن، گزینهی Show Column in table را انتخاب کرد تا شاخص مدنظر، در ستونهای گزارش نیز ظاهر شود.
اگر بخواهیم از عملیات صورت گرفته توسط DMO's کوئری بگیریم:
که در آن تنها ردیفهایی که متن کوئری آنها حاوی Countries است، فیلتر شده، به یک چنین خروجی خواهیم رسید:
همانطور که مشاهده میکنید، شاخصهای چهارگانهای که در ابتدای بحث معرفی شدند، در مورد کوئری پارامتری نوشته شده، وضعیت بسیار بهتری نسبت به کوئری AdHoc دوم دارند.
از Query Store هم میتوان به صورت زیر کوئری گرفت (علاوه بر قسمت رابط کاربری Query Store که ذیل اشیاء مرتبط با بانک اطلاعاتی WideWorldImporters در management studio قابل مشاهدهاست):
شاخصهای مهم بررسی کارآیی کوئریها
در ابتدای بررسی هر کوئری، باید 4 شاخص بسیار مهم، مدنظر باشند:
- مدت زمان اجرای کوئری: هرچند بررسی مدت زمان اجرای کوئری، شاخص مهمیاست، اما الزاما حاوی اطلاعات مفیدی در مورد آن کوئری نیست. برای مثال اگر یک کوئری زیاد طول میکشد، حتما به معنای وجود مشکلی با آن نیست؛ ممکن است اطلاعات زیادی را واکشی میکند یا ممکن است توسط عاملی سد شدهاست. در این موارد هرچند مشکلاتی وجود دارند، اما مستقیما مرتبط با آن کوئری نیستند.
- میزان مصرف CPU: میزان کاری که باید توسط CPU انجام شود تا کوئری به نتیجه برسد.
- I/O: در SQL Server میتوان هم physical I/O و هم logical I/O را بررسی کرد. برای مثال اگر اطلاعات مورد درخواست توسط کوئری هم اکنون در حافظه موجود باشند، نیازی به physical I/O پرهزینه نخواهد بود و در مقابل آن logical I/O کم هزینهتر است.
- میزان مصرف حافظه
در کل هر کدام از این شاخصها اگر دارای مقدار بالایی باشند، بیانگر وجود مشکلی است.
مروری بر ابزارهای مختلف اندازهگیری شاخصهای کارآیی
Management studio
درون Management studio میتوان اطلاعات مرتبط با یک کوئری را به صورت زنده مشاهده کرد. البته این اطلاعات صرفا مرتبط با یک کوئری و یا تعدادی مشخص هستند؛ چون باید کوئری را به صورت دستی درون این برنامه اجرا کرد و سپس اطلاعات اجرای کوئریها را دریافت نمود. اطلاعات آماری که توسط آن نیز ارائه میشود محدودیتهایی دارد. برای مثال مدت زمان اجرای کوئری و یا تعداد رکوردهای تحت تاثیر قرار گرفته شده را میتوان مشاهده کرد. اما به اندازهی اطلاعات ارائه شدهی در یک execution plan کامل نیست. به علاوه بازگشت اطلاعات حاصل از اجرای کوئریها درون این برنامه، سربار خودش را داشته و سبب کند شدن برنامه میشود. در آخر اطلاعات ارائه شدهی توسط آنرا نیز باید از قسمتهای مختلفی جمع آوری و به صورت دستی ذخیره کرد.
Extended Events
توسط Extended Events نیز میتوان همانند Management studio، اطلاعات آماری یک تک کوئری و یا یک batch را جمع آوری کرد؛ اما پس از ایجاد و تنظیم آن، به صورت خودکار اجرا میشود. در حین تعریف یک سشن Extended Events میتوان شاخصهای خاصی را انتخاب کرد و یا شرطهای دقیقی را اعمال کرد. خروجی آن نیز به صورت خودکار در یک فایل ذخیره میشود.
Dynamic management objects
با استفاده از DMO's از نتایج آماری مرتبط با تک کوئریها، به نتایج تجمعی حاصل از اجرای آنها میرسیم. این نتایج نیز در plan cache ذخیره میشوند. به این معنا که اگر کش، تخلیه (با اجرای دستور DBCC FREEPROCCACHE) و یا سرور ریاستارت شود، این اطلاعات از دست خواهند رفت. هدف آن بیشتر رفع اشکال کوئریهایی است که هم اکنون در حال اجرا هستند. اگر نیاز به اطلاعات دورهای را داشته باشید، نیاز خواهید داشت تا با تهیهی snapshotهایی از بانک اطلاعاتی، این تاریخچه را تکمیل کنید. به همین جهت Query Store ارائه شدهاست تا نیازی به اینکار نباشد.
Query Store
Query Store کار ذخیره سازی متن plan و آمار تجمعی مرتبط با آنرا به صورت خودکار انجام میدهد و آنرا درون بانک اطلاعاتی کاربر ذخیره میکند. به همین جهت با خالی شدن کش، برخلاف DMO's، اطلاعات آن حذف نمیشود.
مثالی از روشهای مختلف جمع آوری اطلاعات آماری حاصل از اجرای کوئریها در SQL Server
در ادامه قصد داریم با مثالی، خلاصهای را از سه قسمتی که تاکنون بررسی کردیم، ارائه دهیم. برای این منظور ابتدا رویهی ذخیره شدهی زیر را ایجاد میکنیم:
USE [WideWorldImporters]; GO DROP PROCEDURE IF EXISTS [Application].[usp_GetPersonInfo]; GO CREATE PROCEDURE [Application].[usp_GetPersonInfo] (@PersonID INT) AS SELECT [p].[FullName], [p].[EmailAddress], [c].[FormalName] FROM [Application].[People] [p] LEFT OUTER JOIN [Application].[Countries] [c] ON [p].[PersonID] = [c].[LastEditedBy] WHERE [p].[PersonID] = @PersonID; GO
سپس یک سشن Extended event را با نام QueryPerf ایجاد میکنیم:
IF EXISTS ( SELECT * FROM sys.server_event_sessions WHERE [name] = 'QueryPerf') BEGIN DROP EVENT SESSION [QueryPerf] ON SERVER; END GO CREATE EVENT SESSION [QueryPerf] ON SERVER ADD EVENT sqlserver.sp_statement_completed( WHERE ([duration]>(1000))), ADD EVENT sqlserver.sql_statement_completed( WHERE ([duration]>(1000))), ADD EVENT sqlserver.query_post_execution_showplan ADD TARGET package0.event_file( SET filename=N'C:\Temp\QueryPerf\test.xel',max_file_size=(256)) WITH ( MAX_MEMORY=16384 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS, MAX_DISPATCH_LATENCY=5 SECONDS,MAX_EVENT_SIZE=0 KB, MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF); GO
در ادامه Query Store را نیز بر روی بانک اطلاعاتی WideWorldImporters فعال کرده و همچنین اگر اطلاعاتی از پیش در آن وجود دارند، پاک میشود.
USE [master]; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE = ON; GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE ( OPERATION_MODE = READ_WRITE, CLEANUP_POLICY = (STALE_QUERY_THRESHOLD_DAYS = 30), DATA_FLUSH_INTERVAL_SECONDS = 60, INTERVAL_LENGTH_MINUTES = 5, MAX_STORAGE_SIZE_MB = 100, QUERY_CAPTURE_MODE = ALL, SIZE_BASED_CLEANUP_MODE = AUTO, MAX_PLANS_PER_QUERY = 200); GO ALTER DATABASE [WideWorldImporters] SET QUERY_STORE CLEAR; GO
سپس هر آنچه را که در plan cache نیز وجود دارد، حذف میکنیم:
DBCC FREEPROCCACHE; GO
اکنون سشن QueryPerf را که پیشتر ایجاد کردیم، آغاز میکنیم:
ALTER EVENT SESSION [QueryPerf] ON SERVER STATE = START; GO
در ادامه چون میخواهیم نتایج آماری را در management studio نیز مشاهده کنیم، ابتدا جمع آوری شاخصهای آماری را در یک پنجرهی جدید new query، فعال میکنیم:
SET STATISTICS IO ON; GO SET STATISTICS TIME ON; GO SET STATISTICS XML ON; GO
همچنین در منوی Query، گزینهی Include client statistics را نیز انتخاب میکنیم تا مشخص شود که آیا عملیات insert/update/delete انجام شدهاست. چه تعداد ردیف تحت تاثیر اجرای این کوئری قرار گرفتهاند. چه تعداد تراکنش انجام شدهاست. همچنین اطلاعات آماری شبکه و زمان نیز ارائه شوند.
پس از این تنظیمات، اکنون نوبت به اجرای کوئریهای زیر رسیدهاست که یکی پارامتری است و دیگری AdHoc:
USE [WideWorldImporters]; GO EXECUTE [Application].[usp_GetPersonInfo] 1234; GO SELECT [s].[StateProvinceName], [s].[SalesTerritory], [s].[LatestRecordedPopulation], [s].[StateProvinceCode] FROM [Application].[Countries] [c] JOIN [Application].[StateProvinces] [s] ON [s].[CountryID] = [c].[CountryID] WHERE [c].[CountryName] = 'United States'; GO
سپس سشن QueryPerf را متوقف و حذف میکنیم:
ALTER EVENT SESSION [QueryPerf] ON SERVER STATE = STOP; GO DROP EVENT SESSION [QueryPerf] ON SERVER; GO
اگر بخواهیم از عملیات صورت گرفته توسط DMO's کوئری بگیریم:
SELECT [qs].[last_execution_time], [qs].[execution_count], [qs].[total_elapsed_time], [qs].[total_elapsed_time]/[qs].[execution_count] [AvgDuration], [qs].[total_logical_reads], [qs].[total_logical_reads]/[qs].[execution_count] [AvgLogicalReads], [t].[text], [p].[query_plan] FROM sys.dm_exec_query_stats [qs] CROSS APPLY sys.dm_exec_sql_text([qs].sql_handle) [t] CROSS APPLY sys.dm_exec_query_plan([qs].[plan_handle]) [p] WHERE [t].[text] LIKE '%Countries%'; GO
همانطور که مشاهده میکنید، شاخصهای چهارگانهای که در ابتدای بحث معرفی شدند، در مورد کوئری پارامتری نوشته شده، وضعیت بسیار بهتری نسبت به کوئری AdHoc دوم دارند.
از Query Store هم میتوان به صورت زیر کوئری گرفت (علاوه بر قسمت رابط کاربری Query Store که ذیل اشیاء مرتبط با بانک اطلاعاتی WideWorldImporters در management studio قابل مشاهدهاست):
USE [WideWorldImporters]; GO SELECT [qsq].[query_id], [qst].[query_sql_text], CASE WHEN [qsq].[object_id] = 0 THEN N'Ad-hoc' ELSE OBJECT_NAME([qsq].[object_id]) END AS [ObjectName], [qsp].[plan_id], [rs].[count_executions], [rs].[avg_logical_io_reads], [rs].[avg_duration], TRY_CONVERT(XML, [qsp].[query_plan]), [rs].[last_execution_time], (DATEADD(MINUTE, -(DATEDIFF(MINUTE, GETDATE(), GETUTCDATE())), [rs].[last_execution_time])) AS [LocalLastExecutionTime] FROM [sys].[query_store_query] [qsq] JOIN [sys].[query_store_query_text] [qst] ON [qsq].[query_text_id] = [qst].[query_text_id] JOIN [sys].[query_store_plan] [qsp] ON [qsq].[query_id] = [qsp].[query_id] JOIN [sys].[query_store_runtime_stats] [rs] ON [qsp].[plan_id] = [rs].[plan_id] WHERE [qst].[query_sql_text] LIKE '%Countries%'; GO
در این مطلب قصد داریم پیامها و اخطارهای برنامه را توسط کامپوننت Angular2 Toasty نمایش داده و همچنین برای کاهش میزان تکرار قسمتهای نمایش خطا در برنامه، کار مدیریت متمرکز و سراسری آنها را نیز انجام دهیم.
نمایش پیامها و اخطارهای یک برنامهی Angular توسط ng2-toasty
در مطلب «ایجاد Drop Down Listهای آبشاری در Angular» در قسمت دریافت اطلاعات drop down دوم از سرور، اگر کاربر مجددا گروه را بر روی حالت «لطفا گروهی را انتخاب کنید ...» قرار دهد، مقدار categoryId به undefined تغییر میکند:
در اینجا میخواهیم توسط کامپوننت Angular2 Toasty، پیام متناسبی را نمایش دهیم:
پیشنیازهای کار با کامپوننت Angular2 Toasty توسط یک برنامهی Angular CLI
برای کار با کامپوننت Angular2 Toasty، ابتدا از طریق خط فرمان به پوشهی ریشهی برنامه وارد شده و سپس دستور ذیل را صادر میکنیم:
اینکار سبب خواهد شد تا این کامپوننت در پوشهی node_modules\ng2-toasty نصب شده و همچنین فایل package.json نیز جهت درج مدخل آن به روز رسانی شود:
یک نکته: اگر در حین اجرای این دستور به خطای ذیل برخوردید:
چون VSCode پوشهی node_modules را تحت نظر قرار میدهد، ممکن است یک سری اعمال npm مجوز اجرا را پیدا نکنند. بنابراین ابتدا VSCode را بسته و مجددا دستور npm را اجرا کنید.
پس از آن نیاز است یکی از شیوهنامههایی را که در تصویر فوق ملاحظه میکنید، در فایل angular-cli.json. مشخص کنیم:
که برای نمونه در اینجا، شیوهنامهی بوت استرپ آن انتخاب شدهاست.
سپس باید به فایل src\app\app.module.ts مراجعه کرد و ماژول این کامپوننت را معرفی نمود:
همچنین در همین قسمت، به فایل قالب src\app\app.component.html مراجعه کرده و selector tag این کامپوننت را در ابتدای آن تعریف میکنیم:
در اینجا با استفاده از property binding و تعیین مقدار رشتهای top-right، محل نمایش اعلانات برنامه را مشخص میکنیم. مقدارهای ممکن آن شامل bottom-right، bottom-left، top-right، top-left، top-center، bottom-center، center-center هستند. برای مثال اگر میخواهید آنرا در میانهی صفحه نمایش دهید، مقدار center-center را انتخاب کنید. همچنین باید دقت داشت که این مقدار باید درون '' قرار گیرد تا مشخص شود که رشتهای به خاصیت position انتساب داده شدهاست و این مقدار یک خاصیت عمومی تعریف شدهی در کامپوننت متناظر با قالب، نیست.
نمایش یک پیام خطا توسط ToastyService
اکنون که کار برپایی کامپوننت Angular2 Toasty به پایان رسید، کار کردن با آن به سادگی تزریق سرویس آن به سازندهی یک کامپوننت و فراخوانی متدهای info، success ، wait ، error و warning آن است:
- در اینجا در ابتدا ماژولهای مورد نیاز import شدهاند.
- سپس ToastyService به سازندهی کلاس کامپوننت مدنظر تزریق شدهاست تا بتوان از امکانات آن استفاده کرد.
- در ادامه، فراخوانی متد this.toastyService.error سبب نمایش اخطار قرمز رنگی میشود که تصویر آنرا در ابتدای مطلب جاری مشاهده کردید.
- علت ذکر <ToastOptions> در اینجا این است که وجود آن سبب خواهد شد تا intellisense در VSCode فعال شود و پس از آن بتوان تمام گزینههای این متد و تنظیمات را بدون مراجعهی به مستندات آن از طریق intellisense یافت و درج کرد:
مدیریت سراسری خطاهای مدیریت نشده، در یک برنامهی Angular
در برنامههای Angular از این دست کدها بسیار مشاهده میشوند:
تا اینجا قسمت err یا بروز خطا را با console.log مدیریت کردهایم. در این حالت کاربر ممکن است 10 بار بر روی دکمهای کلیک کند یا صفحهای را بارگذاری کند و دست آخر متوجه نشود که مشکل کار چیست. به همین جهت میتوان خطاها را نیز توسط ToastyService نمایش داد تا کاربران دقیقا متوجه بروز مشکل رخ داده شوند. اما ... به این ترتیب تکرار کد زیادی را خواهیم داشت و باید به ازای تمام این موارد، یکبار this.toastyService.error را فراخوانی کنیم. برای مدیریت بهتر یک چنین سناریویی در Angular، کلاس و سرویس توکاری به نام ErrorHandler وجود دارد. در هر قسمتی از برنامهی Angular که استثنایی مدیریت نشده رخ دهد، ابتدا از این کلاس رد شده و سپس به برنامه انتشار پیدا میکند. بنابراین میتوان یک ErrorHandler سفارشی را با ارث بری از آن تهیه کرد و سپس بجای سرویس توکار اصلی، به برنامه معرفی و از آن استفاده نمود. به این ترتیب میتوان یک Global Error Interceptor را طراحی نمود.
به همین منظور کلاس جدیدی را به صورت ذیل در پوشهی src\app اضافه میکنیم:
با این خروجی
سپس این کلاس را به نحو ذیل تکمیل خواهیم کرد:
کلاس جدید AppErrorHandler از کلاس پایه ErrorHandler ارث بری میکند. بنابراین import آنرا در ابتدای کار مشاهده میکنید. سپس باید متد handleError آنرا با امضایی که مشاهده میکنید، پیاده سازی کنیم. فعلا با استفاده از console.log این خطا را در کنسول developer tools نمایش میدهیم.
اکنون نیاز است این ErrorHandler سفارشی را بجای نمونهی اصلی به برنامه معرفی کنیم. برای این منظور به فایل src\app\app.module.ts مراجعه کرده و تغییرات ذیل را اعمال میکنیم:
ابتدا ErrorHandler به لیست imports اضافه شدهاست و همچنین محل تامین AppErrorHandler نیز مشخص گردیدهاست. سپس در قسمت providers ماژول جاری، از تعریف خاصی که ملاحظه میکنید، استفاده خواهد شد. به این ترتیب به Angular اعلام میکنیم، هرگاه نیازی به وهلهای از کلاس توکار ErrorHandler بود، وهلهای از کلاس سفارشی AppErrorHandler را مورد استفاده قرار بده.
اکنون برای آزمایش آن، در کدهای سمت سرور مطلب «ایجاد Drop Down Listهای آبشاری در Angular»، یک استثنای عمدی را قرار میدهیم:
به این ترتیب هر زمانیکه گروهی انتخاب شد، دریافت محصولات آن گروه با خطا مواجه میشود.
برای اینکه AppErrorHandler، مورد استفاده قرار گیرد، قسمت err دریافت لیست محصولات را نیز حذف میکنیم (تا تبدیل به یک استثنای مدیریت نشده شود):
اکنون اگر برنامه را اجرا کنیم، چنین پیامی، در کنسول developer tools ظاهر میشود و مشخص است از فایل AppErrorHandler صادر شدهاست:
افزودن ToastyService به AppErrorHandler
در ادامه میخواهیم بجای console.log از ToastyService برای نمایش خطاهای مدیریت نشدهی برنامه در کلاس AppErrorHandler استفاده کنیم:
به همین منظور سرویس آنرا به سازندهی کلاس AppErrorHandler تزریق کرده و سپس از آن به نحو متداولی در متد handleError استفاده میکنیم. به این ترتیب بجای دهها و یا صدها قسمت مدیریت err=>this.toastyService.error در برنامه، تنها یک مورد مدیریت مرکزی را خواهیم داشت.
مشکل اول! اکنون اگر برنامه را اجرا کنیم، در کنسول developer tools چنین خطایی ظاهر میشود:
به این معنا که Angular قادر نیست وهلهای از AppErrorHandler را ایجاد کند؛ چون نمیداند که چگونه باید پارامتر سازندهی ToastyService را وهله سازی و تزریق نماید. علت اینجا است که کار آغاز کلاس ویژهی ErrorHandler سراسری، پیش از کار بارگذاری ماژول مرتبط با ToastyService انجام میشود. به همین جهت، این مورد جزو معدود مواردی است که باید به صورت دستی تزریق شود:
در اینجا توسط Inject decorator، کار تزریق دستی ToastyService انجام خواهد شد. اکنون اگر برنامه را مجدد اجرا کنیم، خطای قبلی برطرف شده؛ یعنی کلاس AppErrorHandler با موفقیت وهله سازی شدهاست.
مشکل دوم! اینبار برنامه را اجرا کنید. سپس گروهی را انتخاب نمائید. مشاهده میکنید که خطایی نمایش داده نشد؛ هرچند در کنسول developer tools میتوان اثری از آن را مشاهده کرد. مجددا گروه دیگری را انتخاب کنید، در این بار دوم است که خطای ارائه شدهی توسط this.toastyService.error ظاهر میشود. توضیح آن نیاز به بررسی مفهومی به نام Zones در Angular دارد.
مفهوم Zones در Angular
زمانیکه متد this.toastyService.error در یک کامپوننت برنامه مورد استفاده قرار گرفت، به خوبی کار میکرد و در همان بار اول فراخوانی، پیام را نمایش میداد. اما با انتقال آن به کلاسAppErrorHandler ، این قابلیت از کار افتاد. علت اینجا است که زمینهی اجرایی این قطعه کد، اکنون خارج از Zone یا ناحیهی Angular است و به همین دلیل متوجه تغییرات آن نمیشود. Zone زمینهی اجرایی اعمال async است و اگر به فایل package.json یک برنامهی Angular دقت کنید، بستهی zone.js، یکی از وابستگیهای همراه آن است.
تغییرات حالت برنامه، توسط یکی از اعمال ذیل رخ میدهند:
الف) بروز رخدادهایی مانند کلیک، ورود اطلاعات و یا ارسال فرم
ب) اعمال Ajax ایی
ج) استفاده از Timers مانند استفاده از setTimeout و setInterval
هر سه مورد یاد شده از نوع async بوده و زمانیکه رخ میدهند، حالت برنامه را تغییر خواهند داد. Angular نیز تنها به این موارد علاقمند بوده و به آنها در جهت به روز رسانی رابط کاربری برنامه واکنش نشان میدهد.
برای مثال this.toastyService.error دارای خاصیتی است به نام timeout: 5000 که در آن، مورد «ج» فوق رخ میدهد؛ یعنی یک Timer پس از 5 ثانیه سبب بسته شدن آن خواهد شد. به همین جهت است که اگر پیش از پایان این 5 ثانیه مجددا درخواست واکشی لیست محصولات یک گروه را بدهیم، خطای مربوطه مشاهده میشود. چون Angular زمینهی اجرایی لازم را فراهم کرده (یا همان Zone در اینجا) و مجبور به واکنش به عملیات async از نوع Timer است.
برای دسترسی به امکانات کتابخانهی zone.js، میتوان از طریق تزریق سرویس آن به نام NgZone به سازندهی کلاس شروع کرد:
در اینجا فراخوانی this.ngZone.run سبب میشود تا درخواست نمایش خطای رخداده وارد Angular Zone شده و بلافاصله سبب نمایش آن گردد:
چند نکته
1- اگر میخواهید علاوه بر رخدادگردانی سراسری خطاها، این خطاها را به محل اصلی آنها نیز انتشار دهید، نیاز است سطر throw error را در انتهای متد handleError نیز ذکر کنید. در غیر اینصورت، کار در همینجا به پایان خواهد رسید و این خطاها دیگر منتشر نمیشوند.
2- روش دریافت URL جاری صفحه را نیز در اینجا مشاهده میکنید. این اطلاعات میتوانند جهت ارسال به سرور برای ثبت و بررسیهای بعدی مفید باشند.
3- مقدار new Error().stack معادل stack trace جاری است و تقریبا در تمام مرورگرهای جدید پشتیبانی میشود.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-template-driven-forms-lab-07.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس به ریشهی پروژه وارد شده و دو پنجرهی کنسول مجزا را باز کنید. در اولی دستورات
و در دومی دستورات ذیل را اجرا کنید:
اکنون میتوانید برنامه را در آدرس http://localhost:5000 مشاهده و اجرا کنید.
نمایش پیامها و اخطارهای یک برنامهی Angular توسط ng2-toasty
در مطلب «ایجاد Drop Down Listهای آبشاری در Angular» در قسمت دریافت اطلاعات drop down دوم از سرور، اگر کاربر مجددا گروه را بر روی حالت «لطفا گروهی را انتخاب کنید ...» قرار دهد، مقدار categoryId به undefined تغییر میکند:
fetchProducts(categoryId?: number) { console.log(categoryId); this.products = []; if (categoryId === undefined || categoryId.toString() === "undefined") { return; }
پیشنیازهای کار با کامپوننت Angular2 Toasty توسط یک برنامهی Angular CLI
برای کار با کامپوننت Angular2 Toasty، ابتدا از طریق خط فرمان به پوشهی ریشهی برنامه وارد شده و سپس دستور ذیل را صادر میکنیم:
> npm install ng2-toasty --save
یک نکته: اگر در حین اجرای این دستور به خطای ذیل برخوردید:
npm ERR! Error: EPERM: operation not permitted, rename
پس از آن نیاز است یکی از شیوهنامههایی را که در تصویر فوق ملاحظه میکنید، در فایل angular-cli.json. مشخص کنیم:
"styles": [ "../node_modules/bootstrap/dist/css/bootstrap.min.css", "../node_modules/ng2-toasty/bundles/style-bootstrap.css", "styles.css" ],
سپس باید به فایل src\app\app.module.ts مراجعه کرد و ماژول این کامپوننت را معرفی نمود:
import { ToastyModule } from "ng2-toasty"; @NgModule({ imports: [ BrowserModule, ToastyModule.forRoot(),
همچنین در همین قسمت، به فایل قالب src\app\app.component.html مراجعه کرده و selector tag این کامپوننت را در ابتدای آن تعریف میکنیم:
<ng2-toasty [position]="'top-right'"></ng2-toasty>
نمایش یک پیام خطا توسط ToastyService
اکنون که کار برپایی کامپوننت Angular2 Toasty به پایان رسید، کار کردن با آن به سادگی تزریق سرویس آن به سازندهی یک کامپوننت و فراخوانی متدهای info، success ، wait ، error و warning آن است:
import { ToastyService, ToastOptions } from "ng2-toasty"; export class ProductGroupComponent implements OnInit { constructor( private productItemsService: ProductItemsService, private toastyService: ToastyService) { } fetchProducts(categoryId?: number) { console.log(categoryId); this.products = []; if (categoryId === undefined || categoryId.toString() === "undefined") { this.toastyService.error(<ToastOptions>{ title: "Error!", msg: "Please select a category.", theme: "bootstrap", showClose: true, timeout: 5000 }); return; }
- سپس ToastyService به سازندهی کلاس کامپوننت مدنظر تزریق شدهاست تا بتوان از امکانات آن استفاده کرد.
- در ادامه، فراخوانی متد this.toastyService.error سبب نمایش اخطار قرمز رنگی میشود که تصویر آنرا در ابتدای مطلب جاری مشاهده کردید.
- علت ذکر <ToastOptions> در اینجا این است که وجود آن سبب خواهد شد تا intellisense در VSCode فعال شود و پس از آن بتوان تمام گزینههای این متد و تنظیمات را بدون مراجعهی به مستندات آن از طریق intellisense یافت و درج کرد:
مدیریت سراسری خطاهای مدیریت نشده، در یک برنامهی Angular
در برنامههای Angular از این دست کدها بسیار مشاهده میشوند:
this.productItemsService.getCategories().subscribe( data => { this.categories = data; }, err => console.log("get error: ", err) );
به همین منظور کلاس جدیدی را به صورت ذیل در پوشهی src\app اضافه میکنیم:
> ng g cl app.error-handler
installing class create src\app\app.error-handler.ts
import { ErrorHandler } from "@angular/core"; export class AppErrorHandler implements ErrorHandler { handleError(error: any): void { console.log("Error:", error); } }
اکنون نیاز است این ErrorHandler سفارشی را بجای نمونهی اصلی به برنامه معرفی کنیم. برای این منظور به فایل src\app\app.module.ts مراجعه کرده و تغییرات ذیل را اعمال میکنیم:
import { NgModule, ErrorHandler } from "@angular/core"; import { AppErrorHandler } from "./app.error-handler"; @NgModule({ providers: [ { provide: ErrorHandler, useClass: AppErrorHandler } ]
اکنون برای آزمایش آن، در کدهای سمت سرور مطلب «ایجاد Drop Down Listهای آبشاری در Angular»، یک استثنای عمدی را قرار میدهیم:
[HttpGet("[action]/{categoryId:int}")] public async Task<IActionResult> GetProducts(int categoryId) { throw new Exception();
برای اینکه AppErrorHandler، مورد استفاده قرار گیرد، قسمت err دریافت لیست محصولات را نیز حذف میکنیم (تا تبدیل به یک استثنای مدیریت نشده شود):
this.productItemsService.getProducts(categoryId).subscribe( data => { this.products = data; this.isLoadingProducts = false; }// , // err => { // console.log("get error: ", err); // this.isLoadingProducts = false; // } );
افزودن ToastyService به AppErrorHandler
در ادامه میخواهیم بجای console.log از ToastyService برای نمایش خطاهای مدیریت نشدهی برنامه در کلاس AppErrorHandler استفاده کنیم:
import { ToastyService, ToastOptions } from "ng2-toasty"; import { ErrorHandler } from "@angular/core"; export class AppErrorHandler implements ErrorHandler { constructor(private toastyService: ToastyService) { } handleError(error: any): void { // console.log("Error:", error); this.toastyService.error(<ToastOptions>{ title: "Error!", msg: "Fatal error!", theme: "bootstrap", showClose: true, timeout: 5000 }); } }
مشکل اول! اکنون اگر برنامه را اجرا کنیم، در کنسول developer tools چنین خطایی ظاهر میشود:
Uncaught Error: Can't resolve all parameters for AppErrorHandler: (?).
import { ErrorHandler, Inject } from "@angular/core"; export class AppErrorHandler implements ErrorHandler { constructor( @Inject(ToastyService) private toastyService: ToastyService ) { }
مشکل دوم! اینبار برنامه را اجرا کنید. سپس گروهی را انتخاب نمائید. مشاهده میکنید که خطایی نمایش داده نشد؛ هرچند در کنسول developer tools میتوان اثری از آن را مشاهده کرد. مجددا گروه دیگری را انتخاب کنید، در این بار دوم است که خطای ارائه شدهی توسط this.toastyService.error ظاهر میشود. توضیح آن نیاز به بررسی مفهومی به نام Zones در Angular دارد.
مفهوم Zones در Angular
زمانیکه متد this.toastyService.error در یک کامپوننت برنامه مورد استفاده قرار گرفت، به خوبی کار میکرد و در همان بار اول فراخوانی، پیام را نمایش میداد. اما با انتقال آن به کلاسAppErrorHandler ، این قابلیت از کار افتاد. علت اینجا است که زمینهی اجرایی این قطعه کد، اکنون خارج از Zone یا ناحیهی Angular است و به همین دلیل متوجه تغییرات آن نمیشود. Zone زمینهی اجرایی اعمال async است و اگر به فایل package.json یک برنامهی Angular دقت کنید، بستهی zone.js، یکی از وابستگیهای همراه آن است.
تغییرات حالت برنامه، توسط یکی از اعمال ذیل رخ میدهند:
الف) بروز رخدادهایی مانند کلیک، ورود اطلاعات و یا ارسال فرم
ب) اعمال Ajax ایی
ج) استفاده از Timers مانند استفاده از setTimeout و setInterval
هر سه مورد یاد شده از نوع async بوده و زمانیکه رخ میدهند، حالت برنامه را تغییر خواهند داد. Angular نیز تنها به این موارد علاقمند بوده و به آنها در جهت به روز رسانی رابط کاربری برنامه واکنش نشان میدهد.
برای مثال this.toastyService.error دارای خاصیتی است به نام timeout: 5000 که در آن، مورد «ج» فوق رخ میدهد؛ یعنی یک Timer پس از 5 ثانیه سبب بسته شدن آن خواهد شد. به همین جهت است که اگر پیش از پایان این 5 ثانیه مجددا درخواست واکشی لیست محصولات یک گروه را بدهیم، خطای مربوطه مشاهده میشود. چون Angular زمینهی اجرایی لازم را فراهم کرده (یا همان Zone در اینجا) و مجبور به واکنش به عملیات async از نوع Timer است.
برای دسترسی به امکانات کتابخانهی zone.js، میتوان از طریق تزریق سرویس آن به نام NgZone به سازندهی کلاس شروع کرد:
import { ToastyService, ToastOptions } from "ng2-toasty"; import { ErrorHandler, Inject, NgZone } from "@angular/core"; import { LocationStrategy, PathLocationStrategy } from "@angular/common"; export class AppErrorHandler implements ErrorHandler { constructor( @Inject(NgZone) private ngZone: NgZone, @Inject(ToastyService) private toastyService: ToastyService, @Inject(LocationStrategy) private locationProvider: LocationStrategy ) { } handleError(error: any): void { // console.log("Error:", error); const url = this.locationProvider instanceof PathLocationStrategy ? this.locationProvider.path() : ""; const message = error.message ? error.message : error.toString(); this.ngZone.run(() => { this.toastyService.error(<ToastOptions>{ title: "Error!", msg: `URL:${url} \n ERROR:${message}`, theme: "bootstrap", showClose: true, timeout: 5000 }); }); // IMPORTANT: Rethrow the error otherwise it gets swallowed // throw error; } }
چند نکته
1- اگر میخواهید علاوه بر رخدادگردانی سراسری خطاها، این خطاها را به محل اصلی آنها نیز انتشار دهید، نیاز است سطر throw error را در انتهای متد handleError نیز ذکر کنید. در غیر اینصورت، کار در همینجا به پایان خواهد رسید و این خطاها دیگر منتشر نمیشوند.
2- روش دریافت URL جاری صفحه را نیز در اینجا مشاهده میکنید. این اطلاعات میتوانند جهت ارسال به سرور برای ثبت و بررسیهای بعدی مفید باشند.
3- مقدار new Error().stack معادل stack trace جاری است و تقریبا در تمام مرورگرهای جدید پشتیبانی میشود.
کدهای کامل این قسمت را از اینجا میتوانید دریافت کنید: angular-template-driven-forms-lab-07.zip
برای اجرای آن فرض بر این است که پیشتر Angular CLI را نصب کردهاید. سپس به ریشهی پروژه وارد شده و دو پنجرهی کنسول مجزا را باز کنید. در اولی دستورات
>npm install >ng build --watch
>dotnet restore >dotnet watch run
یک نکتهی تکمیلی: روشی برای عدم استفاده از Razor Pages جهت لاگین کاربران در برنامههای Blazor Server
در این سری، از razor pages به همراه قالب پیشفرض ASP.NET Core Identity، جهت پیاده سازی ورود کاربران به سیستم، استفاده شدهاست. یعنی کاربر یکبار از فضای Blazor Server خارج شده و وارد یک برنامهی ASP.NET Core Razor Pages معمولی میشود؛ لاگین میکند (در یک ناحیهی مخصوص razor pages) و سپس مجددا وارد قسمت Blazor Server میشود که ... تجربهی کاربری مطلوبی را به همراه ندارد. علت این خروج و ورود را هم در این مطلب میتوانید مطالعه کنید: «دستیابی به HttpContext در Blazor Server». هدف این بوده که بتوان با استفاده از HttpContext مهیای در razor pages (و نه توسط اتصال web socket یک برنامهی blazor server)، کوکیهای پس از لاگین موفق را به سمت مرورگر ارسال و ثبت کرد و درگیر مشکلات به همراه دسترسی به HttpContext در برنامههای Blazor server نشد.
راه دیگری هم برای مواجه شدن با این مشکل وجود دارد: حذف قسمت razor pages؛ حذف نیاز به خروج و ورود از برنامهی blazor server و ... استفاده از ProtectedBrowserStorage که اکنون جزئی از blazor server استاندارد است؛ جهت ثبت اطلاعات user claims و عدم استفاده از کوکیها که نیاز به دسترسی به HttpContext را دارند. اگر علاقمند به مشاهدهی یک مثال کامل در این زمینه هستید، میتوانید به پروژهی « BlazorServerAuthenticationAndAuthorization » مراجعه کنید. در اینجا یک CustomAuthenticationStateProvider را به کمک ProtectedSessionStorage طراحی و استفاده کرده تا نیاز به کار با کوکیها برطرف شود و دیگر نیازی به استفاده از razor pages نباشد. البته باید دقت داشت که SessionStorage محدود به tab جاری است و اگر نیاز است اطلاعات آن در تمام برگههای باز شده در دسترس باشد، بهتر است از ProtectedLocalStorage استفاده کرد. همچنین باید دقت داشت که چون این protected storageها برای رمزنگاری خودکار اطلاعات از ASP.NET Core data protection API استفاده میکنند، نکات مطلب « غیرمعتبر شدن کوکیهای برنامههای ASP.NET Core هاست شدهی در IIS پس از ریاستارت آن » نیز در مورد آنها صادق است.
مطالب دورهها
صفحات مودال در بوت استرپ 3
در مورد صفحات مودال بوت استرپ 2، مطالب ذیل، در سایت جاری پیشتر مطرح شدهاند:
- استفاده از modal dialogs مجموعه Twitter Bootstrap برای گرفتن تائید از کاربر
- نمایش فرمهای مودال Ajax ایی در ASP.NET MVC به کمک Twitter Bootstrap
این کدها نیاز به اندکی تغییر دارند تا با سیستم بوت استرپ 3 سازگار شوند.
ارتقاء کدهای صفحات مودال بوت استرپ 2 به 3
- اگر پیشتر به کلاس modal، کلاس hide را نیز اضافه میکردید، اکنون دیگر نیازی نیست؛ زیرا hide بودن به صورت پیش فرض اعمال میشود (بودن آن هم سبب میشود تا یک صفحه خاکستری نمایش داده شود؛ اما از صفحه مودال خبری نباشد).
- کلاسهای modal-header، modal-body و modal-footer بوت استرپ 2، باید داخل یک div با کلاس modal-content محصور شوند.
- کلاس modal-content باید داخل کلاس modal-dialog محصور شود.
یک مثال:
در این مثال، سلسله مراتب کلاسهای modal ایی که باید تعریف شوند را ملاحظه میکنید. همچنین لینکی با ویژگی data-toggle مساوی modal سبب نمایش این قسمت مخفی از صفحه، به صورت مودال خواهد شد.
در مثالهایی که با بوت استرپ 2 مشاهده کردید (در مقدمه بحث جاری)، این محتوای مخفی به صورت پویا با جاوا اسکریپت به body صفحه اضافه میشود.
بارگذاری یک صفحه مودال Ajax ایی
در بوت استرپ سه میتوان با استفاده از خاصیت remote تنظیمات نمایش یک صفحه مودال، به صورت خودکار اینگونه صفحات را بارگذاری کرد:
و یا حتی اینکار بدون نیاز به کدنویسی جاوا اسکریپتی و با تنظیم ویژگیهای data- مانند مثال ذیل نیز قابل انجام است:
البته بدیهی است در این حالت اطلاعات از طریق HttpGet به صورت خودکار دریافت میشوند. ضمنا مباحث اعتبارسنجی و غیره هم در این حالت به درستی کار نخواهند کرد. بنابراین بهتر است از افزونه مثال انتهای بحث در حالتهای پیشرفتهتر استفاده شود. صرفا برای کاربردهای معمولی نمایش اطلاعات خواندنی، قابلیت ریموت توکار جالب است.
نکته مهم: در حالت ریموت، طراحی محتوایی که باید نمایش داده شود، نباید شامل سطر ذیل باشد. در غیراینصورت اطلاعاتی نمایش داده نخواهد شد:
از این جهت که این سطر با آی دی myModal پیشتر به صفحه اضافه شدهاست و تکرار آن سبب محو محتوای جدید میشود.
به روز رسانی مثالهای ASP.NET MVC جهت سازگاری با بوت استرپ 3
مثال فوق را به همراه کدهای اصلاح شده دو مثال ابتدای بحث (jquery.bootstrap-modal-ajax-form.js و jquery.bootstrap-modal-confirm.js)، از لینک ذیل میتوانید دریافت کنید. این مثال به همراه قالب t4 افزودن Viewهای مودال بوت استرپ (CreateBootstrap3ModalForm.tt) نیز هست.
bs3-sample06.zip
- استفاده از modal dialogs مجموعه Twitter Bootstrap برای گرفتن تائید از کاربر
- نمایش فرمهای مودال Ajax ایی در ASP.NET MVC به کمک Twitter Bootstrap
این کدها نیاز به اندکی تغییر دارند تا با سیستم بوت استرپ 3 سازگار شوند.
ارتقاء کدهای صفحات مودال بوت استرپ 2 به 3
- اگر پیشتر به کلاس modal، کلاس hide را نیز اضافه میکردید، اکنون دیگر نیازی نیست؛ زیرا hide بودن به صورت پیش فرض اعمال میشود (بودن آن هم سبب میشود تا یک صفحه خاکستری نمایش داده شود؛ اما از صفحه مودال خبری نباشد).
- کلاسهای modal-header، modal-body و modal-footer بوت استرپ 2، باید داخل یک div با کلاس modal-content محصور شوند.
- کلاس modal-content باید داخل کلاس modal-dialog محصور شود.
یک مثال:
<div class="container"> <h4 class="alert alert-info"> فرمهای مودال بوت استرپ 3</h4> <div class="row"> <a data-toggle="modal" href="#myModal" class="btn btn-primary">نمایش صفحه مودال</a> <div class="modal" id="myModal"> <div class="modal-dialog"> <div class="modal-content"> <div class="modal-header"> <button type="button" class="close" data-dismiss="modal" aria-hidden="true"> ×</button> <h4 class="modal-title"> عنوان</h4> </div> <div class="modal-body"> محتوای صفحه در اینجا </div> <div class="modal-footer"> <a href="#" data-dismiss="modal" class="btn">بستن</a> <a href="#" class="btn btn-primary"> ذخیره سازی تغییرات</a> </div> </div> </div> </div> </div> <!-- end row --> </div> <!-- /container -->
در این مثال، سلسله مراتب کلاسهای modal ایی که باید تعریف شوند را ملاحظه میکنید. همچنین لینکی با ویژگی data-toggle مساوی modal سبب نمایش این قسمت مخفی از صفحه، به صورت مودال خواهد شد.
در مثالهایی که با بوت استرپ 2 مشاهده کردید (در مقدمه بحث جاری)، این محتوای مخفی به صورت پویا با جاوا اسکریپت به body صفحه اضافه میشود.
بارگذاری یک صفحه مودال Ajax ایی
در بوت استرپ سه میتوان با استفاده از خاصیت remote تنظیمات نمایش یک صفحه مودال، به صورت خودکار اینگونه صفحات را بارگذاری کرد:
$('#myModal').modal({ show: true, remote: '/myNestedContent' });
<a data-toggle="modal" class="btn btn-primary" href="@renderModalPartialViewUrl" data-target="#myModal">Click me</a> <div class="modal fade" id="myModal" tabindex="-1" role="dialog"></div>
نکته مهم: در حالت ریموت، طراحی محتوایی که باید نمایش داده شود، نباید شامل سطر ذیل باشد. در غیراینصورت اطلاعاتی نمایش داده نخواهد شد:
<div class="modal" id="myModal">
به روز رسانی مثالهای ASP.NET MVC جهت سازگاری با بوت استرپ 3
مثال فوق را به همراه کدهای اصلاح شده دو مثال ابتدای بحث (jquery.bootstrap-modal-ajax-form.js و jquery.bootstrap-modal-confirm.js)، از لینک ذیل میتوانید دریافت کنید. این مثال به همراه قالب t4 افزودن Viewهای مودال بوت استرپ (CreateBootstrap3ModalForm.tt) نیز هست.
bs3-sample06.zip
در قسمتهای قبلی( ^ و ^) نحوهی ارتباط بین کامپوننتها در Vue.js بررسی و مزایا و معایب آنها بیان شد. روش دیگری هم برای ارسال اطلاعات از کامپوننتِ Parent به فرزندانش وجود دارد که با استفاده از Dependency Injection یا به اختصار DI مقدور میباشد و در ورژن +2.2 معرفی شد که نحوهی ارتباط بین کامپوننتِ Parent و فرزندانش را آسان نمود. پیشتر برای ارتباط از Parent به Child، از Props استفاده میکردیم، ولی اگر قرار بود در چند سطح این ارتباط عمیق باشد، باز هم مدیریت کردن Props مشکل و سخت بود. اکنون با استفاده از provide و inject قادر خواهیم بود تا آبجکت، فانکشن و یا دیتایِ یک کامپوننتِ Parent را در فرزندانش فراخوانی و استفاده کنیم. اگر در حالت عادی نیاز بود تا در دو سطح، یا بیشتر (مانند تصویر زیر) دیتایِ کامپوننت پدر را به فرزند، نوه و ... انتقال دهیم، میبایست اطلاعات را بصورت Props به هر Level انتقال دهیم.
و در کامپوننتهای فرزند به شکل زیر میتوانیم مقدار foo را دریافت کنیم:
روش جاری شباهت زیادی به استفاده از Context در React دارد:
Context provides a way to pass data through the component tree without having to pass props down manually at every level
جهت به اشتراک گذاری دیتا یا تابعی در کامپوننت Parent با Children، به شکل زیر عمل میکنیم. در اینجا با استفاده از provide، دیتای foo به اشتراک گذاشته شدهاست:
// parent component providing 'foo' var Provider = { provide: { foo: 'bar' }, // ... }
// child component injecting 'foo' var Child = { inject: ['foo'], created () { console.log(this.foo) // => "bar" } // ... }
میتوانیم مقدار پیش فرض دیتایِ ارسالی از کامپوننت Parent را در قسمت data و props در کامپوننت Child دریافت نماییم:
Using an injected value as the default for a prop //دریافت میکنیم props در قسمت child را در کامپوننت foo مقدار const Child = { inject: ['foo'], props: { bar: { default () { return this.foo } } } } Using an injected value as data entry //دریافت میکنیم data در قسمت child را در کامپوننت foo مقدار const Child = { inject: ['foo'], data () { return { bar: this.foo } } }
نکته: در این روش در صورتیکه دیتایِ به اشتراک گذاشته شده در کامپوننتِ Parent تغییر کند، مقدار آن در کامپوننت Child تغییری نخواهد کرد و مانند روشهای قبلی (^ و ^) نیست و نیاز به نوشتن کدی برای تعامل داشتن و بهروز رسانی مقادیر، در کامپوننت Child میباشد.
کد زیر را در نظر بگیرید؛ با زدن دکمهی Increment counter مقدار counter در کامپوننتِParent تغییر میکند، ولی در کامپوننت Child، مقدار counter_in_child تغییری حاصل نمیکند.
<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <script src="https://cdn.jsdelivr.net/npm/vue"></script> <title>Dependency injection</title> </head> <body> <div id="app"> <button @click="counter++">Increment counter</button> <h2>Parent</h2> <p>{{counter}}</p> <div> <h3>Child</h3> <child></child> </div> </div> <script> const Child = { inject: ['counter_in_child'], template: `<div>Counter Child is:{{ counter_in_child }}</div>` }; new Vue ({ el: "#app", components: { Child }, provide() { return { counter_in_child: this.counter }; }, data() { return { counter: 0 }; } }); </script> </body> </html>
برای اینکه بتوان تغییرات ایجاد شدهی بر روی دیتا را در کامپوننتِChild، مشاهده کرد، نیاز داریم کد زیر را در قسمت provide به ازای آن دیتا اضافه کنیم:
<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <script src="https://cdn.jsdelivr.net/npm/vue"></script> <title>Dependency injection</title> </head> <body> <div id="app"> <button @click="counter++">Increment counter</button> <h2>Parent</h2> <p>{{counter}}</p> <div> <h3>Child</h3> <child></child> </div> </div> <script> const Child = { inject: ['counter_in_child'], template: `<div>Counter Child is:{{ counter_in_child.counter }}</div>` }; new Vue ({ el: "#app", components: { Child }, provide() { const counter_in_child={}; Object.defineProperty(counter_in_child,'counter',{ enumerable:true, get:()=>this.counter }) return { counter_in_child }; }, data() { return { counter: 0 }; } }); </script> </body> </html>
مثالی از نحوه به اشتراک گذاری متد بین Parent و Child.
نتیجه گیری:
A) استفاده از این روش مرسوم نیست و بیشتر برای ساخت پلاگین در Vuejs مورد استفاده قرار میگیرد:
provide
and inject
are primarily provided for advanced plugin / component library use cases. It is NOT recommended to use them in generic application code C) این روش برای ارتباط Sibling Component مناسب نیست.
فرض کنید ایمیل اطلاع رسانی برنامه ASP.Net شما قرار است ایمیل زیر را پس از تکمیل یک فرم ارسال کند.
برای ارسال این قالب که مطابق تصویر هر بار باید سه برچسب آن تغییر کند چه راهی را پیشنهاد میدهید؟
راه اول: (راه متداول)
این فرم را در یک html editor درست کرده و جای سه برچسب را خالی میگذاریم. سپس html مورد نظر را در تابع ارسال ایمیل خود به صورت یک رشته تعریف نموده و جاهای خالی را پر خواهیم کرد. مثلا:
string Name = "علی";
string Desc = "منابع مورد نیاز";
int Number = 10;
string content =
"<div dir=\"rtl\" style=\"text-align: right; font-family:Tahoma; font-size:9pt\">" +
"با سلام<br />" +
"احتراما آقای/خانم" +
Name +
" درخواست چاپ" +
Desc +
" دارای" +
Number +
" صفحه را دادهاند. لطفا جهت تائید درخواست ایشان به برنامه مراجعه بفرمائید.<br />" +
"<br />" +
"با تشکر</div>";
- الف) امکان مشاهده شکل نهایی تا زمانیکه ایمیل مورد نظر را دریافت نکرده باشیم، وجود ندارد.
- ب) اعمال تغییرات جدید به این فرمت رشتهای مشکل است. همیشه استفاده از ابزارهای بصری برای بهبود کار کمک بزرگی هستند که در این حالت از آنها محروم خواهیم شد.
- ج)اگر تغییر رسیده جدید، درخواست اضافه کردن لیست پرینتهای قبلی این شخص بود چه باید کرد؟ آیا جدول مورد نظر را باید به صورت دستی ایجاد و باز هم به صورت یک رشته به این مجموعه اضافه کرد؟ در این حالت از کنترلهای استانداردی مانند GridView و امثال آن محروم خواهیم شد.
- د) هر بار تغییر، نیاز به recompile برنامه دارد.
راه دوم: استفاده از قالبها
خوشبختانه در ASP.Net امکان رندر کردن کنترلها به صورت یک string نیز موجود است. در مثال ما نیاز است تا چندین کنترل در کنار هم قرار گیرند تا شکل نهایی را ایجاد کنند. بنابراین میتوان تمام آنها را در یک یوزر کنترل قرار داد. سپس باید کل یوزر کنترل را به صورت یک رشته، رندر کرد که در ادامه به آن خواهیم پرداخت.
اگر قالب فوق را بخواهیم در یک یوزر کنترل طراحی کنیم، سورس صفحه html یوزر کنترل به صورت زیر خواهد بود (فایل WebUserControl1.ascx) :
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="WebUserControl1.ascx.cs"
Inherits="testWebForms87.WebUserControl1" %>
<div dir="rtl" style="text-align: right; font-family:Tahoma; font-size:9pt">
با سلام<br />
احتراما آقای/خانم
<asp:Label ID="lblName" runat="server"></asp:Label>
درخواست چاپ
<asp:Label ID="lblDesc" runat="server"></asp:Label>
دارای
<asp:Label ID="lblNumber" runat="server"></asp:Label>
صفحه را دادهاند. لطفا جهت تائید درخواست ایشان به برنامه مراجعه بفرمائید.<br />
<br />
با تشکر</div>
public string Name { get; set; }
public int Number { get; set; }
public string Desc { get; set; }
protected void Page_Load(object sender, EventArgs e)
{
lblNumber.Text = Number.ToString();
lblName.Text = Name;
lblDesc.Text = Desc;
}
مرحله بعد، رندر کردن خودکار این یوزر کنترل و سپس تبدیل محتوای حاصل به یک رشته است. برای این منظور از تابع زیر میتوان کمک گرفت (برای مثال تعریف شده در کلاس دلخواه CLoadUC) :
using System;
using System.Collections.Generic;
using System.IO;
using System.Reflection;
using System.Web;
using System.Web.UI;
/// <summary>
/// تبدیل یک یوزر کنترل به معادل اچ تی ام ال آن
/// </summary>
/// <param name="path">مسیر یوزر کنترل</param>
/// <param name="properties">لیست خواص به همراه مقادیر مورد نظر</param>
/// <returns></returns>
/// <exception cref="NotImplementedException"><c>NotImplementedException</c>.</exception>
public static string RenderUserControl(string path,
List<KeyValuePair<string,object>> properties)
{
Page pageHolder = new Page();
UserControl viewControl =
(UserControl)pageHolder.LoadControl(path);
Type viewControlType = viewControl.GetType();
foreach (var pair in properties)
{
PropertyInfo property =
viewControlType.GetProperty(pair.Key);
if (property != null)
{
property.SetValue(viewControl, pair.Value, null);
}
else
{
throw new NotImplementedException(string.Format(
"UserControl: {0} does not have a public {1} property.",
path, pair.Key));
}
}
pageHolder.Controls.Add(viewControl);
StringWriter output = new StringWriter();
HttpContext.Current.Server.Execute(pageHolder, output, false);
return output.ToString();
}
که البته تابع نهایی آنرا کمی اصلاح کردم تا بتوان لیستی از خواص پابلیک یک یوزر کنترل را به آن پاس کرد و محدود به یک خاصیت نبود.
اکنون استفاده از یوزر کنترلی که تاکنون طراحی کردهایم به سادگی زیر است:
List<KeyValuePair<string, object>> lst =
new List<KeyValuePair<string, object>>
{
new KeyValuePair<string, object>("Name", "علی"),
new KeyValuePair<string, object>("Number", 10),
new KeyValuePair<string, object>("Desc", "منابع مورد نیاز")
};
string content = CLoadUC.RenderUserControl("WebUserControl1.ascx", lst);
مطالب دورهها
اعمال غیر همزمان و چند ریسمانی
تصور عموم بر آن است که اعمال غیر همزمان با چند ریسمانی به یک معنا هستند. این مورد الزاما صحیح نیست. برای مثال دریافت غیرهمزمان یک فایل را از اینترنت درنظر بگیرید. شاید اینطور به نظر برسد که در اینجا یک ترد جدید ایجاد شده و در آن کل کار دریافت فایل آغاز میگردد؛ اما خیر. ایجاد یک ترد جدید تنها در قسمتهای خاصی از یک پروسه انجام میشود. همچنین از لحاظ فنی امکان انجام کل کار در یک ترد، بدون بلاک کردن آن وجود دارد. از این جهت که بیشتر زمان، جهت صبر کردن دریافت پاسخی از سرور صرف میشود. زمانیکه کلاینت درخواستی را ارسال میکند، دیگر کار خاصی را نمیتواند انجام دهد تا اینکه پاسخی را دریافت کند.
زمانیکه از یک API غیرهمزمان برای مدیریت چنین عملیاتی استفاده میشود، ترد جاری را در این حالت در خواب فرو میبرد. برای اینکه کار بیشتری برای انجام وجود ندارد. همچنین با اینکه کلاینت درخواستی را ارسال میکند یا پاسخی را دریافت، برای مدیریت کل عملیات در اکثر اوقات نیازی به تردها ندارد. این سخت افزار شبکهی نصب شده در سیستم است که عمدهی کار را انجام میدهد و نه برنامه. زمانیکه برنامه درخواست ارسال اطلاعاتی را بر روی شبکه ارائه میدهد، درایور سخت افزار شبکه است که به سخت افزار مرتبط فرمان میدهد چه اطلاعاتی را باید ارسال کند. اکثر اینگونه سخت افزارها قادرند اطلاعات را خارج از حافظهی اصلی سیستم دریافت کنند. در اینجا درایور تنها باید به سخت افزار عنوان کند، چه اطلاعاتی را و به کجا باید ارسال کند. بنابراین CPU تنها در طی ارسال این فرمان است که مشغول میباشد و نه خارج از آن و این زمان اصلا در مقایسه با زمان ارسال اطلاعات توسط سخت افزار مرتبط، طولانی نیست. CPU مجددا زمانی درگیر خواهد شد که سخت افزار شبکه، اطلاعاتی را دریافت کرده است و باز هم این زمان در مقایسه با زمان دریافت اطلاعات توسط سخت افزار شبکه بسیار کوتاه است.
اغلب کارهای IO به همین شکل هستند. شبیه به همین روند در حالت دسترسی به سخت دیسک وجود دارد. مدت زمانیکه CPU به دیسک کنترلر اعلام میکند چه اطلاعاتی را نیاز دارد در مقایسه با مدت زمانیکه دیسک کنترلر این اطلاعات را واقعا بارگذاری میکند، بسیار ناچیز است.
نمونهی دیگر آن کار با بانکهای اطلاعاتی است. در اغلب اوقات برنامهی ما صرفا یک درخواست را به بانک اطلاعاتی ارائه میدهد و اصل عملیات در جایی دیگر و توسط موتور بانک اطلاعاتی، خارج از برنامه پردازش میگردد.
بنابراین جهت پردازش یک پروسهی خاص، در بسیاری از مراحل آن تنها یک ترد کافی است و هدف اصلی اعمال غیرهمزمان، کاهش تعداد تردهایی است که برنامه جهت پردازش عملیاتی خاص، نیاز دارد. این نوع الگوریتمها طوری طراحی شدهاند تا تردها تنها زمانی بکار گرفته شود که واقعا CPU قرار است کار خاصی را انجام دهد و نه برای مثال زمانیکه دیسک کنترلر یا سخت افزار شبکه مشغول به کار هستند (و ویندوز به صورت توکار دارای یک چنین API ایی هست). این مساله در سمت کلاینت، سبب خواهد شد تا ترد UI آزاد شود و بتواند به درخواستهای رسیده کاربر بهتر پاسخ دهد. همچنین این مساله در سمت سرور نیز بسیار مفید است، زیرا برنامه قادر خواهد شد تا به تعداد بیشتری از درخواستها به صورت همزمان پاسخ دهد. زیرا با کاهش تعداد تردهای درگیر، مقیاس پذیری سیستم افزایش مییابد.
زمانیکه از یک API غیرهمزمان برای مدیریت چنین عملیاتی استفاده میشود، ترد جاری را در این حالت در خواب فرو میبرد. برای اینکه کار بیشتری برای انجام وجود ندارد. همچنین با اینکه کلاینت درخواستی را ارسال میکند یا پاسخی را دریافت، برای مدیریت کل عملیات در اکثر اوقات نیازی به تردها ندارد. این سخت افزار شبکهی نصب شده در سیستم است که عمدهی کار را انجام میدهد و نه برنامه. زمانیکه برنامه درخواست ارسال اطلاعاتی را بر روی شبکه ارائه میدهد، درایور سخت افزار شبکه است که به سخت افزار مرتبط فرمان میدهد چه اطلاعاتی را باید ارسال کند. اکثر اینگونه سخت افزارها قادرند اطلاعات را خارج از حافظهی اصلی سیستم دریافت کنند. در اینجا درایور تنها باید به سخت افزار عنوان کند، چه اطلاعاتی را و به کجا باید ارسال کند. بنابراین CPU تنها در طی ارسال این فرمان است که مشغول میباشد و نه خارج از آن و این زمان اصلا در مقایسه با زمان ارسال اطلاعات توسط سخت افزار مرتبط، طولانی نیست. CPU مجددا زمانی درگیر خواهد شد که سخت افزار شبکه، اطلاعاتی را دریافت کرده است و باز هم این زمان در مقایسه با زمان دریافت اطلاعات توسط سخت افزار شبکه بسیار کوتاه است.
اغلب کارهای IO به همین شکل هستند. شبیه به همین روند در حالت دسترسی به سخت دیسک وجود دارد. مدت زمانیکه CPU به دیسک کنترلر اعلام میکند چه اطلاعاتی را نیاز دارد در مقایسه با مدت زمانیکه دیسک کنترلر این اطلاعات را واقعا بارگذاری میکند، بسیار ناچیز است.
نمونهی دیگر آن کار با بانکهای اطلاعاتی است. در اغلب اوقات برنامهی ما صرفا یک درخواست را به بانک اطلاعاتی ارائه میدهد و اصل عملیات در جایی دیگر و توسط موتور بانک اطلاعاتی، خارج از برنامه پردازش میگردد.
بنابراین جهت پردازش یک پروسهی خاص، در بسیاری از مراحل آن تنها یک ترد کافی است و هدف اصلی اعمال غیرهمزمان، کاهش تعداد تردهایی است که برنامه جهت پردازش عملیاتی خاص، نیاز دارد. این نوع الگوریتمها طوری طراحی شدهاند تا تردها تنها زمانی بکار گرفته شود که واقعا CPU قرار است کار خاصی را انجام دهد و نه برای مثال زمانیکه دیسک کنترلر یا سخت افزار شبکه مشغول به کار هستند (و ویندوز به صورت توکار دارای یک چنین API ایی هست). این مساله در سمت کلاینت، سبب خواهد شد تا ترد UI آزاد شود و بتواند به درخواستهای رسیده کاربر بهتر پاسخ دهد. همچنین این مساله در سمت سرور نیز بسیار مفید است، زیرا برنامه قادر خواهد شد تا به تعداد بیشتری از درخواستها به صورت همزمان پاسخ دهد. زیرا با کاهش تعداد تردهای درگیر، مقیاس پذیری سیستم افزایش مییابد.
با کمک امکانات ارائه شده توسط LINQ ، میتوان بسیاری از اعمال برنامه نویسی را در حجمی کمتر، خواناتر و در نتیجه با قابلیت نگهداری بهتر، انجام داد که تعدادی از آنها را در ادامه مرور خواهیم کرد.
الف) تهیه یک یک رشته، حاوی عناصر یک آرایه، جدا شده با کاما.
using System.Linq;
public class CLinq
{
public static string GetCommaSeparatedListNormal(string[] data)
{
string items = string.Empty;
foreach (var item in data)
{
items += item + ", ";
}
return items.Remove(items.Length - 2, 1).Trim();
}
public static string GetCommaSeparatedList(string[] data)
{
return data.Aggregate((s1, s2) => s1 + ", " + s2);
}
}
ب) پیدا کردن تعداد عناصر یک آرایه حاوی مقداری مشخص
برای مثال آرایه زیر را در نظر بگیرید:
var names = new[] { "name1", "name2", "name3", "name4", "name5", "name6", "name7" };
در تابع GetCountNormal زیر، این کار به شکلی متداول انجام شده و در GetCount از LINQ Count extension method کمک گرفته شده است.
using System.Linq;
public class CLinq
{
public static int GetCountNormal()
{
var names = new[] { "name1", "name2", "name3", "name4", "name5", "name6", "name7" };
var count = 0;
foreach (var name in names)
{
if (name.Contains("name"))
count += 1;
}
return count;
}
public static int GetCount()
{
var names = new[] { "name1", "name2", "name3", "name4", "name5", "name6", "name7" };
return names.Count(name => name.Contains("name"));
}
}
ج) دریافت لیستی از عناصر شروع شده با یک عبارت
در اینجا نیز دو روش متداول و استفاده از LINQ بررسی شده است.
using System.Linq;
using System.Collections.Generic;
public class CLinq
{
public static List<string> GetListNormal()
{
List<string> sampleList = new List<string>() { "A1", "A2", "P1", "P10", "B1", "B@", "J30", "P12" };
List<string> result = new List<string>();
foreach (var item in sampleList)
{
if (item.StartsWith("P"))
result.Add(item);
}
return result;
}
public static List<string> GetList()
{
List<string> sampleList = new List<string>() { "A1", "A2", "P1", "P10", "B1", "B@", "J30", "P12" };
return sampleList.Where(x => x.StartsWith("P")).ToList();
}
}
و در حالت کلی، اکثر حلقههای foreach متداول را میتوان با نمونههای خواناتر کوئریهای LINQ معادل، جایگزین کرد.
با سلام
ما مطابق آموزشی که در این مقاله داده شده از یک اکشن متد برای ذخیره عکس ارسالی تو یک پوشه و سپس برگشت دادن مسیر عکس و از یک اکشن متد دیگه برای ذخیره اطلاعاتی که قراره همراه با فرم ارسال بشن (به همراه مسیر عکس برگشت داده شده)، استفاده میکنیم
مشکلی که ما موقع استفاده از این افزونه باهاش برخوردیم اینه که گاهی اوقات و همونطور که انتظار میره اکشن متد (AddAvatars) که وظیفه ذخیره عکس رو داره اول اجرا میشه و اکشن متد (Add) که وظیفه ذخیره اطلاعات رو داره دوم، ولی گاهی اوقات این ترتیب به هم میریزه و ابتدا اطلاعات ارسالی ذخیره میشه و بعد اکشن متد ذخیره عکس اجرا میشه.
سناریوی ما هم تا حدی شبیه به سناریویی هست که آقای احمدی مطرح کردند، ولی همونطور که گفتیم مشکل اصلی اینه که اکشن متدها هر بار با ترتیبهای متفاوت فراخوانی میشن
ما مطابق آموزشی که در این مقاله داده شده از یک اکشن متد برای ذخیره عکس ارسالی تو یک پوشه و سپس برگشت دادن مسیر عکس و از یک اکشن متد دیگه برای ذخیره اطلاعاتی که قراره همراه با فرم ارسال بشن (به همراه مسیر عکس برگشت داده شده)، استفاده میکنیم
مشکلی که ما موقع استفاده از این افزونه باهاش برخوردیم اینه که گاهی اوقات و همونطور که انتظار میره اکشن متد (AddAvatars) که وظیفه ذخیره عکس رو داره اول اجرا میشه و اکشن متد (Add) که وظیفه ذخیره اطلاعات رو داره دوم، ولی گاهی اوقات این ترتیب به هم میریزه و ابتدا اطلاعات ارسالی ذخیره میشه و بعد اکشن متد ذخیره عکس اجرا میشه.
سناریوی ما هم تا حدی شبیه به سناریویی هست که آقای احمدی مطرح کردند، ولی همونطور که گفتیم مشکل اصلی اینه که اکشن متدها هر بار با ترتیبهای متفاوت فراخوانی میشن
<div class="container-fluid"> @using (Ajax.BeginForm("Add", "Authors", new AjaxOptions { UpdateTargetId = "result", InsertionMode = InsertionMode.Replace, HttpMethod = "POST" }, new { @class = "form-horizontal", id = "UploadFile" })) { @Html.AntiForgeryToken() <div class="control-group"> <label class="control-label" for="AuhtorFirstNameAndLastName">نام نویسنده</label> <div class="controls"> @Html.TextBoxFor(author => author.AuhtorFirstNameAndLastName, new { placeholder = "نام نویسنده" }) </div> @Html.ValidationMessageFor(author => author.AuhtorFirstNameAndLastName) </div> <div class="control-group"> <label class="control-label" for="Status">ارسال عکس</label> <div class="controls"> <input type="file" name="avatarFile" id="avatarFile" /> </div> <div> @*<input type="submit" name="btn-submit" value="ارسال" class="btn btn-success" />*@ <img id="loading" alt="1" src="Images/loading83.gif" style="display: none;" /> </div> </div> <div id="result"></div> <input type="submit" name="btn-submit" value="افزودن نویسنده" class="btn btn-success" /> <input type="button" name="btn-colose" id="btn-close" value="انصراف" class="btn btn-danger" onclick="$dialog.dialog('close');" /> } </div> <script type="text/javascript"> $('#UploadFile').submit(function () { $("#loading").show(); $.ajaxFileUpload({ url: "@Url.Action("AddAvatar","Authors")", secureuri: false, fileElementId: 'avatarFile', dataType: 'json', data: {}, success: function (data, status) { $("#loading").hide(); }, error: function (data, status, e) { $("#loading").hide(); } }); }); </script>