MJHutchinson.com Michael Hutchinson's Home on the Web

I just saw a post by Chris Howie on glueless javascript calls into Gecko#, and over a couple of my revision breaks I modified JSCall# to use this technique. The new completely managed code version is now in SVN, and I'll make a proper 0.0.3 release when I've written some docs.

The upshot of this is that it's now bundled with MonoDevelop, so Monodevelop SVN can be built with AspNetEdit ("./configure --enable-aspnet --enable-aspnetedit") without having to have JSCall# built and installed. This means you no longer need a C++ compiler and the Mozilla development libraries. Thanks Chris!

Now that Ubuntu Edgy has gone final, and I'm no longer tracking the beta, I've made some checkinstall packages for JSCall#. Although JSCall# originated as the native part of AspNetEdit, it has other uses as a limited Gecko-C# bridge. You'll obviously need Firefox, though I don't think there are any other hard dependencies. If a Firefox update breaks the packages, please add a comment to this post to tell me, and I'll rebuild them. There's an AMD64 and an i386 version.

Well, the Summer of Code is now ended. The ASP.NET MonoDevelop addin is now open to testing, and although it doesn't look any better than my previous screenshots, it's quite a bit more stable.

If you want to build the AspNetAddIn, just build MonoDevelop from SVN with the --enable-aspnet configure option. To enable the AspNetEdit Visual Designer you will need to build and install the jscall-sharp library (available from Mono SVN) and you will additionally need the MD configure option --enable-aspnetedit. The addin will probably be in the upcoming MonoDevelop 0.12 release, although it won't be built by default, so it may be worth waiting for that.

As well as testing, I welcome bugfixing and new features. If it's something big, please check with me first to make sure that someone else is not working on it already. I personally have a load of feature additions lined up for the future, but right now I need to spend a couple of weeks sorting a lot of stuff out, including this site, and sleeping :).

The Summer of Code has been fantastic. I've gained a lot of experience of working with a large and very well-designed codebase, which I think has improved my own coding a lot. I'd like to thank my mentor Lluis, who has been more than helpful with my many MD-related questions. Thanks also to Miguel and the rest of the Mono community for their help and support; this is a great community to work in, and I plan on sticking around.

And of course thanks to Google for running such a brilliant programme. Not only am I getting paid to do something I enjoy, but most of my favourite open-source projects (Mono, Gnome, GIMP, Inkscape, OGRE and Drupal, to name a few) have gained lots of exciting new features!

Update:
Here are some known issues with AspNetEdit:

1. To get some items in the toolbox, you'll need to add $PREFIX/lib/mono/2.0/System.Web.dll using the button on the toolbox toolbar.
2. On Firefox 1.5+ the control selection handles disappear after a few seconds. Mozilla 1.7 works fine.
3. The code from the design view can't be saved with older releases of Mono. This is caused by a bug in Mono's 2.0 classlib (or runtime) that has been fixed in SVN HEAD as of 11 Sept 2006.
4. The XUL/JS addin needs to be registered with your global Mozilla/Firefox profile. This happens when you install MonoDevelop, but if don't want to install the rest of Monodevelop (e.g. if you use 'make run') then you can just 'sudo make install' in the Extras/AspNetEdit/chrome directory.

Here's a shiny screenshot of AspNetEdit embedded in MonoDevelop. The code's not really ready for use yet, but I'm making good progress. It's been complicated by the fact that I'm running AspNetEdit and its property grid in a separate process so that the ASP.NET controls are isolated from the MD process.

I've just committed a patch to MonoDevelop to enable the use of the AspNetAddIn that I committed a couple of days ago. It's not close to fully-featured yet, but I'm pleased because it now enables a basic ASP.NET workflow. One can create an ASP.NET project and various ASP.NET files, then build and run it. The XSP server will be launched, followed by a web browser, and the compiled page can be seen in all its glory. In theory all .NET languages supported by MonoDevelop can be used, though I have only been able to test C# so far.

One of the most difficult things about developing ASP.NET project support for MonoDevelop is deciding upon a project model to use. Microsoft appears to have this problem too; while having used a "Web Application" (WA) model for VS.NET 2003, and then switched to a "Web Site" (WS) model for Visual Studio 2005, they have just recently brought back the Web Application model for VS2005. Both are sensible and straightforward ways of developing an ASP.NET site, and developers migrating from Windows are familiar with them, so it was clearly a good idea to use them as a starting point when planning how to implement the project support in MonoDevelop.

I have been accepted into Google's Summer of Code 2006!

This time round I will be adding an ASP.NET Project type to MonoDevelop, with a proper compilation, preview and deployment workflow. I will then be able to host AspNetEdit in MonoDevelop as its graphical designer for ASP.NET.

I will be posting regular updates on my blog. Right now I'm trying to decide which of ASP.NET's compilations models to support, and how they can integrate with the project model. I'm also familiarising myself with MonoDevelop's extension model.

Apologies for the delay in this announcement, but I only finished exams last Thursday.

Three exams down, two to go.

Just thought I'd post a link to my Dr Dobbs Journal article on AspNetEdit. It went out about 6 months ago, but I hadn't got round to linking to it yet. It explains a little bit about the reason for AspNetEdit, and the technologies used to bring it to fruition.

There's a terrible photo of me in the article as well ;-)

Well, it's exam time again. Five in total; first one on Monday, and the last is two days after I find out whether I've been accepted for the Summer of Code 2006. Not enjoying revision, and these exams – third year – are very important.

As for the Summer of Code, I've applied to work on ASP.NET Project Support for MonoDevelop. If I get accepted, I will be integrating AspNetEdit into a proper development environment at last!

My website can now be accessed at the domain http://mjhutchinson.com, and this redirects to the current site for now. I'll be migrating over after exams.

I've been thinking about how the ASP.NET Visual Designer should work with CSS and good semantic markup, and I've been thinking a lot about the role of both of these in the Web. In particular, what part do they play with ASP.NET?

I believe that the content of a document should be kept separate from its presentation. Semantic markup is good; structured content is easier for a machine to interpret and convert, as well as being cleaner and more elegant. CSS allows us to style a document without affecting its markup, and the same stylesheets can be applied to multiple documents for consistency and efficiency. Good semantic design also improves maintainability and accessibility.

So far, so good. But what about web applications? HTML originated as a document markup language, but via forms-and-CGI based search interfaces, the web has evolved into a complete UI platform. It's simple enough to send one view at a time, abusing HTML to make it look like a UI, and using dynamic HTML and JavaScript quite a complex user experience can be crafted. Everything stored on the server, and anyone and everyone with a web browser can access it. This is what ASP.NET is targeting, as it is essentially an HTML UI framework.

But where does semantic HTML fit into this? A UI and a document are different things, and should be separated. I don't really care how semantically correct a UI is on principle, though it does have some advantages, especially accessibility. But the semantics of a UI and of a document are different. If only there were a 'document' tag that could be inserted into HTML to show which bits are documents or document fragments, and another set of tags for panels and menus and so on.

Usually the solution is to use CSS classes, with some kind of <div id="content"> containing the document. But what kind of CSS design system works well with this? I have considered a couple of approaches.

1. ASP.NET has a theming system for its own controls, and I'd like to have a "content" control with a designer that would allow you to style a piece of placeholder text and would generates stylesheet from that.
2. A general-purpose stylesheet designer that lets you view a document and see the breakdown of the rules cascade on any element, and edit them.

I think that both would be useful, actually. In both cases, however, I think it's important to keep the style design distinct from the document design, even if the "document" is a UI. I'm tempted to remove all the font size and style, italic, bold, indent etc. toolbar options from AspNetEdit and replace them with a CSS style selector and semantic element buttons like "em". Though I'm also considering ways of enforcing which types of elements different CSS classes can be applied to, maybe some kind of stylesheet schema, and a way to use schemas to enforce structured document design.

As an aside, I've often wondered why there isn't a "semantic word processor" that enforces document structure and styles, and removes the temptation to fiddle with the details.

Anyway, if anyone has any ideas about this, comments are welcome as always. I've already begun to implement some of the changes to the toolbox discussed last time; I decided to go with a simple treeview with a filtering box at the time. Unfortunately I'm very busy with academic work right now, but look for developments sometime next term!

Update:I recently came across microformats, which look cool. Nice semantically, meaningfully, defined structures. I'd love to have an HTML graphical editor driven by some sort of schema to restrict editing in certain regions of a page to particular formats like these.