Journal for November 2008

Completing ASP.NET Collection Properties

I've recently been tweaking the ASP.NET completion, adding support for resolving valid children for a control. These can be properties, a property, or controls. More difficult was resolving the valid children for properties, but this is now done:

Screenshot of an ASP.NET file in MonoDevelop showing autocompletion on the children of a collection property.

Unfortunately, there aren't actually any designer or parser attributes for limiting the children of a property, so in order to resolve the children, I assume it's a collection, and look for an Add method with a single parameter derived from Control. If this exists, I use its parameter to filter the types in the control completion list. It's an ugly hack, but it works perfectly for tables and wizards. In the worst case, MonoDevelop falls back to showing all controls.

With this done, the ASP.NET completion is essentially feature-complete.

HTML Completion

The main thing I've been working on for the upcoming MonoDevelop 2.0 release is ASP.NET code completion, and I'm pretty happy with its current state. Recently I've been "downporting" this code into base classes to make it easier to write XML completion and HTML completion editor extensions. A while back I wrote a hybrid XML/ASP.NET/HTML parser, which I've been using in MonoDevelop for triggering ASP.NET code completion. The aims of this parser were to be extensible and to have good error recovery. This makes sharing code between XML-like completion extensions very easy — the completion triggering code and the path bar code are entirely shared between the editors.

After moving the HTML code down to a common base class, I decided to expose this functionality for actual HTML files, rather than just ASP.NET, and wrote an HTML text editor extension to handle this.

As well as parsing a path, for code completion, the parser can also parse a complete document into a tree. This is useful for code folding, error underlining, and the document outline. The ASP.NET extension does not yet use it in this mode, instead using the older and better-tested Mono ASP.NET parser, so the first time this saw use was in XAML completion (about which I still need to blog). I recently (and trivially) "crossported" this code over to the HTML text editor.

The final piece of the puzzle was to write an HTML tag state for the parser to enable it to recognise and implicitly close tags when appropriate. Putting this all together, we get to the most important thing: the screenshot.

Screenshot of an HTML file in MonoDevelop showing the warning underlines on implicitly closed elements.

The blue underlines are warnings, when a tag has been implicitly closed. Note that the document outline is still correctly formed. The red underline is of course an error, and the parser has recovered from that too.