Linus Ekström
May 3, 2010
  5120
(0 votes)

Changes to the EPiServer UI dialog system in EPiServer CMS 6

When an EPiServer CMS editor opens a dialog it is usually done by a JavaScript API called EPi.Dialog. This API is responsible for instantiating  the dialog as well as sending data to and from the dialog. In EPiServer CMS 5 and 6 dialogs are created as new windows that are styled as “pop ups”. This is nothing that the user normally is aware of although a user can close the dialog window with the normal close window function in the web browser.

Inline dialogs vs. external dialogs

An inline dialog is created as a part of the existing page and window but styled to look as a pop up dialog. This means that the dialog is technically the same page as it’s “parent” window. In Internet Explorer 8 new windows are run under a separate thread. This can cause race conditions between script running in different windows. The EPiServer Development Team have spent time addressing bugs that are caused by race conditions when closing a dialog, specially if the dialog has made a post back before closing itself.

Dialogs in the Tiny MCE implementation

In the Tiny MCE implementation in EPiServer CMS 6 external dialogs are used when opening built in Tiny MCE dialogs (for instance the insert/edit image dialog). These dialogs works a bit differently than the rest of the dialogs in the EPiServer CMS UI. For instance, it’s possible to access the underlying UI when a dialog is opened. Please note that this behavior is not intentional.

What are the changes we plan to implement?

To address the race condition problems in IE 8 (and new versions of IE and possible other browsers) as well as creating one user experience for editors when using dialogs we would like to rewrite EPi.Dialog to use inline dialogs. Since we are currently working on upgrading Tiny MCE to the latest version (3.3.4 at the moment) we would like to do these changes as the same time.

How will these changes affect my code?

The hypothesis is that these changes will not affect the public API:s for the EPi.Dialog classes. JavaScript code that is executed in a dialog might be affected if it relies on the knowledge that the dialog lives in a separate window. For instance, a call to window.top will return a different object in an inline dialog compared to an external dialog. Resizing the current window size will also work differently with inline/external dialogs.

We are interested in your feedback

We are normally very restrictive with making breaking changes, but since we believe that very few will be affected by this change we would really like to address these issues. If you know that this will affect you, for instance if you are using EPi.Dialog in an EPiServer CMS module, then please reply to these post so that we can this into consideration before making a final decision.

May 03, 2010

Comments

Sep 21, 2010 10:33 AM

Sounds like a good plan. :-)

I also think that it is important to define clearly what is part of the public API that EPiServer developers can use safely to extend the EPiServer user interface with plug-ins.

If you as a developer in a normal project extends EPiServer user interface you will rely on EPiServer's CSS classes and JavaScript library. It is hard to know what is safe to use...

Linus Ekström
Linus Ekström Sep 21, 2010 10:33 AM

Hi Fredrik!

You have a very valid point regarding what is public or not regarding the user interface. One cause of this is that there is currently not any SDK for the client API:s that is intended to be public. We are currently working on a more streamlined way to work with UI extensibility for the EPiServer product family with more documentation and guidelines for partner developers. We are still very early in this process but be assured that we will write more about this as soon as we have the basics in place and need feedback from the EPiServer community.

Mari Jørgensen
Mari Jørgensen Sep 21, 2010 10:33 AM

Hi Linus!

I think the change is a good idea. :-)

I now there are a lot of modules that are using EPi.Dialog to interact with EPiServer dialogs.
It would be great if the changes could be described in detail, similar to what Henrik wrote when the EPi.Dialog was introduced in EPiServer 5: http://world.episerver.com/Articles/Items/Modal-Dialogs-in-the-EPiServer-UI-for-non-IE-Browsers/

Please login to comment.
Latest blogs
Integrating Searchspring with Optimizely – Part 1: Architecture & Setup

Integrating Searchspring with Optimizely – Part 1: Architecture & Setup

Wiselin Jaya Jos | Mar 20, 2026 |

CMS 13 Preview 4 — Upgrading from Preview 3

This is the third post in a series where I use the Alloy template as a reference to walk through each CMS 13 preview. The first post covered...

Robert Svallin | Mar 20, 2026

The move to CMS 13: Upgrade Notes for Technical Teams

A technical walkthrough of CMS 13 preview3 and headless work: what is changing, where the risks are, and how an upgrade and what to expect

Hristo Bakalov | Mar 20, 2026 |

Customizing Product Data Sent to Optimizely Product Recommendations in Optimizely Commerce

A practical guide to customizing IEntryAttributeService in Optimizely Commerce so you can override product titles, add custom feed attributes, and...

Wojciech Seweryn | Mar 20, 2026 |

A Synonyms Manager for Optimizely Graph

If you’re using Optimizely Graph for search, synonyms are one of the simplest ways to improve relevance without touching content. But they’re also...

Pär Wissmark | Mar 17, 2026 |

Building a Better Link Validation Report in Optimizely CMS 12

Broken links frustrate visitors and damage SEO. I have made a custom broken links report, that makes it easier to work broken links than the built-...

Henning Sjørbotten | Mar 17, 2026 |