This post show some of the new goodies we Sitecore developers get when working with Sitecore SPEAK 1.2 and Sitecore Rocks compared with the previous version of SPEAK.

Strongly typed View Model

In SPEAK 1.1 there was a lot of plumbing work you had to do almost all over the place.

In your cshtml view you first had to get the user control from the Sitecore Mvc RenderingModel. Then you could start building up your view by getting the rendering parameters from the model by calling various Get methods with loosely typed parameters.

The below code shows an example from one of previous posts.

It was also necessary to explicitly set what scripts and stylesheet the view required even though the SPEAK guidelines made you place the files in the same folder with the same name as the cshtml file.

Now in 1.2 your model class is derived from a base class called Sitecore.Mvc.Presentation.SpeakRenderingModel instead of the Sitecore.Mvc.RenderingModel.

The SpeakRenderingModel base class ensures that a js and a css file with the same name as the rendering is written as attributes for Require if such files exists. So no more requiring the scripts explicitly as long as you stick to the SPEAK naming convention.

You should note that the SpeakRenderingModel  sets the require category to “client” which means that when you place your code in a different location you should either set Model.ScriptCategory to your own category name or make sure that the extra folder you patch into the resolveScript pipeline is in the “client” category.

Besides being derived from SpeakRenderingModel your new 1.2 model class is now auto-generated as a partial class by Rocks so you get all the fields from your rendering parameter strongly typed.

How to: Auto-generate your strongly typed View Model with Sitecore Rocks

Sitecore Rocks has a new menu button for auto-generating your SPEAK view model from Rendering parameters.

First you of course need to create your rendering for your component.

Before you create your component then create a folder with the same name as the component that you are about to create.

Always create a designated folder for each of your components. This is a lot cleaner than having a lot of different components cshtml, js and styling all in the same folder. So I repeat, always create a folder specific for your component.

When you’ve created your folder then right click on this in the Solution Explorer and click Add -> New Item -> SPEAK 1.2 -> SPEAK Component.

Choose where to place the rendering item in Sitecore, also here remember to create a designated folder for your application and place the component rendering in a renderings folder beneath the application.

Now locate the generated rendering in Sitecore Explorer, right click and select Create SPEAK Parameters template

Define your fields in the Parameters template and save.

Now right click the rendering again and  choose Create SPEAK View Model.

This will generate a partial class from the rendering parameters similar to the one shown below.

If you change your Rendering parameters then simply click on Create SPEAK view model again and the file will be updated.

I love this, no more plumbing code for getting the model and Sitecore hooked together, so easy.

Assigning model attributes

In SPEAK v1.1 your fingers would almost be bleeding from typing by now but you hadn’t even started to write the client side code. And then each time you should get or set a model attribute in JavaScript then you again had to call loosely typed get and set methods on the component model as shown in the code below.

But now the model attributes client side are strongly typed as well. So in SPEAK 1.2 you would simply write

The old get and set calls still works fine so if you are already too used to these or are using some old code it is still all good.

It is so perfect that all the plumbing code now is generated. This really reduce the overhead when creating a new SPEAK component. But what is even better is..

You can use TypeScript!!

Yeah.

If you want to use TypeScript for your component then add your new component using the template called SPEAK Component and not the SPEAK Component with Javascript.

When you’ve made your rendering parameters template and generated your view model then you can right-click the rendering and pick Create SPEAK TypeScript file.

This will auto-generate a TypeScript class similar to the one shown below.

If the rendering parameter template changes then you can just click Create SPEAK TypeScript file again even though you probably have written your own code within the TypeScript file.

The generator will only replace the code within the Public properties region when the file exists already.

You also need to reference the Sitecore SPEAK typing in your project if you want to use TypeScript.

The typings definition file is called Sitecore.Speak.d.ts and is located under <website>\sitecore\shell\client\Speak\Assets\lib\core\1.2

You can either reference it from each of your TypeScript files by placing a reference in the top of the file as shown below.

But this can be a bit messy and redundant depending on where you have placed your project. The relative path can be quite long. Another approach is to simply add the existing file to your project and voila you have type safety without referencing the file everywhere in your code.

On the above image I simply placed the typings file in the root of the project but it can be placed anywhere within the project. Note that this approach will not get the file updated when Sitecore is updated.

Do not fear TypeScript

You should not fear TypeScript, if you are a C# developer you should rather embrace it. The extended JavaScript syntax is easy to learn and there is a lot of great material out there so Google will help you to get started and you will be coding TypeScript within minutes. The learning curve is not steep at all. You should also read my post on 3 reasons why TypeScript is brilliant if you are not completely convinced yet.

There are of course more good stuff in the new version of SPEAK so more posts coming up. It is so much quicker to get started and the amount of plumbing code required to get things running is reduced dramatically.

My next post on SPEAK will introduce the bootstrap component library made by Jakob Christensen which really shows how relative easy it is to make your own component libraries.