Monday 25 May 2015

Guidelines for Sitecore MVC


­
1.    Controller is supposed to control and direct, it should not have any logic (many developers forget this and it happened in Vision Web too) and should be as slim as possible.
2.    One of the main advantages of MVC is that the view (technically called as View template) is not tightly coupled with the server side. So, we can switch/add a new view (say for mobile or tablet) for an existing flow any time. In order to achieve this we should make the view as ignorant as possible of what it displays and should concentrate more towards how it displays.
3.    Try to avoid c# code in .cshtml as much as possible. Use html helpers in all situations. Create extension methods for html helpers to re-use code and constructs.
4.    Model could contain all logics and calculations and can be fat. It is good to use Model only to represent an entity and to use ViewModel to represent transit entities.
5.    Better to avoid ViewBag or ViewData for transit entities when they are present in multiple places. ViewModel instead would make the code more managable.
6.    Use IOC to decouple the connection to SiteCore. This will help in redirecting the call for test data to our own repository.
7.    Methods which are not Actions should not be public.
8.    Use TempData instead of Session when the data is needed only for the subsequent request.
9.    Use filters as and when it becomes appropriate. It will help in getting an easier control of the flow in different stages on a global scale.
1.    For enhancing reusability, use controls/partial pages as much as possible.
. ...   Exception handling mechanism and Logging framework will have to be put in place which will not require much effort from the developer every time that he has to handle it for his module.

1.  Never put an unnecessary check when some value is not intended to be there. There were many problems in Visionweb due to this. (Example of this is developers putting a check for null/empty everywhere. This habit will avoid the exception but will make the intention of the code ambiguous and will lead to loop holes in the flow. 

Thursday 26 March 2015

Characteristics of modern web applications.

Characteristics of modern web applications.

• Cross-browser compatibility: The application experience is constant across all modern web browsers, including Google Chrome, Mozilla Firefox, Internet Explorer 9 and 10, Safari, and Opera. 

• Adaptive design: The application automatically adapts to work on many screen resolutions,from huge 30-inch monitors to tiny 3.4-inch cell phones.

• Natural user interfaces: The application accepts input from natural user interfaces (NUI) such as touch, voice, NFC, video cameras, GPS, and other sensors. Meeting this requirement means that you have not only the right software but the hardware to test how the application behaves on these devices.

• Social network integration: The application seamlessly interacts with social networks.

• Cloud-ready: The application can use cloud-based infrastructure and scales on demand,adding new servers when needed and scaling down when traffic slows.

• Resiliency: The application can adapt to challenging network conditions and, in some cases, can work in a disconnected state. The application is designed to tolerate failures of one or more subsystems and still operate at limited but acceptable capacity.

• Extensible: The application is extensible by way of RESTful APIs and its functionality can be augmented by third-party developers.

• Reliable: The application is reliable and supports multiple levels of automated and manual testing before being deployed. 

• Maintainable: The application is easy to maintain and can be upgraded frequently and seamlessly with minimal disruption of the service. 

• RESTful: The application is built on established standards and protocols, and takes advantage of network optimization appliances, load balancers, and monitoring packages.

• Secure: The application has been designed to protect itself from evolving security threats using a layered system of counter measures. If a breach occurs, only the compromised subsystems will be affected; confidential and personally identifiable information will not be exposed.

• Scalable: The application should be able to support thousands of concurrent users.

Tuesday 20 January 2015

The most important rules for Sitecore development.

The most important rules for Sitecore development.
Technology is only as effective as the people that implement it, so making sure you're at the top of your Sitecore development game will be beneficial for your entire organization.

1. Use Page Editor friendly controls

Content author experience is something we talk about often here at nonlinear. Ensuring that your content authors have the capabilities to create and modify content in real time using "what you see is what you get" or WYSIWYG editing is crucial. By incorporating these controls into your development, your content authors will avoid having to delve into the Sitecore content tree to find the matching fields.

2. Don't bind a repeater unless the situation calls for one

The <asp:Repeater> control allows a list of items to be bound to it and causes the specified HTML (and possible code) to be executed for each item. In a basic repeater pattern, there is often a header and footer section that contains HTML that does not repeat. Binding an empty list to a repeater will cause any header and footer HTML that is in the repeater to show up even though no items are repeated. This may be what a user wants, but often that is not the case and by not binding a repeater, you'll be ensuring that none of the HTML in the repeater will show up on a page.

3. Ensure proper null checks before accessing an object

To do this, the first thing you should check, with any variable or method, is to determine if the resulting object is null. As a rule, if an object is not initialized, it will be set to the “null” value. Many methods will also return a “null” value if certain conditions are not met. Trying to use an object which has been set null generally results in a run time exception that will cause your website to crash (sometimes gracefully, sometimes not), so ensuring that you are aware of the characteristics of your variables is paramount to good development.

4. Be cautious about HTML generated in backend code

Generally, .ascx files contain HTML which dictates the physical layout of the page, while the .ascx.cs files contain code that populates the layout. Though the general rule is to make sure not to include any HTML in the backend code, there are situations where this method can solve certain issues. The biggest thing with this law is to be aware of what's being used where to ensure that you have an understanding where the results are coming from, either HTML or backend code.

5. Don't code after return statement

Though this one definitely depends on both the situation and your own preference (some people prefer conditions do have a single, standalone return statement at the end of the method) not coding after the return statement is common. If you are trying to simplify multiple bracketing, this is a good option.

6. Before deploying, check commands to ensure a successful Page Editor user experience:

  • Add a component to a page without a data source
  • Add a component to a page and point to an existing data source item
  • Add a component to a page and create a new datasource item for it to use
  • Remove the component from the page
  • Remove/add child items from the component if it is a container component

7. Ensure that all Sitecore fields that require a datasource are properly set

If you have any fields that point to a list of items in Sitecore (or part of the Sitecore content tree) for which you require population from a datasource, ensure that you have correctly configured the datasource to allow a content item to have "valid" values to choose from when accessing that information.

8. Use the Sitecore debugger to find performance issues

Though its use may depend on the type of contract you have with a client, if the budget and time allow, testing out a variety of scenarios, both positive and negative, will help in delivering a thoroughly tested, and ultimately superior, product.

9. Choose icons that correspond to your content types

This one goes back to creating a positive user experience for the content author. By choosing unique and logical icons or icon groups for related items (news, news folder, news listing etc.) you will give them a visual indicator for what type of page or component they are looking for. Sitecore has a number if built in icons. To select one for a page, simple double click on its associated icon in the content editor.

10. Use default standard values (most of the time)

Using standard values to populate certain fields can be a way to make life easier for your content authors, but make sure to thoroughly consider the choice before deciding that's the way to go. Sometimes there will be cases where the process requires a content author to select a value with a possible required validation rule. In those cases, if instead a standard value has been chosen, the content authors will be less likely to reexamine and fill in the value correctly, since it will already appear to be full (with the standard value which may not be what they wanted in the first place).

11. Provide field-level help for your content authors

For each field of a template in Sitecore, a line of text can be added to give a content author more information about what the field should contain and how it should be used. While this can be a pain for developers to fill in and become redundant once a content author is experienced in content creation, it’s still a good practice to help new content authors, or for fields where the content or use of the field is not intuitive.

12. Include real-world content into testing to make sure everything is working as it should

Depending on budget and the type of contract, including some real-world content into your testing should be standard across all projects. Having an ample amount among your pages will help in analyzing the performance of the site, while also testing pagination and ensuring that specific features like sorting function correctly. Other suggested site content includes: image sizing and language variants to ensure that the layout of the pages remain viable. What other Sitecore laws do you abide by when developing? If you enjoyed this post, make sure to check out these other technical Sitecore articles:

  • Overcoming 2 common Sitecore page editor challenges
  • 3 steps to customize your Sitecore security access ribbon buttons
  • Customizing Sitecore's rich text editor for better usability
  • Sitecore developer resource: Timed publication using publisher restrictions