Archive for category Glassmapper

EditFrame and Experience editor buttons are both great ways of adding experience editor support to our Sitecore pages.

EditFrame buttons

Create item in core database (I usually just duplicate the Default folder at /sitecore/content/Applications/WebEdit/Edit Frame Buttons/Default). You can add the field(s) you want to make editable in the ‘Fields’ field

In your view, you need to wrap the html that you want to make editable, with the EditFrame code, where you need to supply it with the path of your edit frame button in core, and the item ID of the item you want to edit. The fields made editable would depend on the fields you include in the EditFrame button item as shown in the above image.

In your rendering, select the button you just created in the ‘Experience Editor Buttons’ field

The additional button you created will now be available when you select the entire rendering. If the datasource is available, that item is considered for editing and the field name mentioned in the experience editor button item in core is searched for in that item, else the context item is considered for the same.

Points to note about these 2 implementations:

EditFrame Buttons

Experience Editor Buttons

Providing fields to edit

Pipe separated – In the core item for the button

Pipe separated – In the core item for the button

Item to be edited

Item id passed in, in the view code

The datasource item is used if available, else the context item is used. This is irrespective of whether the fields mentioned in the button item exist in the datasource item.

Code change required

Yes, code needs to be added in the view as shown above.

No

Html to be selected

Only the html around which the EditFrame code is wrapped needs to be selected to see the button.

The available buttons show up when the entire rendering is selected.

Flexibility

You can choose to edit any number of items selecting any single html tag as is the requirement.

Only 1 item can be edited per rendering (datasource or context item), and individual html elements cannot be selected to see the button(s).

The bLazy Plugin provides us with a great way to implement serving up resized images based on the current viewport, and additionally it also allows us to lazy load images on our site, drastically reducing the page size and download time.

We used bLazy for img tags – and also for other tags (where it simply loads up the image as a background image).

We created a few glass HTML helpers here to help us maintain consistency and increase maintainability by having this html present in only 1 place in the site.

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.

In today’s world of multi-sized devices / screens, responsive design is almost a must for trendy websites.
The <picture> tag provides a nice solution to the need for serving up resized / different images based on the viewport / orientation of the client screen.

This allows us to efficiently use bandwidth and serve up appropriately sized images based on the screen size AND pixel density. In addition, we could also use different images altogether based on the viewport.

In one of our Sitecore projects we extensively used picture tags. We used it in tandem with the Sitecore Image Processor Module to resize images based on view port. In our solution, we didn’t make any changes based on screen orientation (which is definitely an option too in the picture tag). We served up differently sized versions of the same image based on the viewport.

We created a glass html helper method to help render the picture tag for a given sitecore item field, passing in the max size of the image per breakpoint.

You’ll note that we have an additional line in there to allow for page editor support! So in page editor mode, we would render this as a regular img tag.
Additionally, we had multiple instances where the design called for not showing a particular image in the mobile view at all. To support this, we also added the ability to pass in a token which signifies that a given breakpoint url needs to be blank.

Please note, the List takes the dimensions in the order: Desktop –> Tab –> Mobile.
You could ofcourse choose to be more explicit and have different parameters for each breakpoint.

In our project, we also had to support IE, so we used PictureFill as well, and you’ll see that the output html also outputs a video tag around the picture tag for IE9 as is needed to support the browser.

Additionally, we also had to render certain images on our site, which were not a part of a sitecore field. A good example of this, would be using an existing image repository for say product images, or user uploaded images which we store in a different location. For this we utilized the following code, which takes in an image url and a set of dimensions and builds the picture tag for you:

There are 2 underlying methods here which actually build the url for the resized images. For images in Sitecore, we used the Sitecore Image Processor Module. Going through the documentation, you’ll see that all we need to do is add the querystring parameter ‘usecustomfunctions’ to kick off the Image processor module resizing. So here’s the method we used:

For external images, we ended up writing out own code to resize images. You’ll see, we also added an additional control to determine the quality of the resized image. You could also choose to build out your own image resizing module with this code.
We used a http handler for this, and made it asynchronous, so that the image resizing happens asynchronously!

So the method we use to get the resized url basically created a url to the http handler, passing in the width / height parameters:

When a content author enters decoded symbols in single line / multiline sitecore text fields, the symbols don’t get encoded on their own on the site when we output them with @Editable (Glass method – supporting page editor mode).
This also applies to links rendered using @RenderLink (Glass method)
This would mean text like &reg; and &trade; getting output in place of ® and ™ respectively.

Sitecore text fields DO support these symbols being pasted on to them directly, but sometimes it is not a choice we can make, especially if we have items created and prefilled automatically through external code / a connector to a third party system etc.

To achieve this, we create a new class inheriting from the GlassView class, and create Editable / RenderLink methods which use the respective base methods, taking care of the HtmlDecode!

Transform File (glassv3header.tt) – for the common header and will appear only once in your generated code file – this includes the namespace using statements / base interface / class for all models.

Base Project Transform File (glassv3item.tt) – The other template file will be used in a repetitive manner for every item that code (class / model) is generated for.

In addition to this, we also use the Code Generation Template (itempaths.tt) file to generate item properties for any items we would want. The properties generated per item, is again decided by the template file itself, but out of the box, contains properties such as the item id, item path, template name and template id.

Add TemplateId to all codegen classes

One thing we noticed right off the bat, was the lack of a property for the template id in the models! We needed this for many situations, like deciding a separate html rendering based on the template id of the item etc. So we updated the t4 template (glassv3header.tt) to include the template id for every model, including the appropriate sitecore attributes on them to get them to populate as expected. (line below)

Item Name vs a Name field

The header template for the common code for your code gen file, has a property mapped to the item name ‘Name’. We came across a situation where we were working with Sitecore Commerce Connect templates, and the main product template there had a Name field. When we tried generating code for that template, we ran into conflicts! We couldn’t change the name of the field in the Commerce Connect template, so had to update the t4 template (glassv3header.tt) instead to change the ‘Name’ property to ‘ItemName’ (line below)

Error with codegen for System Language template

When we tried adding the sitecore system template ‘/sitecore/templates/System/Language’ into TDS and generating code for it, but we again ran into conflicts here! This is why we again updated the t4 template (glassv3header.tt) to explicitly specify the namespace of the Language property. (line below)

Add a new sitecore field type to enable codegen create the right custom field property types

For various reasons, we have had to add custom fields in Sitecore. For these new fields, by default glassmapper will general Object properties unless we provide a hint to the type of data this new custom field will contain.
For example, the Single Select with Search, Single Select Tree fields are link fields and contain a single guid, while Multisite Multilist with Search is a list field and contains a list of guids. So we need to map the intended property type in the GetGlassFieldType() method of glassv3item.tt template file:

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.