The dot notation breaking change
In Magnus's blog post (http://world.episerver.com/blogs/magnus-stalberg/Dates/2016/9/planned-breaking-changes-in-cms-ui-2016/) on the upcoming breaking changes in the CMS UI, there were a lot of questions and a little confusion about the removal of dot notation support. I am hoping that with this blog post I can shed some light on the matter and make things a little easier to understand.
The history
When we first released the updated UI back in CMS 7, we were using a version of dojo that had its own synchronous loader which used dot notation, the syntax looked something like this:
<script type="text/javascript">
dojo.require("dijit.Dialog");
var dialog = new dijit.Dialog();
</script>
When we updated to CMS 7.1 we also upgraded our dojo dependency. However dojo had changed its loader to be asynchronous and use the AMD format. This format uses slash notation since each dependency is a path to a JavaScript file. It looks something like this:
<script type="text/javascript">
require(["dijit/Dialog"], function (Dialog) {
var dialog = new Dialog();
});
</script>
To ensure the change wouldn't be too breaking we added code to maintain support for the dot notation.
The breaking change
In the coming CMS 10 release we have removed the support for the dot notation in the JavaScript loader. So this means that anywhere were a JavaScript file is referenced in the code it should now use slash notation (that is forward slashes).
It is also important to note that we have been using the slash notation since CMS 7.1 so you don't need to wait for the CMS 10 release to change your code. You can change it now!
The effects of this should be very limited since there are not many areas where the dot notation could have been used. Here are the places that you should check in your code:
PropertyFor: It is possible to pass an additionalViewData argument to the PropertyFor method.
data-epi-* attributes: Any epi attributes that you manually render in your views.
Widget templates: The data-dojo-type attribute in widget templates.
Initializer class in module.config: It is possible to pass an initializer JavaScript file to the clientModule element in the module.config, for example:
<clientModule initializer="addon/Initializer">
</clientModule>
ComponentBase: Any class inheriting from ComponentBase that sends a widget type to the constructor.
ComponentDefinitionBase: Any class inheriting from ComponentDefinitionBase that sends a widget type to the constructor.
EditorDescriptor: There are several properties on the EditorDescriptor that could be affect but the most likely is ClientEditingClass.
ViewConfiguration: The properties ViewType and ControllerType.
Thank you. I was definitely the target audience for this post :)
Yes, thanks for that - really clarifies things.
Great summary of valuable info!
Great post! Thanks
Great post!
Another place to check is the EPiServer.Shell.ViewComposition.ComponentAttribute and it's WidgetType property