Phil Tucker

Editor's Second Skin

Phil — Mon, 31 Mar 2008 13:30:00 GMT

With a mandate to continuously improve our products and suite as a whole each version of Web.UI can bring many upgrades. With Editor 2008.1 we decided to add a new method of skinning the Editor control. Previously, developers were required to employ our sample UserControl skins and not directly embed the Editor on to their ASPX page. While this kept the ASPX clear of detailed Template, ToolBar and Widget code, it abstracted the Editor tag and added an extra layer to the control hierarchy. Editor 2008.1 introduces a new skinning mechanism which accomplishes the goal of allowing a clean ASPX yet eliminates the need to refer to the Editor through a UserControl.

In Editor 2008.1 we have divided the required control references into a combination of Widgets, Templates and ToolBar definitions. None of which need to be defined inline. By separating the elements of the Editor it allows the control to optimized by only loading the widgets required by each specific skin or template of the Editor, this eliminates quite a bit of overhead depending on how minimal the skin is.

How Skins Work in Editor 2008.1

The main template for the Editor can be defined either inline or by setting the Editor TemplateFile property. These files are located, or should be placed in the skin directory,

skins\skin_name\templates\

Templates define the layout of the Editor instance. References are included in this Template for various elements of the Editor:

$$ToolBars[0]$$
$$breadcrumbs$$
$$wordcount$$
$$charactercount$$
$$parent$$

ToolBars definitions one of the few elements which must still be defined inline in the Editor <ToolBars> collection, however, each ToolBar's Items may be defined in XML and referenced via ToolBar's SiteMapXml property.

       <ToolBars> 
           <ComponentArt:ToolBar
            RunAt="server"
            Id="CoreToolBar"
            ImagesBaseUrl="../../skins/blackice/images/toolbar/"
            CssClass="toolbar"
            Height="25"
            DefaultItemImageWidth="23"
            DefaultItemImageHeight="21"
            UseFadeEffect="false"
            SiteMapXmlFile="CoreToolBar.xml"
            >

            <ClientEvents>
              <ItemMouseUp EventHandler="font_toolbar_mouseup">
            </ClientEvents>
          </ComponentArt:ToolBar> 
       </ToolBars>

When defining ToolBarItems, whether in XML for use with SiteMapXml or inline, each ToolBarItem is given an EditorCommandType. The EditorCommandType both defines the function of this ToolBarItem within the Editor context and dictates which Widget, if any, should be loaded to accompany this ToolBarItem.

<Items>
      <ToolBarItem EditorCommandType="FormatStyle" >
      <ToolBarItem EditorCommandType="FormatFontFace" >
      <ToolBarItem EditorCommandType="FormatFontSize" > 

Once the Template, ToolBars and ToolBarItems are defined, the Editor is ready to go! Of course, these steps are already taken in our samples and one may simply copy the skins directory and an Editor control tag to their application. This document is meant as a reference to some inner workings for those interested in skinning.

Customizing any of our sample skins is as easy as editing any of the elements defined above as well as any of the Widgets.

Customizing Skins in Editor 2008.1

ToolBars can be added or removed from the ToolBars collection in the Editor control tag, ToolBars may also be removed by removing their placeholder from the skin template.

ToolBarItems may be removed, added or edited by editing the corresponding xml file, such as StandardToolBar.xml. If they are defined inline with each ToolBar editing can be done there as well.

Any other aspect of an existing skin may be customized through editing the template file, the widget UserControls for each ToolBarItem skins\skin_name\widgets\ and/or the corresponding image and CSS files. For example, to alter the InsertEditMedia Dialog you would edit the file skins\skin_name\widgets\InsertEditMedia.ascx.

The UserControl method of skinning is still available, relevant files can be found in integrated_skins\. While this method is still functional and available, it will most likely not be supported in a future iteration of the Editor control and may not contain all future fixes. The javascript engine to accompany this method, scripts.js, is now compiled into the ComponentArt.Web.UI.DLL. Therefore cannot easily be edited when using the new skinning method.

We've found this new skinning method to be easiler, both when implementing and when making customizations than it's older counterpart. hopefully you will too.

Share this post: email it! | bookmark it! | digg it! | reddit!

Dynamically Assigning Event Handlers w/ Arguments to Instance Methods in Javascript

Phil — Fri, 16 Feb 2007 21:34:00 GMT

I ran into a speed bump of sorts when attempting to assign an object instance method as a DOM event handler, there's some information floating around the net, but a post on the topic can't hurt. Something like this on the server side would usually fit the bill:

spaghetti.Attributes.Add("onmousemove",this.Id+".myMouseMoveHandler(event)");

However since we want to create this same result completely on the client-side we'll need to do this in the class constructor, something like this:

document.getElementById('spaghetti').onmousemove = this.myMouseMoveHandler;

May work in some situations, but arguments cannot be passed when assigning this way, also, unless the handler function is defined within the constructor it won't be available yet. Something like this:

document.getElementById('spaghetti').onmousemove = 
   new Function ('e',id+'.myMouseMoveHandler(e);');

Again will only work if the handler method has been defined within the constructor, but at least an argument may be passed. Next we add the dreaded eval so it can be evaluated on the fly, allowing us to define the handler method for the object instance outside of the constructor:

document.getElementById('spaghetti').onmousemove = 
   new Function ('e','eval("'+id+'.myMouseMoveHandler(e);");');

Figured it was just convoluted enough to warrant a blog post.

Share this post: email it! | bookmark it! | digg it! | reddit!

Telligent Community Server 2.1

Phil — Tue, 31 Oct 2006 09:45:00 GMT

We here at ComponentArt have long been working with the good folks at Telligent Systems and have been using a highly modified version of their Community Server on our main site for quite some time. When we decided to set up some development/corporate blogs, selecting software didn't take long. I'm currently involved in a number of projects here at ComponentArt, both in development and support of our products, the most recent being the implementation of Community Server 2.1 for these blogs. I'm sure you all envy me the tip-toeing through skin files and templates to get that look just right, but seriously, Telligent have a great product which we managed to completely customize and skin in less than three days. Some URL redirection, which it supports though a .config file, some virtual directory shuffling and we've got CS stripped down to the blog meat we wanted. Here's to hoping these blogs provide the development community with some interesting reading now and then. Cheers.

Share this post: email it! | bookmark it! | digg it! | reddit!