Blog For .NET

I’ve been working with MoxieCode’s free wywiwyg editor tinyMCE. I made the switch from fckEditor because of tinyMCE’s incredible featureset, small footprint, strong userbase, and high degree of configurability.

For ASP.net developers there is a package that includes controls for integrating tinyMCE as a server control. The server control (Moxiecode.TinyMCE.Web.TextArea) suffers several flaws, specifically:

• On render the control traverses the page’s entire control hierarchy via the FindAllTinyMCEAreas method. It’s collects all instances on the page so that it can render a single inline script to initialize the page clientside and load all the proper plugins. This traveral of all objects in the Page.Controls object graph can be very costly and the inline javascript  (tinyMCE.init(…)) is rendered before the first instance’s markup.
• The control does not support encoding on postback – the tinyMCE control supports it client side, but on postback the server control does not decode it.
• The control does not support asp.net validation.
• Individual instances are not independently configurable. The initialization script uses the distinct union of all settings applied to all instances.

So I refactored the control to fix these issues.

• I used the Page.Items dictionary to allow each instance to register itself, avoiding the control tree traveral. 
• By integrating with the scriptManager’s methods each instance of the tinyMCE control is initialized with specific settings. As with the original control, initial settings are “inherited” from the tinyMCE settings section of the web.config . The “installPath” is always the same across all instances. All other settings are overriden via the Settings collection or as attributes of the control’s markup.
• The control now supports decoding input that was encoded clientside to work with asp.net request validation. It’s worth noting that if the tinyMCE setting “ask” equals true, then the tinyMCE editor may not be initialized when postback occurs. If the tinyMCE editor is not initialized, the contents of the textArea will not be encoded and on postback a request validation exception could be thrown.
• The control now supports asp.net validation using custom validators. Before validation occurs, “tinyMCE.triggerSave(); “ needs to be called to force the tinyMCE instances to flush their values to their respective textAreas.  I’ve included custom required and maxLength validators demonstrating this. They are of dubious use, however, since the markup is html encoded it is difficult to check the validitity of a textarea’s length or it’s content.For example, ”<p></p>” is visually equivalent to “” in the browser. As a javascript string ”<p></p>” is considered non-null (length > 0) and it’s encoded text “&lt;p&gt;&lt;p&gt;” is 18 characters long. Though it renders as “” in the browser, the requiredValidator returns true and the maxLength validator will validate against a length of 18 characters.

Check the code out here.

No Comments yet »