(Theoretical) Transformable Widgets in Kentico 12 (MVC)

Hey everyone, I have some great news!  Firstly, as you may have already seen, the Kentico 12 Beta is out to download and install.  This features their first run at expanding the MVC capabilities of Kentico to include widget zones and widgets in your MVC Views, giving users the ability to enter free format content in what otherwise would be very strict structured pages.

IT IS IMPORTANT TO KNOW THAT THIS IS A BETA, AND THIS ARTICLE IS BUILDING ON BETA FUNCTIONALITY THAT WILL PROBABLY CHANGE, SO IT IS JUST FOR FUN!

The basics of widgets within Kentico’s MVC implementation are as follows:

1. Add a Widget Zone to your View
2. Create the Model for the Widget (Properties Model and View Model)
3. Create the View for the Widget (including an Edit Mode portion)
4. Create Inline Property Editors (Model, View, and a well formatted Javascript method)
5. Tie your Widget Properties to the Inline Property Editors, so you can edit your widget.

Now if you want an in-depth article on how to do all of these…sorry!  I’m sure the other Kentico MVP’s are going to be all over that, so I’m going to taking a different route, and I’m going to first assume that you’ve checked out the demo/other articles.  What I want to get into is how I used the current beta Widget system to re-create one of my favorite tools: The Transformable Webpart widget.

What’s the Transformable Webpart/Widget?

If you are asking this question, then you really need to drop everything (unless you’re like, holding your child or pet, don’t drop those), and head over to my Resources Section.  The Transformable Webpart was a tool I created that allowed users to create custom structured Webpart/Widgets without needing to touch code.  It takes the properties you define and simply passes those values into a Transformation, allowing you to easily create structured content web parts and widgets for users.  And since it uses Transformations, if the output ever needs to be modified, you don’t need to do it in code, you can simply re-arrange the elements in the transformation (very similar to Email Widgets).

Why would you want that for an MVC widget?

To me, a CMS is meant to make managing web content easier and less annoying, and nothing says annoying like needing to tell a customer "oh you want to move this over here?  I need to go into code, change it, and then push it," or worse yet, if you don’t have the files handy "oh, and I don’t have the current version, so I need to download it from your repository."

While the widgets within MVC would allow more free-form elements, reducing the need to ask a developer to code in any new piece of content, it still currently has hard set views for your widgets you create, meaning you need to go into code if you want to alter how your widget renders its content.

I want to, as much as it’s in my power, move management of content to the CMS, and less in my sore fingertips.  So, with this tool, once you set it up and define your properties, you can manage the output of your widget through Kentico’s Transformations and can adjust it through the cms instead of in your views.

How does it work?

Glad you asked, or well…I asked for you, but I know you wanted to ask that question, I’m psychic.

First let’s take a look at the original Transformable Web Part.

The Original!

The original leveraged the WebPartInfo.WebPartProperties XML configuration to detect what properties the web part has, then retrieved those properties through the AbstractWebPart’s GetValue(“ColumnName”) to grab the values.

It then created a DataTable with the property values being the column names, then adds a row with the actual values of each of those properties, and then finally passes that DataTable as the DataSource for a Repeater, which would transform that object just like you would if it was a Repeater with Custom Query.

The Difference!

Well, as you probably know, MVC is not web forms, so we don’t have Repeaters anymore to work with.  We also don’t have a the WebPartInfo class…nor the GetValue() method.  But what we do have, are the Widget’s Property Model, and we have the Macro engine! 

How does that help us?  The Macro Engine pretty much is just a gigantic nested dictionary of Fields/Values (and methods of course), similar to how a DataRow has Columns (Fields) and Rows (Values).  When you render a macro statement, it processes the macros using the Macro Resolver’s properties. For instance, the Macro’s "CurrentSite" object has the properties of SiteName, SiteContext, etc.  And if you render

It will give you

Along with the properties and methods that are normally available, you can define macro values dynamically, adding them with the method MacroResolver.SetNamedSourceData(string, object).  Like this:

I have now defined {% Value1 %} as "Hello" and {% Value2 %} as "World!" in my macro resolver.

Now, if I were to render the macro statement:

 using my Macro Resolver, I would get "Hello World!"

The last step is to get the statement to resolve from somewhere in the CMS so it’s easy to change, this can be done through grabbing the text from a Text/XML transformation.

Let’s put it all together!

So by defining my Widget’s properties, then adding those values into a MacroResolver, and grabbing the text of a Text/XML Transformation from Kentico, we now can render the widget however we want, and change it through Kentico without having to touch it.

Current Limitations / Issues

Now while my Portal Engine version of the Transformable Webpart can be leveraged without touching any code, as of the Beta of K12, you will still need to define your widgets in MVC.  This means setting the model, controllers, views, inline controls, etc.  But the main thing is once you do define your properties and set things up, you can control the output of the results within Kentico.

As noted multiple times in this article as well, this is all theorizing on a piece of functionailty that is in Beta, so this entire article could become obsolete come launch.  But it's a good mental exercise on thinking outside the MVC box and in the Portal box.

Give me the code!

One more "sorry" to provide.  Since this is in Beta, it wouldn't be wise to provide code as it will probably change.  But once K12 actually launches, you know I'll be updating my existing tools, and looking to migrate whichever tools i can into the MVC Portal Widget model, including the Transformable Web part.

Final Thoughts

Right now the MVC widget functionality is in it’s infancy, and I can bet that over the time the Kentico team will further improve it's functionality, perhaps a better method will be created for managing the widget properties.  I’m thrilled that they are working on adding portal functionality to MVC, and I’ll continue to blog on more tools and methods once it launches!