بررسی سیر تحولات Javascript ، ظهور JQuery ، هماهنگی مثال زدنی JQuery با MVC و حمایت از AJAX - قسمت اول

بعد از گذشت زمان نسبتا طولانی از نوشتن آخرین مطالبی که هر از گاهی در وبلاگ یا فیسبوک نوشته میشد ، مدتها بود موضوع روند تکامل Form ها در HTML از زمان به کار گیری Javascript به عنوان ابزاری برای کنترل "صحت مقدار یا فرمت مقادیر" ، تا زمان حاضر که شاهد یک همکاری و هارمونی بسیار شگفت انگیز بین JQuery و MVC هستیم ، بخشی از ذهن مرا به خود مشغول ساخته بود.
مخصوصا دغدغه مرور مختصری بر مفهوم و کاربرد FORM در MVC و ارتباط آن با مفاهیم بسیار مهم تری به نام AJAX و Partial View ابعاد این موضوع را تا حد نسبتا غیر قابل کنترلی (حداقل از دیدگاه من) افزایش می داد .
به عبارت ساده تر به نظرم رسید حتی یک معرفی سطحی و اجمالی بر موضوعات مذکور ممکن است بسیار فراتر از مجال محدودی باشد که در اختیار من قرار دارد. مجموعه عناوین و مفاهیمی که ذکر شد بسیار گسترده ولی انصافا بسیار مهم و ظریف بوده و حاوی نکاتی هستند که یقین دارم تحقیق در مورد آنها ابعاد تازه و جالب تری را به این مجموعه اضافه خواهد نمود . 
اگر به روزهای ابتدایی HTML و در واقع زمان معرفی اولین Browser یا مرورگر مخصوص وب با نام Mozaic در سال 1993 برگردیم ، بنا بر مستندات مستدل موجود این مرور گر که در واقع جد همه مرورگرهای مدرن امروزی محسوب میشود ، قابلیت برقراری یک ارتباط محاوره ای با User را با استفاده از تگ Form برای کاربر فراهم می کرده است . 
در واقع یک سال بعد یعنی در سال 1994 وب که حالا تقریبا 4 ساله شده بود توجه بسیاری از بازیگران عصر طلایی صنعت IT را به خود جلب کرد و در سپتامبر همان سال Internet Engineering Task Force با نام اختصاری IETF که متولی ، ناشر و حامی غیر انتفاعی استانداردهای اینترنت بود، کار گروه ویژه ای را برای تدوین و انتشار استانداردهای HTML منسوب کرد. از اعضای مهم این گروه می توان به Tim Berners-Lee (مخترع وب) ، Don Connelly و Mark Anderson اشاره کرد که حاصل این اقدام انتشار استاندارد HTML 2 و تهیه Document Type Definition مربوط به این استاندارد بود .
جالب است بدانیم که Netscape Navigator که به عنوان اولین مرورگر تجاری موفق در سیلیکون ولی تدوین و منتشر شد حاصل کار گروهی Mark Anderson و Jim Clark بود. همانطور که قبلا هم اشاره شد، از همان ابتدا عنصر Form یکی از اصلی ترین و پر کاربرد ترین عناصر و یا Element های HTML محسوب میشد و با توجه به محدودیت های پهنای باند و بنا بر ویژگیها و محدودیت هایی که پروتکل HTTP بر وب تحمیل می کرد ، تا قبل از 1995 موضوع بررسی یا کنترل صحت مقادیر و اطلاعات Form که به نام Form Validation شناخته می شود منحصرا صرفا با یک Round Trip (اشاره به Post Back و Initiate و آغاز Request از سوی مرورگر ، پردازش Request در Server و ایجاد Response ) میسر بود . به عبارت ساده تر ، امکان انجام این کنترل صرفا در Server و با استفاده از زبانهایی مثل PERL وجود داشت که با توجه به سرعت مودم های 28.8 kbps ، نیاز به زمان قابل توجهی داشت . اولین بار Brenden Eich که از مهندسین ارشد Netscape بود به فکر انجام این کنترل، تمام با استفاده از یک زبان اسکریپت افتاد و این انگیزه سبب طراحی زبان اسکریپتی گردید که ابتدا Mocha و در فاصله کوتاهی LiveScript نامیده شد. قبل از تولید نسخه تجاری Netscape Navigator 2 در سال 1995 بازیگر مطرحی در عرصه تکنولوژی مثل Sun Microsystem در تکمیل طراحی LiveScript پا به عرصه وجود گذاشت و نتیجه این همکاری تولد زبان JavaScript بود که با یک تاخیر زمانی کوتاه به Netscape Navigator 3 ملحق شد و از آن موقع تا زمان حاضر چنانچه همه ما مطلع هستیم، به عنوان یکی از ملزومات اصلی مروگرها شناخته می شود. 
اما در این میان همه چیز آن چنان که انتظار میرفت پیش نرفت . چرا که Microsoft به سرعت شروع به تدوین مرورگر اختصاصی و معلوم الحال خود نمود که علاوه بر داغ تر کردن تنور رقابت بازار مروگرها، به دلیل پرهیز از مشکلات ناشی از ثبت انحصاری Javascript نسخه انحصاری خود از زبان اسکریپتی اختصاصی خود به نام Jscript را ضمیمه مرورگر خود کرد و روانه بازار نمود . این موضوع در واقع مبدأ آشفته بازاری بود که انگیزه نیاز به یک استاندارد جامع در زبانهای اسکریپت را تقویت نمود و در نهایت منجر به تدوین ECMAScript ( به صورت رایجی ، اکما - اسکریپت تلفظ می شود) به عنوان استاندارد پایه و مبنای زبانهای اسکریپت شد . 
نکته مهم:
از آنجاییکه JQuery و نقش آن در DOM Processing و Form Validation و Form Submission و نهایتا AJAX بسیار حائز اهمیت است، لاجرم لازم می دانم که که در این مقاله ، هر چند به اجمال، این مباحث بیشتر بررسی شده تا احیانا برخی از ابهامات موجود در این زمینه برطرف گردد .

با در نظر گرفتن مطالبی که عنوان شد از اینجا به بعد در واقع Javascript بر خلاف یک تلقی اشتباه (که برخی آن را مترادف با ECMAScript قلمداد می کنند) یک پیاده سازی از استاندارد از ECMAScript است و در حقیقت شامل اجزای زیر می باشد :
1- هسته و Core مربوط به ECMAScript .
2- Document Object Model یا به اختصار DOM
3- پشتیبانی از Browser Object Model یا به اختصار BOM

به منظور درک عمیقتر ECMAScript اولا باید آن را مستقل از Web در نظر گرفت. در واقع مرورگرهای وب یک میزبان برای هسته اصلی ECMAScript می باشند که امکان پیاده سازی سطوح بالاتر ، بر مبنای امکانات پایه ای که فراهم می کند را ، میسر می سازند . مواردی نظیر نحو یا Syntax ، امکان تعریف Type ، کلید واژه ها، اپراتور ها ، مفهوم Object و ... در JavaScript همه به لطف پیاده سازی سطوح پایین تر در ECMAScript ایجاد و بنا بر نیاز موجود تقویت و بهینه شده اند . با مراجعه به منابع معتبر می توان بوضوح مشاهده کرد که ECMAScript در طول حیات خود و با گذشت زمان و قطعا متناسب با نیازهای موجود ، دارای هسته ای به مراتب مجهز تر شده است که به نظرم در اینجا مجال پرداختن به جزییات آن وجود ندارد و علاقمندان می توانند با مراجعه به منابع معتبر جزییات دقیق تر این تکامل تدریجی ECMAScript را مطالعه کرده و در جریان کامل آن قرار بگیرند . در این زمینه، پشتیبانی از دستورات try catch ، پشتیبانی دقیق تر از کلاسها و مفهوم Inheritance و وراثت ، پشتیبانی و پیاده سازی JSON به عنوان فرمتی برای تبادل Object ها و اطلاعات و .... از مهمترین مواردی بودند که به تدریج در چرخه تکامل ECMAScript نقش آفرینی کرده اند .
مفهوم Document Object Model یا DOM
این مفهوم در اصل عبارت است از یک API خاص منظوره برای کار با فرمت XML که بعدها به منظور کار با HTML تقویت ، ویرایش و یا گسترش یافته است . 
در مقطعی از زمان مرورگرهای اختصاصی Netscape و Microsoft هر یک روایت اختصاصی خود از DHTML را که لزوما با یکدیگر سازگار نبوده و حتی تضادهایی هم داشت، ارائه نموده و این موضوع یکی از عوامل اصلی نیاز به یک استاندارد فراگیر را مطرح کرد که موجب شد World Wide Web Consortium یا W3C تدوین استانداردهای DOM را در دستور کار خود قرار دهد .
از دیدگاه DOM یک سند XML یا HTML (در واقع HTML یک زیر مجموعه از XML محسوب می شود) صرفا دارای مجموعه ای از اجزا یا المانها یا Node هایی است که به صورت سلسله مراتبی (Hierarchical) ، به ترتیبی قرار دارند که اولا همه اجزا (یا همان المانها و Node ها) منشعب از یک Node ویژه به عنوان Root و ریشه بوده و ثانیا هر Node می تواند از نظر محتوا شامل یک یا چند Node فرزند (یا هیچ) بوده و از نظر نوع می تواند شامل انواع متفاوتی از اطلاعات یا Data باشد .
اتخاذ این استراتژی، API را قادر می سازد تا عملیاتی نظیر پیمایش (Traverse) ، افزودن (Add) ، حذف (Remove) ، الحاق (Append) و ... را به صورت بسیار موثر و کارآمدی را انجام دهد . 
اصطلاحات DOM Level 1 ، DOM Level 2 و DOM Level 3 اشاره به روایت های متعددی است که از سال 1998 تا امروز استانداردهای DOM را بر حسب شرایط روز تدوین و منتشر نموده است . در حقیقت مواردی مثل حمایت از Device هایی همچون Mouse ، الحاق و پشتیبانی Css و در ادامه تجهیز و گسترش Event ها و الحاق استاندارد XPath همه و همه از مواردی بودند که به مرور زمان در DOM ایجاد شده و منتشر شدند . 
در حال حاضر به لطف Library های مشهور و کاربردی و در صدر آنها JQuery حمایت و قابلیت کار با DOM تا بالاترین سطح خود در مرورگرها گسترش پیدا کرده و در ادامه و مخصوصا در مباحث مربوط به AJAX مثالهای کاربردی تری از آن را ملاحظه خواهیم کرد .
در واقع به نظرم تا اینجا خواننده این سطور باید به این نکته مهم توجه داشته باشد که JavaScript و JQuery (به عنوان یک کتابخانه کاربردی بنا شده بر اساس Javascript) چگونه در طول زمان بر اساس نیازهای موجود از یک ابزار اسکریپت نویسی ساده به منظور کنترل Form Validation و Dom Traversal (اشاره به قابلیت های آن در ارتباط با پیمایش ، حذف، الحاق و ... Node ها در ساختار سلسله مراتبی DOM) به یک جزء لاینفک از Platform های وب مخصوصا ASP .NET MVC تبدیل شد .
مفهوم Browser Object Model یا BOM
چنانچه پیشتر نیز اشاره شد، اولین و مهمترین ویژگی Javascript پشتیبانی کامل از ECMAScript و DOM و BOM می باشد . به طور دقیق تر مفهوم BOM اشاره به مجموعه ای از امکاناتی بود که همزمان با Netscape Navigator 3 و Internet Explorer 3 در این دو مرورگر ایجاد شد که امکان کار با Window یا پنجره میزبان مرورگر و همچنین استفاده از Dialog های Modalو Modeless را فراهم نمودند . به طور مشخص تمرکز BOM در کار با خود Object پنجره میزبان (Window) و Frame های این پنجره قرار داشت و به طور کلی شامل امکاناتی برای کار با سایر پنجره های Popup ، امکان قابلیت حرکت، تغییر اندازه و بستن پنجره ها و امکان کار با Object های کاربردی navigatorو location و Screen و از همه مهمتر (و در بحث ما با تمرکز بیشتر) تولد XMLHttpRequest به عنوان محور اصلی ظهور تکنولوژی AJAX و گسترش آن بود .

پروژه نمونه بررسی قابلیتهای Google MAP API و تلفیق آن با MVC

پروژه نمونه بررسی قابلیتهای Google MAP API و تلفیق آن با MVC

     در این پروژه مشخصا امکان استفاده از Google Map API در MVC بهانه ای برای کسب تجربه بیشتر و استفاده از تکنیک های این تکنولوژی در سناریو های مرتبط با GIS می باشد .
در مرحله اول به هیچ وجه از Spatial Data و مخصوصا امکانات استثنایی SQL در محاسبات GIS استفاده نشده و هر آنچه در این پروژه ساده استفاده شده فقط به کار گیری بخشی از تواناییهای مفاهیمی مثل Layout ، View و Partial View و تلفیق JQuery UI و بهره گیری از Google Javascript API V 3.0 و AJAX و JSON می باشد .
به دلیل حفظ ساختار اصلی Template پروژه استاندارد، ابتدا یک Layout مستقل به نام _AppLayout.cshtml ایجاد شده که در فولدر View/Shared قرار گرفته است .
این Layout دارای یک ساختار ساده 2 ستونی Right To Left می باشد که پنل سمت راست در واقع یک Div استاندارد با float متمایل به راست می باشد که اندازه طول (Width) آن 156 پیکسل در نظر گرفته شده است .
پنل سمت راست به طور مشابه دارای یک float متمایل به چپ بوده که به دلیل حفظ فاصله مناسب از سمت راست (Padding-right) دارای طولی (Width) به اندازه 170 پیکسل می باشد .
پنل های Header و Footer هم به سادگی در Layout قرار دارند .
پنل سمت راست در Layout به صورت یک Section ایجاد شده است که وظیفه Rendering و محتویات آن به صورت اختیاری :
 

<div id="rightPanel" >
     @RenderSection("RightPanel", required: false)
</div>

در View میهمان (منظور آن View که از Layout استفاده میکند) تامین میشود که این وظیفه را index.cshtml انجام داده است . برای تامین محتویات پنل سمت راست index.cshtml از یک Partial View ساده به نام _PartialRightMapMenu استفاده کرده است که هدف از این کار (Reusable Controls) استفاده مستقل از این Partial View در بخشهای مختلف برنامه بوده است .
این Partial View شامل یک کنترل استاندارد Accordion در JQuery می باشد که از آن به عنوان منوی اصلی برنامه استفاده شده است . گزینه های هر Category از منو به سادگی با یک Button معمولی ایجاد شده اند .
به دلیل بهره گیری از امکانات آخرین نسخه JQuery من تصمیم گرفتم که از نسخه 1.10.2 که در زمان تهیه این برنامه آخرین نسخه آن بوده است استفاده کنم . رفرنس به اسکریپت های مورد نیاز از طریق تکنیک Bundle در MVC انجام شده است که جزییات آن در فایل BundleConfig قابل مشاهده است .
همچنین برای استفاده از Google API درج یک رفرنس به کتابخانه اسکریپت توابع گوگل الزامیست که این کار در داخل index.cshtml انجام شده که این View، نقش میزبان اصلی سناریو های مرتبط با نقشه را بازی میکند .
علاوه بر رفرنس به کتابخانه اصلی اسکریپت های Javascript در Google به دلیل استفاده از سرویس ها و نقشه های وضعیت آب و هوا رفرنس دومی هم به اسکریپت مورد نیاز در همان محل قرار داده شده است .
همچنین کلیه توابع مورد نیاز ما در JQuery و Javascript به طور مستقل در فایل mvcgoogle.js و در فولدر Scripts قرار داده شده است . تقریبا همه عملیات برنامه از داخل این فایل کنترل شده و Event های مربوط به انتخاب گزینه های سمت راست از طریق این فایل Handle می شوند . برای استفاده از این فایل مجددا در BundleConfig.cs آن را به همراه سایر اسکریپت های مورد نیاز برنامه Bundle و بسته بندی کرده ام و در index.cshtml یک رفرنس برای آن در نظر گرفته ام.
در داخل این فایل از استراتژی استفاده از یک متغیر map سراسری و Global استفاده شده است . با توجه به پیش بینی حداقل 30 گزینه در منوی سمت راست و پرهیز از پاسکاری خسته کننده آبجکت map بین توابع فعلا این راهکار مورد استفاده قرار گرفته شده است . مگر آنکه در آینده و در گسترش های بعدی تغییراتی در آن ایجاد گردد .
در اولین نسخه و اولین ارائه این برنامه تعداد 13 سناریوی مختلف بررسی و پیاده سازی شده است که متناسب با هریک از آنها، یک گزینه در منوی سمت راست تدارک دیده شده است . از همان ابتدای فکر طراحی و اجرای این برنامه در نظر داشتم که تنوع زیادی در تکنیک های مرتبط با نقشه استفاده کنم .
مثالها از نمایش یک نقشه ساده شروع شده و انتخاب یک نقطه خاص (در این مثال برج میلاد) و در ادامه امکان ترسیم دلخواه (Custom Style Rendering) در نقشه ها نشان داده شده است . همچنین در گزینه weather استفاده از سرویس وضعیت آب و هوایی و رندر کردن آن روی نقشه توسط Google API نشان داده شده است . همچنین در گزینه "ماهواره – کلیک" نقشه گوگل به صورت Hybrid ترسیم شده است و با هر کلیک بر روی نقشه مختصات محل کلیک شده در نوار Footer انتهای برنامه منعکس خواهد شد . در مجموع جزییات دیگری هم در هر یک از مثالها وجود دارد که توصیه میکنم در هنگام اجرا با دقت به نوع عملیاتی که انجام میشود توجه نمایید .
در این برنامه نمونه و البته ساده، به نظر من یک چارچوب مناسب برای گسترش های آینده ایجاد شده و زمینه برای انجام سناریو های بسیار پیچیده تر نظیر استفاده از داده های جغرافیایی (Sql Spatial Data) در SQL و بهره گیری از معماری SOA با استفاده از WCF مهیا شده است . در Category نام گذاری شده با فرمت KML اختصاصا امکان استفاده از فرمت بسیار مهم KML در Google بررسی شده است . در این باره مطالب زیادی وجود دارد که من توضیح مفصل تر در این مورد را به آینده موکول میکنم و فقط لازم است اشاره کنم که هر 4 گزینه این قسمت اطلاعات خود را از سایت http://earthquake.usgs.gov/ دریافت میکنند که اطلاعات بسیار به روز و طبقه بندی شده را در ارتباط با آمار آخرین زلزله ها حداقل در دو فرمت JSON و KML ارائه میدهد . امکان استفاده از فرمت KML در Google یکی از مزایای استثنایی این API محسوب شده و امکانات موجود در این زمینه بسیار متنوع و جالب می باشند .
تنها محدودیت در این زمینه این است که فایلهای KML باید در یک Domain مستقل و Online قرار داشته باشند و امکان استفاده از فایلها به صورت local وجود ندارد .
تکته بسیار مهمی که باید برای استفاده از این پروژه در نظر داشته باشیداین است که حتما مشخصات ConnectionString را در web.config مطابق با وضعیت سیستم خود تغییر داده و اقدام به استفاده از برنامه نمایید .
در Category سوم استفاده از اطلاعات Dynamic مورد توجه قرار گرفته شده است . برای این کار من یک Database نمونه به نام DBGisSample و به صورت Backup ضمیمه برنامه کرده ام که با SQL Server Express 2012 ایجاد شده و در حال حاضر شامل دو جدول مستقل است . یکی از جدول ها دارای چند رکورد مرتبط با مختصات شهرهای مهم ایران است . دومین جدول مجددا مربوط به اطلاعات زلزله ها ی شدید به تفکیک سال و شدت و زمان آنها می بالشد که فقط توجه به یک نکته بسیار مهم در اینجا ضروریست .
در این جداول به هیچ وجه از امکانات Spatial Data و به طور مشخص نوع داده های Geometry و Geography در Sql استفاده نشده است . هر چند جدول earthquake دارای چنین اطلاعاتی می باشد اما اگر با دقت به هر دو Table نگاه کنیم ، هر کدام از ایk جداول دارای دو ستون مستقل به ترتیب برای طول و عرض جغرافیایی هستند که برنامه ما ابتدا با استفاده از EF اطلاعات این جداول را دریافت کرده و سپس Controller مورد نظر ما به نام Home در MVC آبجکت های موجود در Model را با توجه به اطلاعات دریافت شده از SQL ایجاد کرده و یک لیست Generic از این اطلاعات در فرمت JSON توسط Action ها Serialize شده و دو فراخوانی مستقل و جداگانه از متد $.getJSON در داخل mcvgoogle.js بدون نیاز به Postback و توسط Ajax اطلاعات مورد نیاز ما را به View مورد نظر ما یعنی index منتقل میکند .
بعد از این کار، فراخوانی متدهای مرتبط و مورد نیاز در Google API عملیات ترسیم و Rendering نقاط را انجام داده و هر نقطه دارای یک Tooltip اختصاصی است که سایر اطلاعات و فیلدهای هر رکورد را به این ترتیب نمایش میدهد . بعد ها از infoWindow در Google API برای همین کار استفاده خواهیم کرد که بسیار روش مناسب تری می باشد .
همچنین باید اشاره کنم که در گزینه دوم مربوط به این قسمت، هر چند کار انجام شده بسیار شبیه به گزینه اول می باشد اما تفاوت اندکی وجود دارد :

اولین نکته این است که در گزینه دوم متد Action مورد نظر یعنی SQLEarthQuake دو پارامتر دریافت میکند که من از آن برای محدود کردن تعداد رکورد های دریافتی استفاده کرده ام . در جدول Earthquakes در حدود 5351 رکورد مختلف وجود دارد که متد Action ما با ایجاد یک فیلتر ساده فقط رکورد های مربوط به سال 1960 تا 2013 را دریافت میکند که تعداد رکورد ها تقریبا به نصف کاهش می یابد . پس این Action اولا امکان انتقال پارامتر به متد Action را نشان داده ثانیا بوضوح نشان میدهد که این روش از چه کارآیی و قدرت بالایی برخوردار است که حدود 2500 رکورد را در زمان بسیار کوتاهی بدون Postback دریافت کرده و Google Api به محض دریافت آنها، به ازای هر نقطه یک Pushpin روی نقشه ترسیم میکند .

جزییات انجام این عملیات همه در mvcgoogle.js قابل مطالعه است .
به نظرم می رسد که جزییات زیادی برای مطرح شدن وجود دارد که فعلا به دلیل کوتاه شدن این مطلب از آنها پرهیز میکنم .

لینک دریافت سورس کد پروژه به همراه SQL Data Backup :
https://onedrive.live.com/redir?resid=FC40347DCF4AAF1D%211252

امیدوارم از نظرات و پیشنهادات خود مرا مطلع نمایید .

گزارش یک تجربـه در MVC

ماجرا از آنجایی آغاز شد که در نظر داشتم سناریویی که در برنامه RouthingDemo قبلا در Windows 8 Store App انجام شده بود را در MVC بازسازی کرده و علاوه بر فرمت GPX ، امکان استفاده از API مشخصی که آن را به منظور کار با Shape File ها و Platform Independent طراحی کرده بودم استفاده کنم. کد کامل این API را در اولین فرصت به همراه توضیحات لازم ارائه خواهم کرد .
 در مجموع هدف من Rendering اطلاعات فرمت های اصلی File-based در GIS یعنی KML ، Shape و Gpx حداقل بر روی سه Base Map متفاوت یعنی استفاده از Provider های Bing Map و Google Map و OpenStreet Map می باشد .
تقریبا هر سه Provider مجهز به API های اختصاصی خود هستند که به طور مشترک در Client-side قابل استفاده بوده و امکان Render نمودن یک Base Map و در ادامه امکان ترسیم Geometry های اصلی در GIS یعنی Point ، Line و Polygon را فراهم نموده و عملیات رایجی مثل Panning و Zooming را میسر میسازند .
در سناریوی نهایی به نظرم رسید که خلاص شدن از شر فرمت های File-based تنها در صورت وجود یک Converter و انتقال اطلاعات موجود در آنها به SQL  در قالب Spatial Data بهترین راهکار موجود است که قبل از پرداختن به جزییات موجود در این راه  اولین نکته روش برقراری ارتباط بین MVC (در دیدگاه کلی Server-side)  و JQuery (اشاره به امکان استفاده از API هر یک از Provider های نقشه )  می باشد که در اینجا گزارشی از تجربه موفقیت آمیزی که با استفاده از AJAX و فرمت JSON  داشته ام ، ارائه شده است .

کلاسی که در زیر ایجاد شده تقریبا منطبق بر اطلاعات موجود در فرمت GPX می باشد .
 

    public class GISRoute

    {

        public GISRoute()

        {

        }

        public double Longitude

        {

            get;

            set;

        }

        public double Latitude

        {

            get;

            set;

        }

        public int Altitude

        {

            get;

            set;

        }

        public DateTime TimePoint

        {

            get;

            set;

        }

 

    }
 

در ادامه کلاس دسترسی به فرمت فایلهای GPX و Encapsulation اطلاعات آن در کلاس GISRoute ایجاد کردم که چندان بهینه نیست اما در ساده ترین شکل خود با ایجاد یک لیست جنریک از کلاس GISRoute اطلاعات موجود در فرمت GPX را در کد زیر، با استفاده از LINQ To XML در لیست Gerneric قرار داده و لیست مذکور جهت استفاده در Controller آماده میشود :

    public class GPXReader

    {

        List<GISRoute> gisrouteList;

        public GPXReader()

        {

            Test tst = new Test();

            gisrouteList = new List<GISRoute>();

            LoadGPXFile();

        }

        public GPXReader(string path)

        {

        }

        public List<GISRoute> GisRouteList

        {

            get

            {

                return this.gisrouteList;

            }

        }

        public void LoadGPXFile()

        {

 

            XDocument xmlFile = XDocument.Load(".....\\Projects\\MvcMap\\MvcMap\\App_Data\\sample.gpx");

            XNamespace xns = "http://www.topografix.com/GPX/1/0/";

            foreach (var element in xmlFile.Root.Elements("trkpt"))

            {

                double lat = double.Parse(element.FirstAttribute.Value);

                double lon = double.Parse(element.LastAttribute.Value);

                int alt = Int32.Parse(element.Element("ele").Value);

                DateTime time = DateTime.Parse(element.Element("time").Value);

                string str = element.Value;

                gisrouteList.Add(new GISRoute

                {

                    Altitude = alt,

                    Latitude = lat,

                    Longitude = lon,

                    TimePoint = time

                });

            }       

        }

    }

 

اینک Controller صرفا با Instantiate کردن کلاس GPXReader می تواند به محض دریافت یک Request از نوع Get ،اطلاعات موجود در یک مسیر ثبت شده در فرمت GPX را در فرمت JSON به صورت اتوماتیک Serialize کرده و آن را به یک View دلخواه (حتی نوع Strongly Typed View)   هدایت نماید .
برای ساده تر شدن موضوع، من از همان View استاندارد Index.cshtml استفاده کردم. کد Action مورد نظر من با نام MyMethod به صورت زیر در کنترلر Home ایجاد شد .

 

  public class HomeController : Controller

    {

        public ActionResult Index()

        {

            ViewBag.Message = "Modify this template to jump-start your ASP.NET MVC application.";

 

            return View();

        }

 

        public ActionResult About()

        {

            ViewBag.Message = "Your app description page.";

            GPXReader gpxReader = new GPXReader();

            return View(gpxReader.GisRouteList);

        }

 

        public ActionResult Contact()

        {

            ViewBag.Message = "Your contact page.";

 

            return View();

        }

        [HttpGet]

        public ActionResult MyMethod(int keyid, int newval)

        {           

GPXReader gpxReader = new GPXReader();

            ViewBag.Message = keyid.ToString() + " " + newval.ToString();

            return Json(new { smylist = gpxReader.GisRouteList },

                        JsonRequestBehavior.AllowGet);

        }

    }

 

چنانچه در کد بوضوح مشاهده میشود با استفاده از Annotation و درست در ابتدای متد، نوع درخواستی که متد MyMethod قادر به Handle کردن آن میباشد Get تعیین شده است . همچنین دو پارامتر موجود در این متد صرفا برای بررسی امکان ارسال پارامتر به این متد به کار رفته و در سناریوی فرضی من از این دو پارامتر استفاده نشده است . به عبارت ساده تر با استفاده از JQuery چنانچه در ادامه خواهیم دید امکان ارسال هر تعداد پارامتر مورد نیاز با هر نوع دلخواه به Action تعیین شده در یک Controller میسر خواهد بود که تواناییهای بالقوه این روش استثنایی را آشکار میکند .

برای آزمایش این روش ابتدا در View میزبان از چند المان HTML ساده به صورت زیر استفاده شده است :

 

        <div>

            <button id="btnStart"JSON Send</button>

            <div id="divReturnedData"> </div>

            <ol id="list">

            </ol>

        </div>

 

واضح است که از Button به عنوان یک Trigger برای آغاز این عملیات استفاده شده و برای نمایش خروجی حاصل از احضار متد می توان از divReturnedData و یا list استفاده کرد که جزییات این کار در ادامه شرح داده شده است .

در ادامه و در مرحله اول عملیات Client-side برای رویداد Click در  Button مورد نظر  مطابق زیر یک Event Handler مشخص می کنیم که در آن بوضوح مشخص شده است که به محض لود شدن کلیه عناصر DOM (با توجه به اینکه معمولا Script ما در Header قرار میگیرد و عناصر DOM و تگ های HTML در Body قرار دارند ، این یک روش مناسب و استاندارد  برای اطمینان از لود شدن کل المانهای DOM می باشد) فراخوانی متد GetJSONWithAjax به محض کلیک بر روی Button تعیین شده با btnStart انجام شود . کد متد GetJSONWithAjax در ادامه ارائه شده است .

 

   <script type="text/javascript">

       $(document).ready(function() {

           $("#btnStart").click(GetJSONWithAjax);

       });

    </script>

 

من در ابتدا با استفاده از متد $.ajax درخواستی از نوع Get به Action و Controller ارسال کرده ام که واضح است در آغاز این فراخوانی نوع درخواست get تعیین شده و فرمت اطلاعات دریافتی json تعیین شده است . همچنین ویژگی Caching در اینجا Disable شده و با استفاده از Helper بسیار مفید و کاربردی Url.Action و توسط Razor ابتدا نام Action یعنی MyMethod و سپس نام Controller یعنی Home تعیین شده است .
چنانچه قبلا اشاره شد متد ما در کنترلر دارای دو پارامتر است که با وجود اینکه ما از آن استفاده نکرده ایم اما برای نمایش امکان ارسال پارامتر به همراه Request مقادیر فرضی 1 و 10 را در پارامترها  مقدار دهی کرده و یک Handler از نوع Anonymous   (منظور function بدون نامی است که دارای یک پارامتر بوده و در حقیقت حاوی اطلاعات ارسال شده از Controller می باشد . به عبارت ساده تر ما از این function به به عنوان Callback در هنگام موفقیت آمیز بودن عملیات استفاده کرده ایم) تعیین کرده و در داخل این Callback (توضیح آنکه Callback اشاره به نوع خاصی از Function ها در عملیات Asynchronous می باشد که در مراحل مختلف این عملیات فراخوانی شده و امکان کنترل کامل در کل این فرآیند را میسر میسازند) ابتدا با دریافت تعداد عناصر لیست یا آرایه از صحت دریافت آنها مطمئن می شویم. هر چند در عمل نیازی هم به انجام این کار نیست و فراخوانی این Callback خود دلیل خوبی برای موفقیت آمیز بودن این عملیات است . از divReturnedData هم به عنوان یک Placeholder برای نمایش تعداد عناصر لیست/آرایه استفاده کرده ام . تردید من در استفاده از واژه لیست و یا  آرایه به این دلیل است که مجموعه ای که به عوان Data منتقل شده است در Controller به صورت یک لیست Generic تدارک دیده شده بود و اینجا آن را به صورت یک آرایه در JQuery دریافت کرده ایم .
به محض دریافت آرایه حالا JQuery دارای مجموعه ای از متد ها و توابع بسیار قدرتمند و کارآمدیست که انواع پردازش های دلخواه را بر روی عناصر آرایه فراهم میکند . این ابزارهای بی نظیر حتی بدون نیاز به یک loop سنتی می توانند کلیه نیازهای موجود در زمینه مرور و Traverse کردن عناصر آرایه و پردازش دلخواه بر روی تک تک اعضای آرایه را فراهم کنند . از مهمترین این توابع میتوان به each ، map و grep اشاره کرد که مخصوصا در مورد آخر با تلفیق با Regular Expression  یک ابزار فوق العاده کارآمد محسوب میشود . من با استفاده از متد each در JQuery کار را به ترتیبی که در کد ملاحظه میکنید ادامه داده ام . این متد در پارامتر اول ، خود آرایه را دریافت کرده و در پارامتر دوم امکان مشخص نمودن یک Callback ،  که به ازای هر عنصری از آرایه فراخوانی میشود را میسر می سازد . مجددا من از یک تابع Anonymous استفاده کرده ام و فقط یک Property در آرایه یعنی Longitude (برای توضیح به کد کلاس GISoute مراجعه نمایید) را در یک تگ Ordered List در HTML نمایش داده ام . توضیح اینکه متد append هر بار به تعداد اعضای آرایه یک node از نوع li به تگ OL اضافه میکند .
متد $.ajax چنانچه مشاهده میکنید امکان تعیین یک Callback در شرایطی که انجام عملیات به هر دلیلی با مشکلی مواجه شود را فراهم میکند .

 

 

           function GetJSONWithAjax() {

               $.ajax({

                   type: 'get',

                   dataType: 'json',

                   cache: false,

                   url: '@Url.Action("MyMethod","Home")',

  data: { keyid: 1, newval: 10 },

  success: function (response) {

      var arrayCount = response.mylist.length;

      var memlist = $("#list");

      $("#divReturnedData").html("<b>" + arrayCount + "</b>);

      $.each(response.mylist, function (index, value) {

          memlist.append($("<li>" + value.Longitude + "</li>"));

      });  },

  error: function (jqXHR, textStatus, errorThrown) {

      //alert('Error ' + errorThrown);

  }

        });

           }

 

با توجه به این نکته بسیار مهم که فرمت اطلاعات دریافت شده در اینجا از نوع JSON می باشد ، به نظر میرسد استفاده از متد $.getJSON نیز علاوه بر امکان رسیدن به نتیجه مشابه ، این کار را با تلاش کمتری میسر میسازد . برای استفاده از آن می توان از کد زیر استفاده کرد که توصیه میکنم به مشابهت های آن با روش قبلی و مزیت آن توجه نمایید .

 

    function GetJSON()

           {

        var params = { keyid: 1, newval: 10 };

        $.getJSON('@Url.Action("MyMethod","Home")',

            params,

            function (response) {

                  var arint = response.mylist.length;

                  var memlist = $("#list");

                  $("#divReturnedData").html(arint + " <b>" + response.mydata + "</b> " + response.oldval + " " + "<hr/> " + response.mylist[0].Longitude);

                  $.each(response.mylist,function( index, value ){

                                  memlist.append($( "<li>" + value.Longitude + "</li>" ));

                  });

        });

 

با توجه به توضیحاتی که قبلا داده شد به نظر میرسد هیچ نقطه مبهمی در این فراخوانی وجود ندارد .
با استفاده از Developer Tools در Google Chrome مطلع شدم که کل این درخواست و دریافت اطلاعات در مدت 550 میلی ثانیه انجام شده اما اگر با دقت به تصویری که ضمیمه شدهاستتوجه کنیم ملاحظه خواهیم کرد که ارسال اطلاعات و زمان مورد نیاز Response فقط 1.5 میلی ثانیه بوده است که برای حدود 1000 رکورد از نوع GISRoute زمان بسیار خوب و نشان دهنده سرعت بالای این روش می باشد . بر طبق گزارش Developer Tools سیستم به مدت 547 میلی ثانیه توقف داشته است که با بهینه سازی کد و روشها میتوان این مقدار را تا یک سوم مقدار فعلی کاهش داد .

 امیدوارم توضیح این تجربه، برای دوستان و همکاران محترم مفید بوده و این عزیزان از  نظرات و پیشنهادهای خود مرا بی نصیب نگذارند .