Umbraco Jupiter Plugins - Part 5 - Surface Controllers
This is the fifth blog post in a series of posts relating to building plugins for Umbraco v5 (Jupiter). This post will explain what a Surface Controller is, what they can be used for and how to create one.
Disclaimer
This post is about developing for Umbraco v5 (Jupiter) which at the time of this post is still under development. The technical details described below may change by the time Umbraco Jupiter is released. If you have feedback on the technical implementation details, please comment below.
Related Posts:
- Umbraco Jupiter Plugins – Part 1
- Umbraco Jupiter Plugins – Part 2 – Routing
- Umbraco Jupiter Pluings – Part 3 – Trees
- Umbraco Jupiter Pluings – Part 4 – Editors
What is a Surface Controller?
A Surface Controller is an MVC controller that interacts with the front-end (or render layer) of Umbraco. An example of a Surface Controller could be a controller that has a Child Action used to display a Twitter Feed, or a controller that has an Action to accept some posted information from a form. Child Actions on Surface Controller will probably be primarily used for Child Action Macros in Umbraco v5.
Since Surface Controllers are plugins, this means that you can create a package that contains Surface Controllers to distribute whatever front-end functionality you like to Umbraco developers. Surface Controllers, just like Tree Controllers and Editor Controllers get automatically routed for you.
Creating a Surface Controller
Important convention: All Surface controller names MUST be suffixed with ‘SurfaceController’. For example, if you are creating a Surface Controller to display system a Twitter feed, you might call your controller: TwitterFeedSurfaceController. If you don’t follow this convention, you’re surface controller wont be routed.
The first step is to create a class that inherits from the base Surface Controller class: Umbraco.Cms.Web.Surface.SurfaceController
The next step is to define some MVC Action’s to do whatever it is you’d like them to do. Here’s some examples:
- Creating an action to partake in a Child Action Macro. To define this is very simple and follows the exact same MVC principles to creating a Child Action… just add a ChildActionOnlyAttribute to your action method:
[ChildActionOnly]
public ActionResult DisplayTwitterFeed()
- Creating a child action to simply be used as a normal MVC child action which get rendered using @Html.Action or @Html.RenderAction
- Create an action to handle some posted form data:
[HttpPost]
public ActionResult HandleMyFormSubmission(MyFormModel model)
- Maybe you’d like to track all links clicked on your page. You could use jquery to update all of your links on your page to point to your custom action URL with the real URL as a query string. Then your custom action will log the real link address and redirect the user to where they want to go.
Plugins vs Non-plugins
A Surface Controller ‘can’ be a plugin, meaning that you can create it as a plugin and distribute it as part of a package. However, if you are creating your own Umbraco website and do your development in Visual Studio like most of us, you don’t need to create a Surface Controller with a plugin definition and install it as part of a package, you can just define it locally just like a controller in a normal MVC project. If you do want to ship your Surface Controller as part of a package then you must attribute your Surface Controller with the SurfaceAttribute, and give it an Id. If you don’t do this then Umbraco will detect that its loading a Surface Controller plugin without an Id and throw an exception.
As a plugin
Standard practice for creating any kind of controller is to put your controllers in the ‘Controllers’ folder (this is not mandatory but a simple convention to follow). So If you’ve created a new project in Visual Studio, you’d create a folder called ‘Controllers’, then create your Surface Controller class with the SurfaceAttribute and an Id:
using System.Web.Mvc; using Umbraco.Cms.Web.Context; using Umbraco.Cms.Web.Surface; using Umbraco.Framework; namespace MyProject.Controllers { [Surface("98625300-6DF0-41AF-A432-83BD0232815A")] public class TwitterFeedSurfaceController : SurfaceController { } }
Because this Surface Controller is a plugin, you’ll need to attribute your project assembly (just like when creating Trees or Editor plugins). You can declare this in any of your classes or in the AssemblyInfo.cs file.
[assembly: AssemblyContainsPlugins]
As a locally declared Surface Controller
This is pretty much identical to the above but you don’t have to include the SurfaceAttribute or attribute your assembly. If you’ve got an Umbraco v5 website that you’re working on you should just create a ~/Controllers folder to put your controller in, just as if you were creating a normal MVC project. Then you can create your Surface Controller:
using System.Web.Mvc; using Umbraco.Cms.Web.Context; using Umbraco.Cms.Web.Surface; using Umbraco.Framework; namespace MyProject.Controllers { public class TwitterFeedSurfaceController : SurfaceController { } }
Using a Surface Controller
The usage of a Surface Controller really depends on what you’ve created your surface controller to do. Probably the 3 main ways to use them will be:
- Create a ChildAction Macro by using the Macro UI in the back office and selecting a child action that you’ve declared on your Surface Controller, then render the macro in your template or inline in the WYSIWYG editor.
- Directly render a child action declared on your Surface Controller by using @Html.Action or @Html.RenderAction
- Create an Html form to post data to an action on your Surface Controller using @Html.BeginUmbracoForm (more on this in the next blog post!)