MVC Forms in Kentico 12 Beta 2

KenticoCMSWeb developmentMVC

You may not be aware, but Kentico 12 is in Beta at the moment. Those who have a Kentico DevNet account and have had a chance to look at it will have noticed and tried out the page builder. What you may not have noticed is that the beta also has taken some of the great features from the page builder added them to a new form builder for MVC.

If you take a look through the Dancing Goat sample site for Kentico 12 at a code level, you might assume that nothing much has changed with forms. In the Contacts controller and view (along with the SendMessage partial view), the contact form is built up using a fairly typical approach in so far the form that the visitor sees is not driven by the definition in Kentico as it might be in a typical portal application using the Online forms widget. The form itself is saved in the Recorded data in the Forms application as you would expect, but for some reason, the Form builder is blank for the Contact us form.

Now, if you're on the beta programme, you'll note that there wasn't really mention of forms in either milestone 1 or 2.  However, back in June, we had the Kentico MVP summit.  This is where the Kentico MVP team head out to Brno and Kentico HQ to meet the team and talk about upcoming features and strategies with both Kentico CMS and Kentico Cloud.  On the last day, there was a great demo of an in-progress piece of work to improve the forms in the MVC development model for Kentico 12.  I think it's fair to say that the MVPs were all quite excited by what we saw.

What does the beta contain for MVC forms?

You may have noticed a tweet from Michal Kadák on July 10 showing an animation of a slick-looking new form builder that looks quite similar to the new MVC page builder.

This new form builder is in the milestone 2 beta release.  I must point out that the version in Michal's sneak preview also appears to be more advanced than the code in milestone 2, but it's still very much worth taking a look at.

As what we have is only a beta and as such is incomplete, you only get a text box form control out of the box in the beta (that being said, you can add your own controls pretty easily if you look at how the text box has been built). At first impression, it looks to have been added after the Contact us form was created and so the form builder doesn't work on that form.  With that statement though, there are two things to note:

1. You can of course still use the Contact us form in the sample application in the way that it is currently implemented, the reason the old form builder no longer works is detailed below.
2. The reason it doesn't seem to work is that the MVC form builder knows whether you're running an MVC application or not and switches to use the appropriate version of the form builder.

If you create a new form, things start to light up though and you get to see what the team have been working on.

How to add a form to your site

Adding a form to your page is relatively straightforward.  As it's MVC we're going to need to put together a model, a view, and a controller.  Adding these to your MVC solution should be enough to get up and running.  Both the model and the view are reasonable straightforward you can see these below:

using Kentico.FormBuilder.Web.Mvc;
using System.Collections.Generic;

namespace DancingGoat.Models.MyForm
{
    public class IndexModel
    {
        public List<AbstractFormComponent> FormComponents { get; set; }
    }
}

@using Kentico.FormBuilder.Web.Mvc
@model DancingGoat.Models.MyForm.IndexModel
@{
    ViewBag.Title = "My Form";
}

<h2>Form</h2>

@using (Html.BeginForm("Index", "MyForm"))
{
    <fieldset>
        @Html.Kentico().FormFields(Model.FormComponents)
    </fieldset>
    <input type="submit" />
}

The controller is a little more involved as we need to be able to submit the form data.  A basic implementation can look as follows:

using CMS.Core;
using CMS.OnlineForms;
using CMS.SiteProvider;
using DancingGoat.Models.MyForm;
using Kentico.FormBuilder.Web.Mvc;
using System.Collections.Generic;
using System.Web.Mvc;

namespace DancingGoat.Controllers
{
    public class MyFormController : Controller
    {
        private readonly IFormProvider formProvider;

        public MyFormController()
        {
            var definitionProvider = new FormComponentDefinitionProvider();
            var componentActivator = new FormComponentActivator();
            formProvider = Service.Resolve<IFormProvider>();
        }

        public ActionResult Index()
        {
            var bizForm = BizFormInfoProvider.GetBizFormInfo("TestForm", SiteContext.CurrentSiteID);
            var formComponents = formProvider.GetFormComponents(bizForm);

            var model = new IndexModel
            {
                FormComponents = formComponents
            };

            return View(model);
        }


        [HttpPost]
        public ActionResult Index([FormBuilderModelBinder("TestForm", "DancingGoatMVC")] List<AbstractFormComponent> formComponents)
        {
            var bizForm = BizFormInfoProvider.GetBizFormInfo("TestForm", SiteContext.CurrentSiteID);
            formProvider.SetFormData(bizForm, formComponents);

            return RedirectToAction(nameof(Index));
        }
    }
}

There are some things to note in here:

1. The term BizForm will never die, it's too much like an old friend now.
2. In the GET Index action, all we need to do is load the BizFormInfo object and then use the implementation of IFormProvider to get a collection of the AbstractFormComponents.
3. In the POST Index action, the FormBuilderModelBinder is used to collect the fields from the form before using  IFormProvider to save the data back into Kentico.

This is a simple implementation an I look forward to seeing how validation etc. might fall into place (assuming, of course, this makes it out of beta).

Controlling your markup

Being MVC, we obviously have much more control of the final markup of the form.  One of the common gripes about the existing online-forms application is the overall lack of control of the supplied markup.  In the beta, the Kentico team have provided a FormFieldRenderingConfiguration object that allows a great level of control for the elements to be rendered on the page.

var myConfiguration = new FormFieldRenderingConfiguration()
{
    ColonAfterLabel = false,
    EditorWrapperConfiguration = new ElementRenderingConfiguration()
    {
        ElementName = "span",
        HtmlAttributes = new Dictionary<string, object> { { "class", "formField" } }
    },
    RootConfiguration = new ElementRenderingConfiguration()
    {
        ElementName = "li"
    }
};

What might need more work?

As I said at the beginning of this post, what we're looking at here is in beta, it's not something that Kentico has highlighted for beta testing for either milestone 1 or 2, but it is in there so you can take a look.  Some key things still need to be worked on (and indeed may already have been completed) and the team know this.  The three things I'd look at for being able to do a more rounded demo for my team are as follows:

Field settings

It's understandable that things are not complete or production-ready.  While the interface to drag and drop fields is looking great, it's clear that the version in Michal's tweet is more advanced than the code that is in the milestone 2 beta.  A simple example is that things like the display name of a field do not yet work (if you try to edit the field in the Fields tab, you'll be disappointed as it will simply stop working).

Validation

With things like the field name, we also have a lack of validation just now.  Again - it's a beta - I'm not concerned too much about this.  I imagine that the changes needed in the forms application are far from trivial.  I'm keen to see how this is approached and how the overall experience between the form settings in the admin interface can be surfaced in the MVC application.

Data protection

With GDPR and data protection in general, there may well need to be more effort here.  As I keep saying, this is a beta; it's not complete and the team are most likely still working hard on it.

Conclusion

I'm really excited to see this in the Kentico 12 beta and am very much looking forward to using it.  As a solution, I think it's going to work really well for marketers and developers alike.  Marketers would be able to see how their forms might work a little better, and the developers will be delighted with the amount of control they will have over the markup.

The UI so far is as clean and as simple to use as the new Page Builder, using a pattern that looks pretty consistent in a number of areas of the Kentico 12 beta.

We wait to see how this might develop as we get closer to the Kentico 12 release.  There are some things I'd like to see here, such as the sections that are available in the Page Builder.  Let's see what happens...