SharePoint Foundation Enterprise साइट: कुछ सर्वोत्तम अभ्यास

अच्छे दिन, Habrahabr के प्रिय उपयोगकर्ता। मैं Microsoft SharePoint Foundation 2010 (इसके बाद - SPF) के प्लेटफ़ॉर्म पर एक कॉर्पोरेट साइट बनाने के अनुभव को आपके साथ साझा करना चाहता हूं। हाल ही में, प्लेटफ़ॉर्म का एक नया संस्करण, SharePoint 2013, जारी किया गया था, लेकिन मुझे लगता है कि यह लेख उसके लिए भी कई मायनों में प्रासंगिक होगा। मैं यहां सामग्री प्रबंधन प्रणाली साइट के रूप में SharePoint के फायदे और नुकसान का वर्णन नहीं करूंगा। इस लेख का उद्देश्य यह दिखाना है कि आप श्रम के संदर्भ में किसी संगठन की वेबसाइट को इस मुफ्त मंच पर अपेक्षाकृत जल्दी और सस्ते में कैसे विकसित कर सकते हैं। मुझे उम्मीद है कि यह अनुभव आप में से कुछ के लिए उपयोगी होगा।

तो चलिए शुरू करते हैं। सबसे पहले, SharePoint सर्वर (इसके बाद SPS के रूप में संदर्भित) के स्थान पर SPF को साइट के लिए प्लेटफ़ॉर्म के रूप में क्यों चुना गया? इंटरनेट परिदृश्यों के लिए Microsoft की लाइसेंसिंग नीति के अनुसार, जब असीमित उपयोगकर्ताओं को SPS के माध्यम से कॉर्पोरेट संसाधनों तक पहुंच मिलती है, तो आपको इंटरनेट साइट्स लाइसेंस के लिए SharePoint सर्वर खरीदना होगा। एसपीएफ मुक्त है और यह मुख्य तर्क है।

लेकिन, एसपीएफ़ चुनने पर, हम साइट सामग्री प्रबंधन प्रणाली की कार्यक्षमता का हिस्सा खो देते हैं, जो एसपीएस में पूरी तरह से उपलब्ध है। अधिकतर, ये अतिरिक्त कॉर्पोरेट वेबसाइट टेम्पलेट हैं और सामग्री प्रकाशित करने की क्षमता है। कॉर्पोरेट साइट टेम्पलेट अपने लिए बोलते हैं और आपको मानक टेम्पलेट के आधार पर साइट बनाने की अनुमति देते हैं। प्रकाशन सुविधा आपको विशेष प्रकार की प्रकाशन सामग्री, सूचियों और दस्तावेज़ पुस्तकालयों, वेब भागों, मास्टर पृष्ठों और पृष्ठ लेआउट का उपयोग करने की अनुमति देती है। मास्टर पेजों के केंद्रीकृत प्रबंधन और उनकी सहायक साइटों की विरासत, साइट नेविगेशन के प्रबंधन और अनाम उपयोगकर्ताओं के लिए साइट के कुछ पृष्ठों को अवरुद्ध करने के कार्य के साथ मिलकर, प्रकाशन की संभावना साइट सामग्री प्रबंधन प्रणाली के बुनियादी ढांचे को प्रदान करती है। एसपीएफ़ में, हमें अन्य साधनों के साथ करना होगा।

एक लोकप्रिय धारणा है कि SharePoint पर एक अच्छा उद्यम साइट एक ऐसी साइट है जो SharePoint पर एक साइट की तरह नहीं दिखती है। इस आशय को प्राप्त करने के लिए, मानक मास्टर पेज टेम्प्लेट और SharePoint पेज लेआउट के उपयोग को छोड़ना बेहतर है और उन्हें अपने स्वयं के साथ बदलना है। सबसे पहले, आपको कॉर्पोरेट शैली में ब्रांडिंग के साथ साइट का एक मास्टर पृष्ठ बनाने की आवश्यकता है। शुरू करने का सबसे आसान तरीका एक मास्टर पेज टेम्पलेट है जिसमें न्यूनतम ASP.NET/SharePoint नियंत्रण और लेआउट, जैसे कि स्टार्टर.मास्टर । इस उद्देश्य के लिए कई लोग इस गाइड का उपयोग न्यूनतम। मास्टर पेज बनाने के लिए भी करते हैं। किसी साइट को ब्रांड बनाने के लिए, आपको corev4.css, form.css, आदि में परिभाषित मानक CSS शैलियों को फिर से परिभाषित करना होगा। नई शैली की फाइलें SharePoint हाईवे या साइट पदानुक्रम में विशेष रूप से बनाए गए फ़ोल्डर में रखी जा सकती हैं। Microsoft Office Power Point या Microsoft थीम बिल्डर में एक थीम बनाकर और साइट थीम संग्रह में जोड़कर SharePoint थीम की कार्यक्षमता का उपयोग करके ब्रांडिंग भी की जा सकती है। डिजाइन के आधार पर, अक्सर किसी साइट के मुख्य पृष्ठ के लिए यह एक त्वरित लॉन्च नेविगेशन बार या शीर्ष लिंक बार के बिना एक अलग मास्टर पेज बनाने के लिए समझ में आता है।

यदि कॉर्पोरेट साइट की संरचना ऐसी है कि शीर्ष-स्तरीय साइट में कई सहायक साइटें हैं, तो आपको मुख्य मास्टर पृष्ठ के अपडेट को सहायक साइटों पर वितरित करने के मुद्दे पर सही तरीके से संपर्क करना चाहिए। जैसा कि पहले उल्लेख किया गया है, एसपीएफ़ में सहायक साइटों के मास्टर पृष्ठों के केंद्रीकृत प्रबंधन के लिए कोई कार्यक्षमता नहीं है। बेशक, आप इसे मैन्युअल रूप से अद्यतन मास्टर पेज फ़ाइल को प्रत्येक साइट के मास्टर पृष्ठों के संग्रह में कॉपी करके कर सकते हैं, लेकिन यह, इसे हल्के ढंग से डालने के लिए, असुविधाजनक है। एक अवसर में मुख्य मास्टर पृष्ठ को लपेटना और समाधान का उपयोग करके इसे स्थापित करना अधिक तर्कसंगत है। इस तरह के अवसर की कॉन्फ़िगरेशन फ़ाइलों का एक उदाहरण है:

<Feature Id="23E27B3A-120C-3259-02DA-103CC45179BB" Title="Site Master Page" Scope="Site" Version="1.0.0.0" Hidden="FALSE" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/" Description="This feature deploys the site master page"> <ElementManifests> <ElementManifest Location="elements.xml" /> <ElementFile Location="MasterPages\sitemasterpage.master" /> </ElementManifests> </Feature> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Module Name="SiteMasterPage" Url="_catalogs/masterpage" Path="MasterPages" RootWebOnly="FALSE"> <File Url="sitemasterpage.master" Type="GhostableInLibrary" /> </Module> </Elements> 

RootWebOnly = "FALSE" विशेषता इंगित करती है कि मास्टर पेज को परिवार में सभी साइटों के मास्टर पेज संग्रह में स्थापित किया जाएगा, और टाइप = "घोस्टेबलइंलुइट्स" विशेषता का अर्थ है कि इस तरह से सेट किए गए सभी मास्टर पृष्ठ एक मास्टर पेज फ़ाइल से लिंक होंगे राजमार्ग में सुविधाओं के फ़ोल्डर में स्थित है, इसलिए इस फ़ाइल में कोई भी परिवर्तन सभी साइटों पर दिखाई देगा।

साइट नेविगेशन के बारे में बात करें। एसपीएस के विपरीत, एसपीएफ़ में मानक साइट प्रशासन पृष्ठ के माध्यम से साइट नेविगेशन लिंक के शीर्ष बार में एक पदानुक्रमित बहु-स्तरीय मेनू बनाने का कोई तरीका नहीं है। लेकिन यह प्रोग्रामेटिक रूप से किया जा सकता है, उदाहरण के लिए, एक साधारण पॉवरशेल स्क्रिप्ट का उपयोग करके:

 [System.Reflection.Assembly]::Load("Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"); $url = "http://site" $site = new-object Microsoft.SharePoint.SPSite $url; $web = $site.OpenWeb() $topnav = $web.Navigation.TopNavigationBar while ($topnav.Count -gt 0) { $topnav.Delete($topnav[0])} $node1 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @(" ", "/company", $False) $node1 = $topnav.AddAsLast($node1) $node2 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("", "/company/pages/history.aspx", $True) $node2 = $node1.Children.AddAsLast($node2) $node3 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("", "/company/events", $False) $node3 = $node1.Children.AddAsLast($node3) $node4 = new-object Microsoft.SharePoint.Navigation.SPNavigationNode -argumentlist @("", "/company/events/Lists/news", $False) $node4 = $node3.Children.AddAsLast($node4) 

त्वरित लॉन्च मेनू के लिए, आप साइट प्रशासन पृष्ठ का उपयोग करके पदानुक्रम के दो स्तर बना सकते हैं। यदि यह पर्याप्त नहीं है, तो आप स्क्रिप्ट के साथ नेविगेशन संरचना बना सकते हैं।

जैसा कि पहले उल्लेख किया गया है, एसपीएस में प्रकाशित करने की क्षमता साइट सामग्री के प्रबंधन के लिए बुनियादी ढांचे का निर्माण करती है। अन्य बातों के अलावा, यह आपको दस्तावेजों "पेज" (पेज) के विशेष पुस्तकालयों में सामग्री को संग्रहीत करने की अनुमति देता है, जिसके लिए सामग्री के प्रमुख और मध्यवर्ती संस्करणों की एक निश्चित संख्या के लिए अनुमोदन और भंडारण विकल्प शामिल हैं। एसपीएफ़ में, हम मैन्युअल रूप से "पेज" दस्तावेज़ लाइब्रेरी बनाकर और गुणों में उनके लिए सामग्री अनुमोदन और संस्करण तैयार करके इस कार्यक्षमता को पुन: उत्पन्न कर सकते हैं। यदि साइट पर सामग्री को संग्रहीत करने के लिए अन्य सूचियों और दस्तावेज़ पुस्तकालयों का उपयोग किया जाता है, तो उन्हें उसी तरह से कॉन्फ़िगर किया जा सकता है।

एसपीएस में प्रकाशन की संभावना भी विशेष प्रकार की सामग्री को ले जाती है, उदाहरण के लिए, "अनुच्छेद पृष्ठ"। उनकी मदद से, एसपीएस पृष्ठ दस्तावेज़ पुस्तकालयों में नई साइट सामग्री बनाना अपेक्षाकृत आसान है, सामग्री को विशेष प्रकाशन नियंत्रण तत्वों में पृष्ठ पर रखा गया है। एसपीएफ में, आप इस उद्देश्य के लिए वेब पार्ट पेज का उपयोग कर सकते हैं, इसमें "कंटेंट एडिटर" वेब पार्ट को जोड़ सकते हैं, इस वेब पार्ट में कंटेंट रख सकते हैं, और पेज को पहले से बने पेज डॉक्यूमेंट लाइब्रेरी में रख सकते हैं। यदि आपको HTML सामग्री को सूची आइटम में संग्रहीत करने की आवश्यकता है, तो "उन्नत रिच टेक्स्ट" विकल्प के साथ एक "बहु-पंक्ति पाठ" फ़ील्ड एक अच्छा फिट है।

SharePoint पर साइट बनाते समय, XsltListViewWartPart जैसे सूची दृश्यों के मानक वेब भागों को अनुकूलित किए बिना करना मुश्किल है। उनकी वास्तुकला काफी अजीब है, और यदि आपको बड़ी संख्या में ऐसे वेब भागों के गंभीर अनुकूलन की आवश्यकता है, उदाहरण के लिए, XSLT रेंडरिंग टेम्प्लेट के बदलाव के साथ, आप इस पर बहुत सारे ग्लास खा सकते हैं। इस तरह के कार्य का सामना करते हुए, मैंने अपने सार्वभौमिक (मेरे उद्देश्यों के लिए) वेब पार्ट लिखने के पक्ष में एक विकल्प बनाया, जो XML VIEW अनुरोध योजना के अनुसार, निर्दिष्ट सूची / दस्तावेज़ लाइब्रेरी से डेटा प्राप्त करता है और उन पर एक सरल XSLT टेम्प्लेट लगाता है, जो आमतौर पर 5 मिनट में लिखा जाता है। जैसा कि कहा जाता है, अंतर महसूस करें:

 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ext="webparts.xsltlistviewwebpart"> <xsl:param name="ListUrl"/> <xsl:output method="html"/> <xsl:template match="rows"> <div id="news"> <div class="page_title" style="margin-top:7px !important; margin-bottom: 10px;"> <span> </span> </div> <table width="100%" border="0" cellspacing="0" cellpadding="3" class="ms-listviewtable"> <tbody> <xsl:for-each select="row"> <tr> <td style="vertical-align:top;"> <span class="date_text" style="display:inline-block;"> <xsl:value-of select="ext:Frmt_Date_Time(PublishDate, 'dd MMMM yyyy')"/> </span> </td> <td style="vertical-align:top;"> <a class="title_item" style="font-size: 10pt;"> <xsl:attribute name="href">javascript:</xsl:attribute> <xsl:attribute name="onclick">javascript: window.location.href='<xsl:value-of select="concat($ListUrl,concat('/DispForm.aspx?ID=',ID))" disable-output-escaping="yes"/>&Source=' + escape(window.location.href);</xsl:attribute> <xsl:value-of select="Title" disable-output-escaping="yes"/> </a> </td> </tr> </xsl:for-each> </tbody> </table> </div> </xsl:template> </xsl:stylesheet> 

एसपीएफ चेहरों पर साइट डेवलपर का एक और महत्वपूर्ण मुद्दा यह है कि क्या आपको अनाम उपयोगकर्ताओं के लिए कुछ साइट पृष्ठों तक पहुंच को प्रतिबंधित करने की आवश्यकता है, उदाहरण के लिए, सिस्टम पेज (एप्लिकेशन पेज) / _layouts / के माध्यम से सुलभ, या सूचियों और पुस्तकालयों के सेवा विचार। दस्तावेजों। एसपीएस में, प्रकाशन पोर्टल टेम्पलेट से बनाई गई साइटों पर, "साइट संग्रह के लिए ब्लॉक मोड" (ViewFormPagesLockDown) सुविधा का उपयोग किया जाता है, जो अनाम उपयोगकर्ताओं के लिए साइट के सिस्टम पृष्ठों को अवरुद्ध करने के कार्य का उपयोग करता है। एसपीएफ में ऐसी कोई संभावना नहीं है, और सबसे तर्कसंगत समाधान, मेरी राय में, कुछ पृष्ठों पर http- अनुरोधों का विश्लेषण और अवरुद्ध करने के लिए अपना स्वयं का http-मॉड्यूल बनाना है, इसके बाद एक पृष्ठ पर पुनर्निर्देशित किया गया है, जहां पहुंच निषेध है। वेबसाइट के वेब एप्लिकेशन के कॉन्फ़िगरेशन में निषिद्ध पृष्ठों के URL को सेट करना सुविधाजनक है, उदाहरण के लिए, फ़ॉर्म में

 <SecuritySettings> <Extensions> <res ext=".aspx" /> <res ext=".html" /> <res ext=".htm" /> </Extensions> <Allowed> <res url="*/_layouts/searchresults.aspx*" /> </Allowed> <Denied> <res url="*/_forms/*" /> <res url="*/_layouts/*" /> <res url="*/_catalogs/*" /> <res url="*/_controltemplates/*" /> <res url="*/_cts/*" /> <res url="*/_private/*" /> <res url="*/_login/default.aspx*" /> <res url="*/m/default.aspx*" /> <res url="*/approval.aspx*" /> <res url="*/latestreports.aspx*" /> <res url="*/personalviews.aspx*" /> <res url="*/last2weeks.aspx*" /> <res url="*/allitems.aspx*" /> </Denied> </SecuritySettings> 

मेटा टैग का उपयोग करके खोज इंजन के लिए साइट सामग्री के खोज इंजन अनुकूलन के अनुयायियों को जिस तरह से आप गतिशील साइट पृष्ठों के लिए ऐसे टैग बना सकते हैं, जैसे कि सूची आइटम और दस्तावेज़ लाइब्रेरीज़ देखने के लिए फ़ॉर्म (DispForm .aspx)। मेरे मामले में, मैंने इस प्रश्न को इस प्रकार हल किया:

• साइट पर कीवर्ड की एक सूची "कीवर्ड" (कीवर्ड) के साथ बनाई गई थी,
• आइटम देखने के लिए प्रपत्रों में मेटा टैग के लिए सूचियों और दस्तावेज़ पुस्तकालयों में, कीवर्ड की सूची से "कीवर्ड" फ़ील्ड के लिए एक प्रतिस्थापन फ़ील्ड जोड़ा गया, साथ ही साथ कीवर्ड द्वारा परिभाषित सामग्री के खोज विवरण के लिए एक "विवरण" फ़ील्ड।
• एक वेब नियंत्रण विकसित किया गया था, जो प्रदान की गई निर्धारित प्रक्रिया के दौरान और, यदि उपलब्ध हो, मेटा टैग "कीवर्ड" में प्रतिस्थापन फ़ील्ड के मान को दर्ज करता है, और मेटा टैग "विवरण" में फ़ील्ड का विवरण "विवरण",
• यह नियंत्रण साइट के मास्टर पेज पर एक डेलीगेटकंट्रोल एडिशनलपेजेज के रूप में दर्ज किया गया था, जिसमें फीचर का उपयोग किया गया था:

 <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <Control Id="AdditionalPageHead" Sequence="50" ControlClass="MetaTagGenerator" ControlAssembly="MetaTagGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=18bdc3dfdc022d0b" /> </Elements> 

परिणामस्वरूप, सूची आइटम या दस्तावेज़ लायब्रेरी को देखने के लिए फ़ॉर्म का पृष्ठ प्रदान करने की प्रक्रिया में जिसके लिए कीवर्ड प्रतिस्थापन फ़ील्ड भरी जाती है, संबंधित मेटा टैग पृष्ठ पर रखे जाते हैं।

और अंत में, एसपीएफ़ में साइट खोज कार्यक्षमता के बारे में कुछ शब्द। मानक खोज एक खोज क्षेत्र चुनने का सुझाव देती है। एक कॉर्पोरेट साइट पर, मेरी राय में, ऐसी सेटिंग्स केवल उपयोगकर्ता के साथ हस्तक्षेप करती हैं, क्योंकि आमतौर पर सभी सामग्री की खोज की आवश्यकता होती है। इसलिए, मैं उपयोगकर्ता को इस चुनाव से थोड़ा अनुकूलन द्वारा बचाने की सलाह देता हूं। ऐसा करने के लिए, निम्न कार्य करें:

• अपना स्वयं का खोज नियंत्रण बनाएं जो पूरी तरह से मानक Microsoft.SharePoint.WebControls.SearchArea के समान हो, लेकिन अपने मार्कअप में SearchScope खोज क्षेत्रों की सूची न बनाएं,
• मास्टर पेज पर बने नियंत्रण को DelegateControl SmallSearchInputBox के रूप में पंजीकृत करने की क्षमता का उपयोग करते हुए,
• मानक खोज परिणाम पृष्ठ /_layouts/searchresulsts.aspx के लेआउट में, SearchScope खोज क्षेत्रों की सूची के नियंत्रण पर टिप्पणी करें।

इस मामले में, जब खोज अनुरोध भेजते हैं, तो SubmitSearchRedirect_function में CORE.js सिस्टम स्क्रिप्ट, मार्कअप में SearchSopeope खोज क्षेत्रों की सूची प्राप्त किए बिना, खोज स्कोप पैरामीटर सेट नहीं करेगा, जो साइट संग्रह में सभी साइटों की खोज के रूप में खोज सेवा द्वारा स्वीकार किया जाएगा।