Umbraco

Deep Dive: Block Grid Editor Part 2

Customizing the Block Grid Editor

Niels Lyngsø
Written by Niels Lyngsø

In this article we dive deeper into the features of the Block Grid Editor. You will learn how to implement custom views for your Blocks in the backoffice. This is a powerful feature that can help editors by providing a good representation of the content.

As the title suggests this is part 2 of the series where we dive into the features of the new Property Editor for Umbraco. The first article centered around the basics of setting up Blocks, how to structure a simple editing experience, and how to render Block Grid content. In this article we will continue the work from part 1, so if you want to follow along I highly recommend reading and completing the tutorial in Block Grid editor part 1.

Setting up custom backoffice views

In the previous article, we set up a simple Block Grid and added custom Partial Views for front end rendering.

Now, let’s use these as inspiration for writing custom views for the backoffice. Custom views give you complete control over how a Block is rendered in the backoffice and this enables you to give a better representation of the content.

To get started we will add custom views for the two Blocks and place them in an App_Plugins folder named `MyCustomBlockViews`.

The custom view templates are simple HTML files written as Angular-JS templates. Any HTML can be used, but we will use Angular-JS syntax for data binding.

This is the code for the views:

App_Plugins/MyCustomBlockViews/richTextBlock.html

 

App_Plugins/MyCustomBlockViews/twoColumnLayoutBlock.html

In these two custom views I use the exact same markup as we did in the Partial Views, the difference is in the implementation of data binding and for the Layout Block we’re using an Angular-JS component for rendering the Areas.

In a later article I will demonstrate how using Web Components can save you from replicating the markup between your front end implementation and backoffice custom Views. For these examples, we will be implementing our markup directly in the Angular-JS templates.

Using a custom stylesheet in the backoffice

In order to make things look good we need to add some styling. You can write custom CSS for the backoffice. To keep things simple and consistent we will use the same stylesheet across the front end and backoffice views. This means that we need to reference the stylesheet on the Data Type configuration (in part 1 we created the Block Grid Layout Stylesheet `/css/blockgridlayout.css`

To configure this we add our own style sheet in the `Layout Stylesheet` property when configuring the Data Type:

While we’re configuring the Data Type let’s add the custom views to our Blocks as well.

Click the individual Blocks to edit, navigate to the `Advanced` tab, and pick the custom view.

Each custom view is rendered in a Shadow DOM, This means it is isolated from the Layout Stylesheet and any parent Blocks. This enables us to add styling directly to the custom view, or use a separate stylesheet, without polluting the overall layout. In this case, we’ll keep it simple and use the same stylesheet for both the front end implementation, the backoffice layout and the both Blocks. Therefore I will pick this stylesheet for each Block as well.

When navigating to the Home content node, you will see that the Blocks are now displayed in the same manner as they are on the front end.

To get full advantage of using the same Stylesheet we should remove the inline styling `style="padding: 20px"` and replace it with a class `class="my-rich-ext"`

So the custom view looks like this:

App_Plugins/MyCustomBlockViews/richTextBlock.html

And add the class to the stylesheet `/css/blockgridlayout.css`

We have now ensured the styling is the same across the front end and backoffice.

A few general Angular-JS tips

To get you started on Angular-JS views I have collected a few tips that will cover most basic needs:

You can always use double curly braces to render something: Either in between elements 

or within the element tag:

But if you have HTML as part of that data, you must to use the `ng-bind-html` directive, like we did before:

If you like to have optional attributes, you will do it in this way. Where ‘my-something’ will become the name of the attribute:

That would result in if the value of ‘mySomething’ is true

Getting the source of a picked Media Item is easiest by using this snippet, which can be inserted at any spot and used by markup right after:

Working with Images

In the above tips-section you can see how to get the source of an Image. Lets put that knowledge to good use and add the ability to insert images in the Block Grid.

Head back to the Block Grid Data Type and add a new Block. We’ll name it Image Block and an Image property with a Media Picker. 

To keep the focus on the backoffice I will not write any new Partial Views for the rest of this article, if you like to view these examples on your front end, then the stylesheet is ready but you must write the Partial Views on your own.

For this Block we will create the following custom view:

App_Plugins/MyCustomBlockViews/imageBlock.html

And add some image styling to the stylesheet:

Make sure to pick the custom view and choose the stylesheet for this Block as well.

With this in place our content is now rendered nicely in the backoffice and you know how to add and style custom views for Blocks.

There’s more to come

The Block Grid Editor is designed to be useful out-of-the-box as well as highly configurable and extendable. I hope this has provided you with some inspiration on how to approach customizing the editing experience. All of the above concepts are also explained in the Block Grid Editor documentation, so that's well worth a read as well.

In part 3 of this blog post series we’ll take a look at how we can use the contextual data provided by the Block Grid Editor to inform rendering in both the backoffice and front end. 

Until then - have fun with the Block Grid Editor 🙌