Category: Uncategorized

With every new project, the situation is a little bit different, some times you feel like you have the whole time in the world and sometimes time is just not enough no matter what.  It depends on timeline, scope, budget and many many other things actually.

In my recent Sitecore project I am working on, fortunately I am getting enough time to craft and think about every single decision on my way.  This feels so good as I can beautifully craft a solution that is great functionally and from marketing perspective.

With start of every build phase of the project, based on team and project, I make a quick checklist for Developers and team to go over before they submit for code review.  It does not  take a lot of time, but, will go long way to ensure we are implementing Sitecore to take advantage of out of the box functionality it has got, it is important to remember why Clients chose Sitecore and ensure the set up is done right to satisfy their needs, both functionally and from content authoring/Marketing perspective.

Below is one such list and I make effort to keep that updated as the team moves towards attempting complex modules.  The mantra is to build out smaller and keep updating it based on pitfalls you generally see in your team.

1.  Follow Technical Breakdown as closely as possible, if something should be done differently, please collaborate with Technical lead that had done the breakdown and mention the same, so he/she is aware
2. Assume that any or every object could be null and ensure null checks are in place on your controller or business logic code.
3. Minimize code or branching in view, in fact, we recommend to have literally no code, except for simple if statements that would check before editable/property is outputted on the view.  Everything should be available on Model or View Model that is passed and logic should reside in Controller.
4. Create and check in all sitecore items on to project that the module or feature would need.
5. Ensure Helix patterns and principles are followed and applied.  Technical breakdown should provide guidelines on the same as well.
6. Do not forget to set proper Insert Options and Standard values based on functional requirements.  This is a must for a seamless content author experience
7. Datasource and Data Template are required and is usually specified on datasource driven modules on the Technical Breakdown
8. All fields such as pickers like Multilist, droplist or Images should be having a source assigned to ensure proper funneled content is shown to content author when trying to load content and keeping media and datasources organized and secured.
9. Helptext, which are hints for the content author should be added when ever there is back end logic to decide on priority between two fields or specific scenario happens when user fills in a specific content field.  Talk to your Technical lead when in question.
10. Every thing that is stated editable should be allowed to be editable and unit tested on Experience Editor, consider adding custom experience buttons / Edit frames to edit background images and pop over text when applicable. Other options could be explored if scenario could not be addressed with such easy to configure tools.
    1. If there is a drop list or a picker on content editor, such as theme selection or pattern selection, etc., consider adding a custom experience button to ensure content author could edit the same from Experience Editor.  Refer :  https://community.sitecore.net/technical_blogs/b/maximizing_usability/posts/enhancing-the-page-editor-experience-with-custom-experience-buttons
11. Ensure your module implemented works on Experience Editor and in fact editable entities are correctly edited and saved via the platform.
12. Ensure to upload a new image for Thumbnail for ease of use by content author and to look professional and intuitive.  Look in to document uploaded on sharepoint for instructions on how to do the same.  Document Name:  Steps To Upload Thumbnail Image For Rendering.docx
13. Do error handling when needed and may be a back end service is being used to gather information on controller.  Use methods available on Sitecore.Diagnostics to ensure to push the error to logs, it would be helpful while debugging an issue on upper environments
14. If there an RTF, ensure a source is set up that pulls up capabilities listed on documentation.
15. At early stages of the implementation, I would recommend for ease of checking and testing process, the new rendering/module should have at least one set of sample content checked in and this rendering should be added to standard values of Generic Template, a new content page should be instantiated under Home node of the instance and if not dynamic data source, a specific data source should be picked to ensure when the page is accessed the module would show up on the website.
16. Use the power of Glass to load everything you need on your datasource object or TDS Class, it is easy to extend and tell Glass what type of object you want and map it with few attributes and as simple as that, you get everything you need and controller is clean. Avoid writing code when you don’t have to.

Glass just makes me so happy! I do not have to write same 10-15 lines of code every time to do something very mundane when it comes to Sitecore. Every other feature on sitecore demands some kind of relationship driven items to be accessible from context page on which your module would do some magic on. Typically, developers tend to write their own custom code to do such things which would lead to bad performance when not done right. Why not just go with Glass if you are using it in your instance development? It is far more easier. I had done a similar blog post to grab children from Glass, but, this time around it is Ancestors. Though similar, it could help some one who did not think or know that it could be used on both the relation ships on the tree, upwards or downwards. Steps to do this is quite simple and three step process Declare a custom partial class that extends your auto generated class based on say a template. For example like below. I like to keep these guys organized, usually do it in special Model project and namespace related to it, to keep things easy and manageable, so some one can easily know if the model has been extended. Next up, add a Attribute that comes with Glass such as below, pass your template ID. I actually tried getting this ID from a config setting which would have been great for maintenance, see if you can do that based on your project settings Access the new ancestor strongly typed( A bonus, so you dont need to cast and make a messy view, the view simply get’s what it needs and you access and ensure your checks are in place)

Sample Code Of Custom Partial Class namespace

YourProject.Models {

public partial class Your_Template_Auto_Generated_Clas{

[SitecoreQuery(“./ancestor-or-self::*[@@templateid='{7E6BC980-362C-4BBB-97E5-9DAA83B70812}’]”, IsRelative = true)] public virtual Your_Strongly_Typed_class myAncerstorItem { get; set; }

} }

Voila!

Goal accomplished and the best part clean code, clean views and happy MVC.

Have a great weekend ahead!!!