[Solved] Found A Bug

[Lee]

Hi,

I have found a bug with the new version of the rad editor. If i assign the toolsfile in the codefile rather than on the page the editors will populate the css dropdownlist with all the css classes used by the page. This happens even though i have added an external css file which has no classes.

On the page:

<telerik:RadEditor
    Id="HtmlEditor"
    Runat="server"
    Enabled="true"
    EnableResize="false"
    StripFormattingOptions="NoneSupressCleanMessage">
    <CssFiles>
        <telerik:EditorCssFile Value="~/css/dummy.css" />
    </CssFiles>
</telerik:RadEditor>

In the codefile:

HtmlEditor.EditModes = Telerik.Web.UI.EditModes.Design | Telerik.Web.UI.EditModes.Html;

Any help to fix this problem would be greatly appreciated as its driving me bonkers!

Lee

[Henning]

Hi

I have a similar problem if I try something like this:

cntlRadEd.CssClasses.Clear();
...
cntlRadEd.CssClasses.Add(localizedKey, pair.Value);

Here I am certain that the pair.Value is well-defined.

This happened after build 6.19, and was working fine before. The editor just populates everything it can find on the page.

[Rumen]

Hi guys,

In the latest Q1 2008 SP2 release of Raeditor's we implemented a new ToolProviderID property. The ToolProviderID property helps to significantly reduce the HTML markup and JSON(Javascript Object Notation) sent from server to the client when multiple RadEditor objects with the same tools are used on the same page.

The implementation of this property required to make a change in the load time of the ToolsFile.xml file and now it is loaded later than all editor's inline tags (such as CssFiles, Tools, Colors, etc collections) and overrides their settings.

That is why to achieve your scenario just declare the tools that you want to render on the toolbar as well as set the CssFiles, CssClasses, etc properties only in the ToolsFile.xml file loaded through the ToolsFile property, e.g.

RadEditor declaration:

<telerik:RadEditor
    Id="RadEditor1"
    Runat="server"
    Enabled="true"
    EnableResize="false"
    StripFormattingOptions="NoneSupressCleanMessage">
</telerik:RadEditor>

Codebehind:

RadEditor1.ToolsFile = "~/ToolsFile1.xml";

ToolsFile.xml declaration:

<root>
    <tools name="MainToolbar" dockable="true">
        <tool name="AjaxSpellCheck" />
        <tool name="Cut" />
        <tool name="Copy" />
        <tool name="Paste" />
        <tool name="FindAndReplace" />
        <tool name="Undo" />
        <tool name="Redo" />
        <tool name="Outdent" />
        <tool name="Indent" />
    </tools>

    <cssFiles>
         <item name="~/CSS/radeditor.css" />
    </cssFiles>
</root>

For your convenience I have attached a sample running project that demonstrates how the solution works.

Kind regards,
Rumen
the Telerik team

Instantly find answers to your questions at the new Telerik Support Center

[Henning]

Hi Rumen,

This is very unfortunate. Because it is for a good reason that I use:

cntlRadEd.CssClasses.Add(localizedKey, pair.Value); 

The value is obtained from a specific website in our CMS and is localized according to the language of the site.

Does this mean that I need to parse each style and generate my own css file that only contains the styles I want?

How do I go about displaying custom and localized names for each style for each specific website? It was relatively easy to define a xml mapping file for each site that contained the localization key mapping to the css style, such that localization could be performed for the styles in the codebehind.

Is there a way to turn this "new feature" off? I don't need more than one editor on a page at each time.

[Henning]

Hi again Rumen,

I found the solution by looking at another post you have posted for another problem. I solved my problem by doing the following:

cntlRadEd.Tools.Clear();
cntlRadEd.ToolsFile = ProviderPath + EditorMode + "Tools.xml";
cntlRadEd.EnsureToolsFileLoaded();

I am a happy camper again :)

[Tervel]

Hi,

We are glad to see you go the issue resolved.

Let me provide you with additional information on why we had to change the logic, and what is the "recommended" approach to follow when dealing with a combination of ToolsFile and using the RadEditor API. Firstly, it is important to point out - the change that was introduced

• does not change the existing API of the editor
• does not reduce the editor flexibility - all scenarios that worked prior to the change will continue to work (albeit it might be possible to add a line or two of code or to reorder the code)

The reason for the change is related to a much requested size and speed optimization when multiple RadEditor instances are on the same page (especially when all use the same ToolsFile). We did several improvements to speed up editor loading, and the result is a significant optimization - the loading time could be cut by as much as 80%, that is - 10 fully-functional editors on the page would load in under 2 seconds.

Here are the optimizations introduced

• New ToolProviderID property. The ToolProviderID property helps to significantly reduce the HTML markup and JSON(Javascript Object Notation) sent from server to the client when multiple RadEditor objects with the same tools are used on the same page
• Lazy initialization of the editor toolbars when the ToolbarMode is other than Default. In that case the editor tools are initialized not at page load, but when an editor is to be used for the first time
• Invisible editors are not initialized until they become visible (very common optimization request from people using RadTabStrip and RadPanelbar to do their page layout)

What is the nature of the change and how does it affect more advanced scenarios such as yours?

To answer this question, it is important to understand how the editor functions internally - how the ToolsFile relates to the editor API. The ToolsFile is used as the default, the base for editor initialization. Not only the tools, but all of the editor's collections can be set from the tools file - e.g. modules, colors, cssclasses, css files, symbols, context menus - to name a few. This is why, when a ToolsFile is explicitly set, all of these collections are cleared and reset to what is specified in the tools file. Thus - scenarios that do both - set a tools file, and then modify some of these collections should do it in the right sequence.

Then comes the API - all the editor collections are also accessible and configurable from the codebehind, as well as declaratively on the page by using markup and specifying items directly between the editor's opening and closing tags.

Up until now the default editor's ToolsFile (which is built into the editor DLL) would be loaded early in the control's lifecycle, and all subsequent changes through the API would be reflected. However, with the changed logic, the editor's ToosFile now loads in its OnPreRender method - late in the control lifecycle. This is to ensure that no needless processing is done and no CPU lifecycles are wasted on the intensive operation of parsing a tools file, filling in collections and constructing obejct trees - that would then be cleared, for example, because of the use of external ToolProvider.

After trying several options - each of which with its side effects, we picked up what seemed the best option:

• Provide the ability for the developer to force the ToolsFile to be parsed and loaded at any given time (this is what the EnsureToolsFileLoaded() method is about.
• If developers use the editor API, then we assume they will want/need/can configure all the tools, collections, etc from the API - and the editor's default ToolsFile will not be loaded
• Setting a ToolsFile explicitly will reset all collections that are configurable from the ToolsFile.

These three rules are very simple, and with them in mind you will be able to configure the editor in any way you did up until now.


All the best,

Tervel

the Telerik team

Instantly find answers to your questions at the new Telerik Support Center