شیرپوینت فریم ورک یا همان SPFx ، متشکل از صفحات و وب پارتها می‌باشد که به صورت کامل امکان توسعه Client-side شیرپوینت را با استفاده از تسهیل در integration با داده‌های شیرپوینت و پشتیبانی از ابزارهای Open Source فراهم می‌سازد.
شیرپوینت فریم ورک یا همان SPFx ، متشکل از صفحات و وب پارتها می‌باشد که به صورت کامل امکان توسعه Client-side شیرپوینت را با استفاده از تسهیل در integration با داده‌های شیرپوینت و پشتیبانی از ابزارهای Open Source فراهم می‌سازد. با شیرپوینت فریم ورک امکان بهره‌مندی از تکنلوژیهای مدرن وب را خواهید داشت و امکان ایجاد Appها و Productهایی که از ابتدا به صورت Responsive (قابل استفاده در موبایل ، تبلت و ... ) می‌باشند را فراهم می‌سازد. شیرپوینت فریم ورک در Sharepoint Online و نسخه On-permisses ( برای Sharepoint 2016 Feature pack 2 به بعد) قابل استفاده می‌باشد.
ویژگیهای کلیدی شیرپوینت فریم ورک عبارتند از :
- شیرپوینت فریم ورک از Context یوزر جاری ( current user ) و یک کانکشن با browser استفاده می‌کند و دیگر مانند نسخه‌های قبل شیرپوینت از iFrame جهت Customization ( سفارشی سازی) استفاده نمی‌کند.
- کنترلها در DOM صفحه رندر (Render) می‌شوند
- کنترلها Responsive هستند و به صورت طبیعی قابل دسترسی هستند
- قابلیت دسترسی که در بالا اشاره شد developerها را قادر می‌سازد تا علاوه بر دسترسی به lifecycle کنترلها به render load, serialize و deserialize, configuration changes کنترلها دسترسی داشته باشند
- SPFx در واقع framework-agnostic است بدین معنی که شما می‌توانید از هر Javascript Framework ای مانند React , Handlebars , Knockout , Angular و ... در SPFx استفاده کنید.
- تمامی ابزارهای لازم برمبنای ابزارهای توسعه کلاینت ساید متن باز ( Open Source ) است نظیر npm ، TypeScript ، Yeoman ، Webpack و Gulp است
- کارایی آن قابل اطمینان است
- End-User ها میتوانند از سولوشن‌های کلاینت ساید SPFx ( به شرط Approve شدن توسط Administratorها یا نمایندگان آنها) در تمامی سایتها مانند Self-sevice team ، Group و Personal sites استفاده کنند
- SPFx Webpart ها میتوانند به صفحات Classic و هم به modern page ها اضافه گردند
در Runtime مدل وب پارت ویرایشگر اسکریپت script editor بهبود یافته است مثلا شامل Client API و HttpClient object که توسط شیرپوینت یا Office365 هندل میشود ، شامل Contextual information و تسهیل سازی تعریف property و پیکره بندی و ... می‌باشد.
اگر شما قبلا با C# کار می‌کردید و تمایل به یادگیری بیشتر در زمینه توسعه کلاینت ساید دارید و بیشتر دانش Javascript ای شما مرتبط با موارد مربوط به شیرپوینت است باید خدمتان عرض کنم که از قابلیت‌های Rest Service و JavaScript Object Model (jsom) می توانید متناسب به نیازهایتان در SPFx هم استفاده نمایید. بهترین گزینه استفاده از TypeScript بجای Pure javascript است ، برای تایپ اسکریپت شما می‌توانید IDE دلخواه خودتان را استفاده کنید ، تعداد زیادی از Developerها از IDE کراس پلت فرم (cross platform ) ویژوال استودیو کد Visual Studio Code استفاده میکنند.
پس ابزاری که شما را قادر می‌سازد بتوانید SPFx را توسعه دهید Visual Studio Code ، Sublime و ATOM است شما بسته به علاقه‌تان می‌توانید یک کدام را انتخاب نمایید.
چرا شیرپوینت فریم ورک ؟ ( Why the Sharepoint Framework )
از زمانیکه شیرپوینت در سال 2001 به صورت نسخه on-permises لانچ شد ، فروم ها و communityهای متعددی شامل توسعه دهنگان شیرپوینت شکل گرفت و گسترش یافت و اغلب developer ها از یک الگو ( pattern and practice ) جهت توسعه محصولات شیرپوینت پیروی می‌کردند که شامل وب پارتها و سایر فیچرهای شیرپوینت و ... بود ، اکثر فیچرها ( featureها ) توسط C# نوشته می‌شدند و سپس DDL های Compile شده آنها در فارمهای On-permises دیپلوی (deploy) می‌شدند.
این فرآیند در معماری enterprise به خوبی پاسخ گوی نیاز کاربران بوده است اما با گسترش مقیاس شیرپوینت و قابلیت اجرای آن در فضای ابری cloud ، جاهایی که چندید tenant به صورت side by side باهم کار میکنند روش فوق ( deploy solution همانند نسخه on permises ) پاسخ گو نبود لذا مدلهای جایگزین
1. Client side JavaScript injection
2. Sharepioint Add-ins
مطرح شدند که هر کدام از موارد فوق شامل مزایا و معایبی می‌باشند
مدل JavaScript injection :
یکی از محبوب ترین وب پارت‌های موجود در شیرپوینت آنلاین وب پارت ویرایشگر اسکریپت ( Script Editor ) است، شما براحتی با paste کردن کدهای جاوااسکریت در این وب پارت و ذخیره آن و سپس ریفرش نمودن مجدد صفحه می‌توانید وب پارت تان را اجرا نمایید. این مدل یک مدل بسیار ابتدایی است اما موثر است ، در این مدل کدها در همان browser context صفحه مان ( نه در یک Iframe مجزا ) اجرا میشود. در مدل وب پارت براحتی می‌تواند با سایر کنترلهای دیگر موجود در صفحه در تعامل باشد. کارایی و عملکرد بالایی دارد از لحاظ سرعت اجرا و ... ، ضمن اینکه براحتی قابل استفاده است و نیاز به فرآیندهای پیچیده جهت deploy ندارد.
از معایب این مدل می‌توان به موارد زیر اشاره کرد، فرض کنید شما یک پکیج از سولوشن خود تهیه کردید و به javaScript injection اجرا نمودید ، آن پکیج وب پارت براحتی توسط همه کاربرانی که دسترسی ویرایش به صفحه مربوطه را دارند قابل ویرایش و پاک شدن است. پیاده سازی نمودن امکان گزینه های پیکره بندی وب پارت در این مدل کار آسانی نیست. یکی دیگر مشکلات جدی این مدل آنست که وب پارت ویرایشگر اسکریپت گزینه ای برای "Safe For Scripting" ندارد. اکثر self service سایت کالکشن‌ها (my-sites, team sites, group sites) یک فیچری دارند به نام No Script که بنا به دلایل امنیتی به صورت پیش فرض enabled است لذا در این مدل ممکن است بخشی از اسکرپیت های شما توسط فیچر مذکور حذف شود و ذخیره نشود.
مدل Add-in یا App-part :
گزینه فعلی استفاده از مدلی است که بتواند در سایت‌های No Script قابلیت اجرا شدن داشته باشد ( app-part یا add-in ) در این مدل هم از iFrame استفاده میشود. یکی از مزایای این روش اینست که چون به صورت external از DOM صفحه می باشد هیچ دسترسی به current DOM و Connection ندارد لذا برای admin ها و کاربران اعتماد به این وب پارت ها آسان تر خواهد بود. End user ها هم براحتی میتوانند add-ins ها را در no script سایتها نصب کنند.
معایب این روش اینست که ، در این مدل افزونه‌ها از iFrame استفاده میکنند و همانطور که مستحضر هستید iFrame از وب پارت ویرایشگر اسکریپت کندتر عمل می‌کند ( به این علت که درخواست به یک صفحه دیگر ارسال میشود ) به نحوی که اگر یک script editor web part برای render نمودن یک صفحه به 2 میلی ثانیه زمان نیاز داشته باشد ممکن است در مدل iFrame که app-part ها از آن استفاده میکنند به 2 ثانیه زمان نیاز باشد. به علاوه iFrame ایجاد یک طراحی responsive را به شدت دشوار می‌سازد ، البته iFrame ها از لحاظ امنیتی ایمن‌تر عمل میکنند چون صفحه شما غیرقابل دسترسی برای سایر کنترلهای موجود در صفحه است و همچنین کانکشن مربوط به شیرپوینت یا O365 برای سایر کنترلها در دسترس نیست.