Validation Summary for Optimizely Forms in Non JS Mode

I recently wrote an article on how to create a Validation Summary for Optimizely Forms. The approach described in that article uses Form Client Events and Javascript to add a validation summary to the top of the form. That method is dependent on Javascript, and Forms must operate in JS mode for it to work. This article provides a different solution for use with Optimizely Forms with workInJonJSMode enabled.

Optimizely Form Container Block with Razor View

With CMS 11, Optimizely Forms display using a traditional Webform User Control (ASCX) out of the box. With all the work I have been doing with forms lately I wanted to change this behaviour to use a Razor View instead. Now that I have it working, I wanted to share it. 

Take note: as mentioned this only applies to CMS 11. With the release of CMS 12, Optimizely has rewritten Forms views to now utilize Razor, and all this work is not necessary.

Custom Optimizely Form Containers - Put the View Where You Want

Most instructions for creating a custom form block in Optimizely follow the same approach. My problem with the typical approach is that it requires a folder structure that doesn't match my solution. I use a slightly different method to allow me to move my Form Container Block rendering to my choice of folders.

Validation Summary for Optimizely Forms

I have seen requests for a method to implement a Validation Summary for Optimizely Forms, and I dealt with one myself. If you're not familiar with the idea, a Validation Summary includes all the validation messages for form fields in a summary section for easy review. This is typically found at the top of the form after you try to submit. There is no option for this functionality out of the box with Optimizely so I put it together.

The Problem with Nested Blocks and AdditionalViewData

It's not uncommon to nest blocks in Optimizely to create more controlled and complex layouts on pages. It's also sometimes necessary to provide additional data to the blocks you render. When using the PropertyFor helper this is done by specifying an additionalViewData object. However ViewData persists to nested views and this can mess up your layout. This is how to identify when this happens, and how to work around it.

Moving the DisplayTemplates Folder

Optimizely uses DisplayTemplates to provide a way to render different partials for data types. DisplayTemplates are native to ASP.Net MVC, though, and Optimizely builds upon them, for instance, by specifying a Tag. An example of this is the rendering of ContentReference properties in my articles here and here. The MVC engine defaults the location for them to "Views/Shared/DisplayTemplates". Sometimes, though, it's convenient to reference different locations, and this is how you can do that. 

Rendering ContentReference With Shared Views Using a TemplateTag

ContentReference properties provide a way to select a single item in Optimizely CMS when you don't need the featureset a ContentArea provides. However, rendering an item with a ContentReference is a bit different. I explored this a bit in my article Rendering ContentReference Properties. This post expands on this with a single DisplayTemplate that works for most content types. It builds on a similar technique using a ContentReferencePartial, and adds additional functionality using a TemplateTag.