kelvinluck.com

a stroke of luck

Using spell checker for TinyMCE with .NET on IIS


Recently I’ve been working on a website which is built in C sharp using the .NET framework (version 2) and running on IIS. This is a fairly different experience to my usual linux/ apache/ php/ mysql and actionscript setup but it’s been interesting and rewarding. I’m planning a series of posts documenting things that I’ve found out and like or dislike about this environment but for now just a quick one about how to get the spell checker for TinyMCE working…

TinyMCE is “a platform independent web based Javascript HTML WYSIWYG editor control” which is very popular on the web (in fact I am using it to create this post in wordpress!). It comes with heaps of functionality and plugins including a spellchecker. As you’ll see at that link though, the spell checker requires PHP on the serverside… Or does it?

If you look on the TinyMCE download page you will see that there is a .NET package available. I was curious about what this was, especially when I looked through the zip and found that it contained a SpellChecker folder. Looking at the code it turns out that this is the alternative of the PHP code necessary for implementing the spell checker – it accepts the AJAX request from a TinyMCE instance, sends it off to Google’s spell checking web service and sends the relevant results back in the AJAX response. Yay! Now I needed to find out how to use it – for some unknown reason this all seems to be undocumented and google wasn’t bringing back any answers either.

Looking through the c# code, I found that the .NET package is implemented as an IHttpHandler. Once I knew that it was pretty easy to figure out how to configure IIS to use the code. Basically you need to drop the Moxiecode.TinyMCE.dll from the .NET package into the bin folder of your website. Then open your web.config file and find the httpHandlers node inside the system.web node and add the following line in:

<add verb="*" path="TinyMCEHandler.aspx" type="Moxiecode.TinyMCE.Web.HttpHandler, Moxiecode.TinyMCE" validate="false" />

This tells IIS that all calls to /TinyMCEHandler.aspx should infact be handled by the Moxiecode.TinyMCE.Web.HttpHandler class in the Moxiecode.TinyMCE assembly. The validate=”false” means that IIS won’t check if this dll and class can be found unless you actually request that page (this is useful if you have seperate applications mapped to virtual directories below this web.config as it will prevent those applications throwing errors because they can’t find the dll)

Now you just have to set up your TinyMCE instances to include a spell checker button and to know the correct place to look for the serverside script. Here is how we instantiate TinyMCE:

tinyMCE.init({
   mode : "textareas",
   theme : "advanced",
   plugins : "paste, spellchecker",
   theme_advanced_buttons1 : "bold,italic,underline,separator,justifyleft,justifycenter,justifyright,justifyfull,separator,bullist,numlist,separator,undo,redo,separator,link,unlink,separator,cut,copy,paste,pastetext,pasteword,separator,forecolor,backcolor,separator,code,separator,spellchecker",
   spellchecker_rpc_url: "/TinyMCEHandler.aspx?module=SpellChecker"
});

The important things are:

  • Added “spellchecker” to the plugins list.
  • Added a “spellchecker” button to the buttons list.
  • Added the spellchecker_rpc_url which tells TinyMCE where to find the serverside script.
And that’s all there is to it. As you can see, it’s very easy as all the code is available but for some reason it seems to be undocumented and I couldn’t find any information out there about how to set it up. So hopefully this post will save someone else the time I spent figuring it out :)

Logging from FAME


Update:

This is a very old page imported from my previous blog. If there is missing content below or anything that doesn’t make sense then please check the page on my old blog.

I’ve recently started playing with FAME (or more properly FME - FDT, MTASC and Eclipse) and found it frustrating not having a trace window in Eclipse which I could use to debug my code…

Then I discovered Powerflasher SOS which is a handy standalone console which you can connect to via an XMLSocket from Flash. SOS has some incredible handy features for use along with FME. For example you can set it to “Console > Bring to Front > During Connection”. This means that the logging console will stay at the front of your screen while there is a socket connection open to it. I found it fiddly with other logging solutions which had a console opening within a panel in Eclipse (maybe because of the lack of screen real estate on my laptop). So I like this feature a lot. You could even run the SOS console on a different machine to make maximum use of screen space!

I thought what if I could combine the power of SOS with the convenient object introspection of the LuminicBox logger and colour coding etc.. And while I was at it I decided to also add support for the MTASC TRACE directive. So I did. Building on the TracePublisher from LuminicBox and adjusting a little code I came up with something which turns this:

/**
* example code for using a com.kelvinluck.util.SOSLogPublisher
**/


import com.kelvinluck.util.SOSLogPublisher;
import com.kelvinluck.util.LogWrapper;

LogWrapper.getInstance().init();
LogWrapper.getLog().addPublisher(new SOSLogPublisher("myAppsName"));
// log messages at different levels
LogWrapper.getLog().fatal("This is a fatal error :'(");
LogWrapper.getLog().error("This is an error :(");
LogWrapper.getLog().warn("This is a warning, warning, warning");
LogWrapper.getLog().info("This is information");
LogWrapper.getLog().debug("This is debugging info");
// an Array (folded by default in SOS)
LogWrapper.getLog().debug([1,2,3,{a:"Part A", b:"Part B"}, "Some text", 99]);
// an anoynomous object (also folded by default)
LogWrapper.getLog().error({a:"this is a", b:"and this is b"});
// an object with a toString method (folded by default with the name from the toString method shown)...
var testObj:Foo = new Foo("bar", 2000, ["A", "B", "C", "DDDDDD"]);
LogWrapper.getLog().warn(testObj);
// and using TRACE - add "-trace com.kelvinluck.util.LogWrapper.mtascTrace" to the commandline and compile using MTASC
trace("Check out the class and line number info above!");
trace({error:"something is wrong"}, LogWrapper.ERROR);

Into this (showing the horizontal scrollbar and four objects – three in their default folded states and one which I have “unfolded”):

SOS in action

Download:
If you want to play with this code please feel free to download it here.

The zip file includes an example class with a static main method that can be used to test the installation.

Requirements:
To use these classes successfully you will need a couple of things:

Powerflasher SOS – install it and run it. Select “Console > Bring to Front > During Connection” from the menu.

LuminicBox logger – install the extension. I have also included the LuminicBox classes in my zip just because I had to make a few tiny changes to get them to play nice with MTASC which is stricter than the MMC.

Unfortunately SOS only runs on windows so at least the machine that you view the logs on must be a windows machine.

Usage:
You can use it pretty much as demonstrated by the code above… Also check in the comments to the SOSLogPublisher code to see the arguments you can pass to the constructor etc… Just make sure that the relevant files are in your classpath.

If you are using these files along with MTASC’s trace functionality then you will need to add the following argument to your command line to MTASC:

-trace com.kelvinluck.util.LogWrapper.mtascTrace

Also note that you can do the following to toggle the display of line numbers:

LogWrapper.logCallingFile = false; // stops class / file / line number information from being logged
LogWrapper.logCallingFile = true; // starts class / file / line number information getting logged.

If you are using in with FDT then I found it really useful to create 4 Templates (“Window > Preferences > FDT > Templates > Templates”) to speed up entering debug code. For example, I have the “ze” (without the quotes) mapped to:

LogWrapper.getLog().error(${cursor});

or if you are using MTASC and trace you may find this more useful:

trace(${cursor}, LogWrapper.ERROR);

And similarly for the other log levels.

When you publish your finished file for production you can simply comment out the relevant addPublisher line to you don’t need to worry about the innards of your program being visible to others. Or if you use MTASC and trace then even better – just change the trace argument to be “-trace no” and the traces won’t even be compiled into your final swf!

History:
2005-08-30: First release
2005-08-31: Added folding so that Objects, Arrays etc which are logged are folded by default and can be opened inside SOS if you desire.
2005-09-01: Bug fix so XML and other objects containing < and > can be debugged.
2005-09-01: Added support for MTASC’s TRACE command
2005-09-10: Wrapped traced data in CDATA block so that ampersands, < ‘sand >’s can be successfully debugged.
2005-09-14: Added Natural Docs to the download zip.

Feedback:
If you find this useful or can think of a way that it can be more useful then please let me know below by leaving a comment below or via the OSFlash mailing list.