Software Factories in .NET, by Christian Weyer

I went to an interesting talk tonight by Christian Weyer, where he described some of the upcoming features in Visual Studio, namely Software Factories. Software Factories allow you to customize and extend Visual Studio much more easily than before, so you can bundle together things like wizards, context sensitive menu actions, code generation etc. The slides from the event are available here.

Being the good Java-devotee that I am (I’m not religious about it or anything, they pay me to care 🙂 ), I of course pointed out that this is, in many ways, very similar to Eclipse perspectives, which also allow you to easily (“easily” being relative of course) extend an Eclipse rich client application with organised packages of code in Plugins and Features. These plugins and features are used to do everything in Eclipse applications, like wizards, context sensitive menu actions, code generation etc (seeing a pattern here?).

As I promised to Christian and others, here are some useful links to Eclipse documentation on this subject:

  • This is the basic, high level description of Eclipse perspectives, more from a users point of view than a developers.
  • Eclipse Rich Client tutorials Part 1, Part 2, and Part 3. Part 2 is where it describes Perspectives best.
  • A book, in German (for you Christian 😉 ), on the Eclipse Rich Client Platform (RCP).
  • A screencast on Eclipse RCP application development. All RCP applications are based on Perspectives.ISV Guide pic
  • And finally, a plug, my RedPaper called “IBM Workplace Managed Client: ISV Integration Guide“, which describes a number of different methods of writing Eclipse RCP applications based on the IBM Workplace Managed Client application. (It’s really good, honest!). Much of the practices and technology described in this paper are used in the upcoming Lotus Notes release, codename Hannover.

All in all, it was a very good talk, with a packed room. It’s just a pity there wasn’t a screening of Blade Runner in a private cinema, like the last time I saw Christian present, in 2004. I guess we were a bit spoiled that time!

P.S. Thanks to Kieran from Digerati for telling me about the event.

Hiding the Dojo rich text editor and modifying its contents

The Dojo toolkit provides a very useful rich text editor, which enables you to do WYSIWYG text editing in the browser. However, while integrating it into an application I came across a problem when I tried to load it into a hidden <div> tag, which would be made visible later.Simply put, it’s not currently possible. If you create an Editor2 widget inside a non-visible DOM node it will not function (note that this is done using the latest nightlybuild of Dojo, as of 12th August 2006). Luckily, the solution was already explained in the mailing lists, and it is this:

Instead of putting the Editor inside a hidden div, like

<div id=”parentNode” style=”display:none”>

<div dojoType=”Editor2″> This is the content</div>


Leave the parentNode visible, and place it offscreen, like

<div id=”parentNode” style=”left:-1000px; top:-1000px”>


and when you want to make it visible, do something like:

dojo.byId(“parentNode”).style.left = “100px”;

dojo.byId(“parentNode”) = “100px”;

Of course, you don’t have to position it absolutely, but you get the idea.

The second issue I came across is that of programmatically modifying the contents of the Editor. Each time the editor becomes visible (or in this case is moved into the viewable area of the screen) I wanted to replace the contents with that of an existing blog posting, which could then be modified. There exists a method on the widget called replaceEditorContent, which is supposed to do exactly what it says on the tin – replace the contents. However, while this worked just fine in Firefox, when I tried it in IE 6.0 the entire contents of the page hosting the widget were replaced, not just the content of the Iframe that the editor uses to do the editing. Knowing the Dojo guys, this could very wellbe fixed by the time you’re reading this, but if not, read on! (update: I’ve filed a defect for this here) The solution to this problem is to dynamically create the editor each time you want to display it, and destroy it when you are finished with it. For example, given the DOM node:

<div id=”postContainer” style=”left:-1000px; top:-1000px”></div>the following function will create a new <div> tag inside “postContainer”, and create an Editor2 widget inside that tag, with the widgetId “w_richText”. It then moves the “d_postContainer” div node into the visible screen area.

function showPostPanel(content)

var parentNode = dojo.byId(‘d_postContainer’);
//create a new div node that the editor will exist in. This will be created and deleted

//each time the editor is shown/hidden

var widgetNode = document.createElement(‘div’);


widgetNode.innerHTML = content ? content : “Enter your post here<br><br><br><br>”;

var widget = dojo.widget.createWidget(“Editor2”, {
id: ‘w_richText’,
htmlEditing: true


var enclosingNode = dojo.byId(‘d_newPost’); = “100px”; = “100px”;

Hopefully this is of some help.

update: You’ve got to love open source 🙂 I filed a bug against the replaceEditorContent bug on Saturday morning (this morning) and a few hours later it’s fixed. No such thing as waiting until Monday. Thanks to liucougar for the fix.

Cross domain Ajax requests in Dojo…. and there was much rejoicing

This is going to be huge! Dojo now supports cross domain Ajax requests, something that has been out of the reach of most Web 2.0 programmers until now. It’s implemented using Iframes, which has both pros and cons (get more info here) but against the couple of issues people might have with it are the two facts:

  • It works! It might use more memory, or it may be slower than normal, but dammit, it works! If you want to keep on using server side proxies or Flash, that’s fine, but here is a standalone, client-side solution that works.
  • It’s ridiculously simple to use. As with all other remote requests in Dojo, the mighty function is used, this time with a single new parameter. As the documentations states, you do:

iframeProxyUrl: “;,
url: “http:/”,
load: function(type, data, evt, kwArgs){
/* do stuff with the result here */

and it all just works. The emboldened parts are the only client-side changes that have to made to existing code. There needs to be server side support too of course, but that is the case with all Ajax sites, so it’s hardly something to criticise.

Final verdict is that this is one of the most important additions to Dojo (after the namespace support of course *ahem*) in quite some time.

Now, as for the security/morality of doing remote Ajax calls….. after all, browsers block it for a reason. Very nasty things can be done if you can access any remote content you like from a Javascript enabled client. However, it seems that this code can only go against remote endpoints that support this Dojo feature, so there should hopefully be no problem there either. Seems like this one’s a keeper folks.