Do-it-खुद ORM Sitecore के लिए

हैलो खब्रोवित्स।


Sitecore का हब पर बहुत कम कवरेज है, लेकिन यह बहुत ही कार्यात्मक (और महंगी) CMS उन लोगों के साथ काफी लोकप्रिय है जो इसे वहन कर सकते हैं। हालांकि, साइटक पर साइट (और विशेष रूप से समर्थन करने वाले) विकसित करने वाले लोग अक्सर टेम्पलेट को संशोधित करने में कठिनाई के बारे में शिकायत करते हैं। तो, एक टेम्प्लेट या एकल फ़ील्ड का एक सरल नामकरण अप्रत्याशित हो सकता है और, सबसे महत्वपूर्ण बात, साइट में उल्लंघन का निदान करना और ठीक करना मुश्किल है। और वे कुछ महीनों के बाद ही बाहर निकल सकते हैं। इसके अलावा, मानक SiteCore FieldRenderers का उपयोग लेआउट को नियंत्रित करना मुश्किल बनाता है, जो हमारे मामले में महत्वपूर्ण था।

बाइक क्यों?

टेम्प्लेट के आधार पर कक्षाएं उत्पन्न करने के लिए समाधान हैं (जैसे trac.sitecore.net/CompiledDomainModel ), लेकिन वे उपयोग करने के लिए बहुत सुविधाजनक नहीं हैं और टेम्पलेट संरचना, फ़ील्ड नामों के लिए बाध्यकारी को समाप्त नहीं करते हैं। उल्लेखित CompiledDomainModel को किसी भी परिवर्तन के बाद सभी मॉडलों के पुनर्जनन की आवश्यकता होती है। यह सहयोगी विकास के लिए भी खराब रूप से अनुकूल है (उत्पन्न कोड में लगातार संघर्ष), सभी टेम्पलेट्स के लिए अद्वितीय नामों की आवश्यकता होती है, टेम्प्लेट और आईडी से बंधा होता है, और एक फ़ाइल में राक्षसी कोड उत्पन्न करता है (परियोजनाओं में से एक पर 60,000 से अधिक लाइनें और खुली थीं) यह वीएस में बहुत तेज नहीं था)।


हमारी टीम सौभाग्यशाली थी कि मौजूदा साइटों के समर्थन में अनुभव के आधार पर, साइटकॉर 6.3 के लिए एक नई साइट विकसित की गई। मुझे तुरंत इस बात पर जोर देना चाहिए कि हम एक सामग्री साइट के बारे में बात करेंगे। दिलचस्प कार्यक्षमता केवल व्यवस्थापक पैनल में आवश्यक थी और इसका साइटकॉर के साथ सीधा संबंध है।

पहियों के आकार के बारे में अगला

सबलेउट पर साइटक के लिए लिंक छोड़ने का फैसला किया गया था, टेम्प्लेट और फ़ील्ड्स के लिए मजबूत टाइपिंग को तेज़ करें, केवल एक एकल और अनुमानित स्थान पर फ़ील्ड के नामों को संग्रहीत करें।

टेम्प्लेट के लिए हमारे सभी रैपर कक्षाओं का आधार क्लास टेम्प्लेट है, जिसका मुख्य कार्य सभी मौजूदा आइटम टेम्प्लेट की जांच करना और घोषित नामों के साथ उनके नामों को सत्यापित करना है। वर्ग-टेम्पलेट संबंध के लिए, DataContract विशेषता का उपयोग किया जाता है।

नोट: इसके बाद, मुख्य विचार और पठनीयता को बताने के लिए कोड को छोटा किया जाता है

[DataContract(Name = "Base text page")] public class BaseTextPage : Template {...} 

 public class Template { private readonly Item item; public Template(Item item) { var missedTemplates = GetMissedTemplates(item, this.GetType()); //   DataContract        Item-. if (missedTemplates.Any()) { ... throw new InvalidDataException("Item is not of required template”); //        } this.item = item; } … } 

उसी टेम्प्लेट क्लास में, टेम्प्लेट फ़ील्ड तक पहुँचने के लिए कई उपयोगी कार्य हैं:

 protected T GetField<T>(string name, T @default = default(T)) { var dataType = typeof(T); var field = this.Item.Fields[name]; … //  : if (dataType == typeof(string)) { if (string.IsNullOrEmpty(field.Value)) { return @default; } return (T)(object)field.Value; } if (dataType == typeof(LinkField)) { return (T)(object)new LinkField(field); } if (dataType == typeof(ImageField)) { return (T)(object)new ImageField(field); } … //etc for all field types } protected T GetFromField<T>(string name) where T : Template { var link = this.GetField<ReferenceField>(name); if (link != null && link.TargetItem != null) { return (T)Activator.CreateInstance(typeof(T), link.TargetItem); } return null; } protected T GetFromParent<T>() where T : Template { if (this.Item == null || this.Item.Parent == null) { return default(T); } return (T)Activator.CreateInstance(typeof(T), this.Item.Parent); } 

अगला कदम खेतों तक पहुंचना है। साइट-साइटों की सहायता से साइट-साइट की एक जानी-मानी समस्या पूरे प्रोजेक्ट में उदारतापूर्वक बिखरे हुए फ़ील्ड नाम हैं। हमारा कार्य परियोजना में एक और केवल एक क्षेत्र का नाम रखना है। फिर से हम मानक विशेषताओं का उपयोग करते हैं, अब DataMember।

 [DataContract(Name = "Base text page")] public class BaseTextPage : Template { [DataMember(Name = "Big text content")] public string Text { get { return this.Item[this.GetFieldName(x => x.QuestionText)]; } } [DataMember(Name = "Logo Image")] public string LogoImage { get { return this.GetField<ImageField>(this.GetFieldName(x => x.BigImage)).GetMediaUrl(); } } … } 

यहाँ सबसे महत्वपूर्ण बात GetFieldName फ़ंक्शन है, जिसे फ़ॉर्म के विस्तार-विधि के रूप में घोषित किया गया है:

 private static readonly Dictionary<string, string> fieldNameCache = new Dictionary<string, string>(); public static string GetFieldName<T, TResult>(this T obj, Expression<Func<T, TResult>> memberExpression) where T : class { if (obj == null) { throw new ArgumentNullException("obj"); } var member = memberExpression.ToMember(); if (member.MemberType != MemberTypes.Property) { throw new ArgumentException("Not a property access", "memberExpression"); } var fieldCahceKey = typeof(T).Name + member.Name; if (fieldNameCache.ContainsKey(fieldCahceKey)) { return fieldNameCache[fieldCahceKey]; } var fieldName = typeof(T) .GetProperty(member.Name) .GetCustomAttributes(typeof(DataMemberAttribute), true) .Cast<DataMemberAttribute>() .Select(curr => curr.Name) .FirstOrDefault(); if (string.IsNullOrEmpty(fieldName)) { return null; } fieldNameCache[fieldCahceKey] = fieldName; return fieldName; } private static MemberInfo ToMember<TMapping, TReturn>( this Expression<Func<TMapping, TReturn>> propertyExpression) { if (propertyExpression == null) { throw new ArgumentNullException("propertyExpression"); } var expression = propertyExpression.Body; if (expression.NodeType == ExpressionType.MemberAccess) { var memberExpression = expression as MemberExpression; if (memberExpression != null) { return memberExpression.Member; } } throw new ArgumentException("Not a member access", "propertyExpression"); } 

इस बिंदु पर हम कुछ इस तरह लिख सकते हैं:

 BaseTextPage page = new BaseTextPage(Sitecore.Context.Item); var text = page.Text; var imageUrl = page.LogoImage; 

और वर्तमान आइटम के "बिग टेक्स्ट कंटेंट" / "लोगो इमेज" फ़ील्ड से डेटा प्राप्त करें, बशर्ते कि इसका टेम्पलेट बेसटेक्स्टपेज क्लास के लिए उपयुक्त हो।

अगला, हम टेम्पलेट के लिए एक आवरण बनाते हैं जो हमारे अन्य सभी टेम्पलेट्स के लिए आधार होगा। कम से कम यह एक "अतिरिक्त टेम्पलेट" होगा, लेकिन आमतौर पर कुछ और उपयोगी करना बेहतर होता है। उदाहरण के लिए

 [DataContract(Name = "Base page")] public class BasePage : Template { [DataMember(Name = "Show in menu")] public bool ShowInMenu { get { return this.Item[this.GetFieldName(x => x.ShowInMenu)].GetBoolValue(); } } [DataMember(Name = "Page title")] public string Title { get { return this.Item[this.GetFieldName(x => x.Title)]; } } } 

अब हम सबलेआउट में इसे लागू करते हैं:

 public class BaseSublayout<T> : UserControl where T : BasePage { protected virtual T Model { get { return (T)Activator.CreateInstance(typeof(T), Sitecore.Context.Item); } } } public partial class ConcreteTextPage: BaseSublayout<MyProject.ORM.Content.ConcreteMapping> { protected void Page_Load(object sender, EventArgs e) { var smthUsefull = this.Model.HeaderText; } } 

इस क्षण से, .aspx फ़ाइलों की सामग्री ASP.MVC में उन लोगों की तरह बनने लगती है। सुविधा प्रभाव को बढ़ाने के लिए, डेटा की उपस्थिति / वैधता के लिए मानक जांच के साथ मार्कअप प्रदर्शित करने के लिए विस्तार विधियों का एक सेट बनाया गया है (उदाहरण के लिए, खाली src या href के बिना लिंक के साथ चित्रों को प्रदर्शित न करें)।

 <h1><%= this.Model.Header %></h1> <%= HtmlHelper.RenderImage(this.Model.SomeEntity.MainImage) %> <% foreach (var link in this.Model.SelectedLinks) { %> <%= HtmlHelper.Anchor(link.Url, link.Text) %> <% } %> 

दृष्टिकोण के लाभ:
+ गुण के रूप में हाथ में प्रासंगिक आइटम के सभी आवश्यक क्षेत्र
+ प्रासंगिक आइटम में हमेशा सही टेम्पलेट होता है
+ सिटकोर के लिए सभी डेटा-जाँच मानक एक ही स्थान पर किया जाता है
+ साइट सेटिंग्स तक केंद्रीकृत पहुंच जिसके लिए समान आवरण लिखे गए हैं
+ स्वच्छ (न्यूनतम, लापता) पृष्ठ कोड
+ पूर्ण लेआउट नियंत्रण
विपक्ष
- सभी हाथ मैपिंग
- फ़ील्ड / टेम्प्लेट के नाम निकालने के लिए खर्च

मुझे उम्मीद है कि यह लेख साइटचोर डेवलपर्स के लिए उपयोगी होगा।