Archive for category MVC

Note: This module has been created as a package and is available for download along with the complete source code at Git: aceanindita

Sitecore being component based as it is, adding start and end comments to your views can be immensely helpful while debugging issues, especially if they are being worked on someone who doesn’t know the project from Adam.

Hardcoding the start / end comments isn’t a great idea for obvious reasons like being prone to developer omission in some views, refactoring / file renaming concerns etc.

In an earlier post I had shown how we had partially resolved this by making the build up of the comment dynamic using a html helper method which used the WebPageExecutingBase.VirtualPath property from the System.Web.WebPages assembly.
You can refer the post here: Using dynamic view markers in Sitecore MVC

In this method, you would need to manually wrap each of your views within a call to the said html helper method, which would dynamically include the current view path in start and end comments around your view. While this did away with the potential issues that might come out of refactoring like changing folder structures / renaming files, it still didn’t deal with the dependency on having the developer(s) remember to add the call to this html helper in every single view.

Here’s a solution for this, we added a new processor in the mvc.rendering pipeline, before and after the call of Sitecore.Mvc.Pipelines.Response.RenderRendering.ExecuteRenderer which renders the actual rendering html.

Note we have 2 additional settings here. ‘RenderingsMarkerModule.Enabled’ lets you toggle the rendering of comments on and off – this could help you turn of this rather revealing feature on staging / production. Additionally you could toggle ‘RenderingsMarkerModule.ShowLayoutMarkers’ to show / hide comments before & after your layout. It is recommended that this remain off, since having your html response start with a html comment might not always be favorable.

Here’s the code we have in place:RenderingsMarkerModule.Pipelines.MVC.RenderingMarker.RenderMarkerStart

However, this will not apply to rendering parameter templates. Since while selecting the rendering parameter values in the presentation of an item, the context item is the rendering itself and not the item on which the presentation is being set.
So if we were using a common rendering parameters template for items in multiple sites, we need to rig something up, so that the options appearing in the link / list type rendering parameters show options from the respective site node.

As an example, consider a rendering parameter template, with a background color field.

This rendering parameter is set to a shared rendering which is used on multiple sites. However, each site has its own unique list of background color options.
To solve this issue, we needed to add support for the token like $sitenode in the example above.

The handler code we write, replaces this token with the right path, after identifying which item the presentation is being set on, and then identifying its sitenode ancestor.

This extension is then added to the regular Droplink field. The logic outlined above will kick in only when the current item has the template: /sitecore/templates/System/Layout/Rendering Parameters/Standard Rendering Parameters as its base template. Which would ideally apply to all rendering parameter templates.

Now the ‘$sitenode’ token would get translated as per the logic added in the above code to the respective site node.

When using the salesforce connector with Sitecore, we came across the need to store user profile images as well in salesforce.
Once the connector is set up (which includes setup in Web.config / Domains.config and S4S.config), any user user profile interaction automatically happens with salesforce, and fields which are mapped in web.config with corresponding sitecore fields – will automatically get mapped / updated on these interactions!

The special case we came across, was with Profile images. Our site allowed the user to upload profile images, which we needed to store in salesforce, and additionally also wanted the image to show up in sitecore.

The solution we came up with, was to create a document folder in salesforce and upload all profile images there with the contact id as the file name as a document, and then store the url in the Sitecore user portrait field.

Once the document is added in salesforce, the document url will give you the base document url of your salesforce instance, which you can use and replace the intended document id to get the right url for each new document created. This is what the S4SHelper.GetDocumentUrl(documentId) method does.

While working with Sitecore, we add many renderings in the presentation and that makes up each page that is output for the corresponding item.

We are currently working with Sitecore MVC, and we have traditionally added start and end comments in views manually (copy pasting the path of the current view) to mark the start and end of each component on the page. This helped us debug things, made the output html more readable and maintainable, and lets face it, after a month or two, we find it hard to remember which module was called what!

Recently it was pointed out that this might be a potential security threat and we are exposing details of our folder structure in the production environment, which might not be the best idea.

So to ease the process, and remove this potential threat, we created a html helper extension method which would dynamically output the view path start and end comments subject to an appsetting value being toggled to true. This appsetting key would be toggled to false in any environment where we wouldn’t want the comments to be output!

While using Sitecore with Glass.Mapper, we can render General Link fields on our views using the GlassVire.RenderLink / GlassView.BeginRenderLink helpers.
However, when we have an item or a collection of items – and want to render a link to the item itself, we usually resort to

<a href="glassItem.Url">glassItem.Title</a>

In our case, we wanted to build in additional logic which needed to get executed every time we render a link to a given item on our site.

In our company we follow a certain pattern with items, something I am sure everyone follows themselves. And as a part of the standard set of base fields that every navigable item in sitecore has, we have a Navigation Title and a Redirect Link.

A Navigation Title serves the purpose of letting the link text to an item rendered anywhere on the site to be managed separately from the item name / headline itself. You might want a shorter title to links to a page, while the headline of the page itself might be more descriptive. So when we use GlassView.RenderLink – we would like the provision to fallback to this Navigation Title field if no description is manually managed by the content author.

A Redirect Link serves the purpose of allowing the content author to temporarily or permanently having an item redirect to a different page (internal or external). In case of external links, this method basically allows us to have placeholder Sitecore items for external links too! Which is especially useful when we want them to show up in Content Tree Navigation renderings. The Redirect Link is at the end of the day a link field. If the content author wanted the external link set in this field to open in a new tab (considering its an external link!), GlassView.RenderLink wouldn’t know to make this happen since this is custom logic we wanted in place based on our custom field. So we needed to make an update to GlassView.RenderLink – to be able to honor the redirect targets as well.

So in this case, we created HTML helpers to render anchor tags to glass items, to take into account the Navigation Title and the Redirect Link on the item.
Please note: we use the Base_Navigation class here as the type of object, this is a custom template – in our code, which has the basic navigation properties which are a part of every page item. This includes the Navigation Title and Redirect Link.

While using Glass.Mapper with Sitecore MVC, we come across the need very often, to check whether a given field – a link or an image / a video is valid or not.

This would be most necessary in views – where we might not want an empty anchor tag, or a a container html tag to show if the contents were empty. The container tag might have certain CSS associated with it, padding / margins – which might break the design, were the contents empty. We might also have js set to run based on the container tag / classes set on them – which we wouldn’t want running if the contents were empty.

We created extension methods to make repeated checks for validity a little easier.

In our project, we came across a requirement where the content author wanted to manage text with highlights, and we also needed to be able to truncate this – to show as teasers in certain locations – to maintain the integrity of the design.

We initially thought of Rich Text fields – but then the business need was to ONLY allow highlighted text as special formats – and nothing else. And this was only for certain fields – so we certainly didn’t want to restrict the rich text editor itself either. Additionally allowing full blown html, made the truncation bit a little dicey.

So here’s the solution we came up with.

We picked a custom tag and had the content authors enter the text with those tags. For example, for the above image, the content managed in the sitecore field (single line or multiline – plain text field) was: [highlight]Test[/highlight] caption with [highlight]highlight[/highlight]

While rendering this field on the view:

In the above example, we not only transform the input text to include highlights, we are also keeping in mind page editor support, and further – we also limit the output text to a certain character count.

Ever hand to deal with html which is just not compatible with the tags that glass html helpers render for you?
And in these occasions, it pretty much seems like you are going to have to say bye bye to page editor support!
EditFrame is the answer to your problems.

This is definitely not a new concept and existed in the asp.net version of sitecore libraries too.
In this post, I will demonstrate how to get this set up in your MVC site (with glass mapper).

EditFrame basically lets you make any html page editor friendly. All you need to do, is tell it which item and which field / set of fields you want to associate with the given html.

There are 2 parts to setting this up

Create items with the fields you want to add support for specified

Add the corresponding code – passing in the item which needs to be made editable, wrapped around the html which will be editable

In this example, consider a simple Product template, with a multilist field ‘Categories’

Core Items

In core database, under /sitecore/content/Applications/WebEdit/Edit Frame Buttons, add your field, making a duplicate of the /sitecore/content/Applications/WebEdit/Edit Frame Buttons/Default folder for convenience. This will bring over with it the below items.

The title and tooltip in the above screenshot will correspond to the title and tooltip of the edit frame in page editor mode when you select the editable target html.

You can then specify the fields for which you would want to add page editor support. In this example, I have mentioned only 1, but as mentioned below, you can add a pipe delimited set of multiple fields.

Another great advantage of this approach, of separating the fields from the items / templates here, is that you can create a single folder for common fields like say Background Image, Products, Featured Links etc, which might be reused over multiple templates!

So now in the code, you need to create the frame tag and pass in the path to this folder we created, along with the item which needs to be editable.

Many a time, we come across the need to customize our urls in sitecore.
While doing this would definitely need overriding the item resolver in sitecore, additionally we use MVC routes to be able to define the route structure we need.

In our project, we found this especially useful for bucketable items and also certain special / listing pages – where we used the JS History API to account for paging / sorting filtering and the likes.

Consider the scenario of bucketable product items:

Now, we would definitely not want the product url correspond with the sitecore structure as shown above. It would be more likely that we would want the product url to perhaps embed a super category name, a category name, and may be a sku along with the product name itself. In this case, we will implement custom routes and also override the sitecore item resolver and link provide to make the circle complete.
This kind of implementation will also let you have separate presentations on every item if you wanted to, as opposed to the approach of using sitecore wildcard nodes where the presentation couldn’t be updated by the content author for individual items.

Now you will need to add to the httpRequestBegin sitecore pipeline – a new itemresolver pipeline where you need to add the logic to identify the item from the route you just created above.
Basically, for any product, if you were to get the identifiers that were declared ({supercategory},{category},{productname},{sku} in this case), the code which fetches the corresponding product item from sitecore based on these identifiers, needs to be in the itemresolver code.

In this case, we will assume that the sku is a unique identifier for a product.
Note: If you are using an item name as an identifier, you will want to ensure that the item name is unique for the template you are searching for (in the location you are searching, if it is not the entire tree). It would be best to ensure that the item names are unique in this case, in the scope you will define for the item search. You could use this post, to ensure this and add a constraint to this effect: Unique item name constraint using index search in Sitecore.

In addition to this, to complete the circle here, you will also want to customize the your sitecore link provider here. This is so that the product urls when requested from the LinkManager are returned in the format you want it to, instead of the one corresponding to the sitecore folder structure (buckets in this case)

So this should allow you to use product urls like the one below throughout your site.
Note: you are defining the custom route in a single place (in the RegisterRoutes method above), so this is a clean approach as well!

In addition to the above, you might also come across random scenarios where implementing custom routes may be a great idea. If you decide to use the history api to manage interactions like sorting / paging etc, to support maintaining listing states on page refresh, you will need custom routes implemented.

An example of this scenario, would be a product listing, accessed using yourdomain.com/products.
Say you were on page 2, had sorted by descending order of product name.
And the sameple resulting url would be:

yourdomain.com/products/params/2/ztoa

If you didnt have custom routes implemented, and refreshed the page, you would ideally land on a 404, since the route till ‘products’ corresponds to the sitecore tree, but the remaining don’t.

To get around this, you could use a route definition like:

routes.MapRoute("ProductListing", "products/params/{*args}");

Having a separator string like ‘params’ would be advised here so that the routes don’t interfere with each other.
Also, {*args} will correspond to a variable number of arguments.
You could also fetch the entire string of these variable arguments in your controller action using the method signature:

public ActionResult CustomIndex(string args = null)
{
// args will contain the string after params, in this example '2/ztoa'
// this string could be split and used to return the page to its intended state if required!
}