Dialog layouts... (and buttons, toolbars etc.)

One of the ideas I have in mind is making it possible to download FCKeditor from a CDN. So, http://www.example.com can download FCKeditor from cdn.fckeditor.net (this is an example only ).

In the above scenario, there are some things we have to consider, regarding the way browser's download, render and execute resources:

• Images and CSS files can be downloaded from any URL, with no restrictions.


• JavaScript files can be downloaded from any URL, with no restrictions.


• HTML files can be downloaded from any URL, inside an IFRAME, with security restrictions. Scripts inside the loaded page can't communicate with other frames from different domains.

So, for HTML files, we have a limitation on using CDNs. This is not a CDN only issue, but a limit to any effort on using a central domain to deliver FCKeditor.

The solution would be avoiding using HTML files at all. So, FCKeditor should be composed by image files, CSS files and JavaScript files only. And here we have many layout related issues.

All layout definitions should come from JavaScript files, instead of HTML files. For that, we would have two options:

1) Include the entire HTML of the dialog in a single string variable.

Advantages:

• Easier (not to say easy) to maintain (maybe).


• Complete flexibility in the layout.


• No need of a rendering API

Disadvantages:

• Difficult to introduce reusable complex components, like date pickers, sliders, or even a "numbers only" text field. All that could be somehow achieved by assigning specific classes to elements.


• No content style standardization. Each dialog may look different.

2) Define the dialog structure by defining a rich components definition (something similar to your proposal).

Advantages:

• Easy to reuse components. Even easier to have specific setting for each one of them.


• Makes it possible to replace components with custom solutions, like third party libraries.


• Standard layout among all dialogs.

Disadvantages:

• It requires a complex API to render the contents based on the definition. This API could potentially represent a huge piece of code in the editor, which would impact in the download performance. Of course, we could include the API as part of the dialog structure, to be downloaded only when opening a dialog (UI responsiveness).


• Rigid layout, limited to the rendering API features.


• Difficult to visually understand the final results (maybe).

I'm sure many points are missing in the above considerations. I'm still not sure though which solution would be applicable, feasible and adequate "considering all aspects".