Journal for 2005

ASP.NET and CSS

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.

Toolbox Style

I'm cleaning up some of AspNetEdit's widgets, the Toolbox and the PropertyGrid. My original plan was to use GTK#'s TreeView for both, but while working on the toolbox I realised that it may not be the best solution for this particular item.

Why? Well, it depends on how people want the toolbox to work. Should the basic mechanism stay as it is, a TreeView-style list with expandable categories in one huge scrollable box? Or should it be similar to Outlook, with effectively a radio-button choice of one category that gets its own scrollable area?

I've used Glade to create a side-by-side mockup of the two approaches:
Two different mockups of the toolbox

I personally prefer the one on the left, but it does raise scalability problems with large numbers of categories, though this is not likely to be a common scenario. It would also make it more difficult to reorder categories.

Comments below, please.

Mozilla editor comes out of hiding

Okay, I admit it, so far I've been "cheating", rendering the page to a temp file every time something changes. No longer! I present to you the all-singing, all-dancing Mozilla editor version. You can select controls on the surface, type text straight into the page, resize controls, and drag-n-drop! This is the first you'll have seen of my co-conspirator Blago's work, but trust me, it's been worth the wait.

In other news, saving and loading are temporarily broken. We also haven't exposed many of the Mozilla editor's features, the main ones being cut/copy/paste, undo/redo, styling, and table editing. However, at this point it's mainly just a matter of hooking them up to toolbar buttons.

Oh, and those are new control icons. They haven't been released yet, as they're too embarassing, but if some SVG genius would like to improve them, the source files are available on request.

AspNetEdit hits SVN

I've finally committed the ASP.NET Graphical Designer to Mono Subversion, module 'aspeditor'. It's unimaginatively codenamed AspNetEdit. If anyone *really* wants to play with it, please be aware that right now it doesn't do an awful lot. Also it requires Mono class libraries hot out of SVN. I would advise waiting till an actual release the beginning of September; I'll keep my blog updated with screenshots. Here's the next:

As before, you can add controls to the design surface from the toolbox, and change their properties with the Property Browser. In this screenshot you can also see the new Collection Editor. All of this has been polished, and you can now save the document to a .aspx file. However, ASP directives are not suported yet, and the interactive design surface is still a little way away.

ASP.NET Graphical Designer screenshot

Okay, it's not quite as exciting as the title suggests. I've been hacking away on the Services and Component Model, and have reached the stage where I can display controls, select them from a drop-down list, change their properties, and have the change reflected on the design surface. You can't interact with the design surface directly yet, and the controls aren't really in a document, just a collection of controls. But it looks pretty!

Update, 28-7-05: Noticed I'd put this in the wrong category.

It lives!

The inbound (Mono -> Gecko) C++ DOM function is working fine and I can recieve a C# call in JavaScript; now I just need to pass it off to the actual function.

There was a bit of trouble initially as I couldn't obtain an nsIWebBrowser pointer from gtk_moz_embed_get_nsIWebBrowser. This turned out to be because the Gecko# WebControl hadn't been shown yet (i.e. window.ShowAll()), but I didn't figure this out as other functions like gtk_moz_embed_get_location worked fine.

Here's Blagovest Dachev's XUL GUI demo hosted in my container, with a simple C#->JS call demonstration. For anyone who hasn't seen the Mono Summer of Code page, Blago's working on the Mozilla half of this project.

Shouldn't be hard now to get the outbound side working. I'll have to test how long the JavaScript status messages can be, or I'll have to finish the outbound C++ glue. Marshalling 'out' parameters isn't too easy, especially when I don't want to place any artificial limits on the size of the data that can be passed around, so I'll return the arguments from the function as a string pointer return value. I don't expect the names of the callee and callback functions to be more than a few hundred characters in the extreme case, so they should be able to be sent in the JavaScript status message.

However, splitting the call in two parts like this could have consequences; there's no telling what multithreading could do to concurrency. I guess some kind of unique identifier is in order.

I also need to finish all of the error and exception handling at some point, though it seems robust enough at the moment.

Gecko# interaction

Implementing the ASP.NET GUI designer with Mozilla's Gecko web rendering engine is an obvious decision: it's open-source, has strong standards support and a large feature set, is highly extensible and flexible thanks to its XPCOM component system, and using Gecko# it can be embedded in a GTK# GUI. Mozilla is becoming an application platform, with XUL for declaratively writting GUIs, and JavaScript for program logic.

Gecko# wraps GtkMozEmbed, which is a C GTK widget, hiding Mozilla's native C++. Understandably this widget isn't bloated by wrapping the Mozilla DOM or other internals: it claims to exposes enough functionality for "about 80% of uses". Essentially this means a basic web browser.

However, to do anything interesting I need to interact with Gecko# from my C# code, and vice versa. There are two obvious ways to approach this:

  • Expose everything
    Open up the whole of Mozilla's internals to Mono code, or at least the DOM and XPConnect for JavaScript interaction. This would be ideal, as it's the most flexible, and would find many other uses. However, wrapping enough functionality to do anything useful is a very significant task in itself.
  • Message-passing
    Simply restrict all of the Mozilla interaction code to JavaScript functions, which can be triggered from C# via a message-passing scheme of some kind. Pragmatic, and not inelegant, as JavaScript is a first-class citizen in the Mozilla world, and is used to write large parts of Mozilla.

So, assuming I choose the second for speed and ease of development, how do I go about implementing it? This time, I have four choices:

  1. Abusing Gecko#
    Relatively harmlessly, we can raise C# events by changing the JavaScript status message.
    A more serious abuse is to stream the document into Gecko#, then stream in additional elements containing our messages. JavaScript can catch these with the DOMNodeInserted event and act accordingly. Or so I thought. While Gecko will render an open HTML stream, it's not so forgiving in the case of XUL. Oh dear.
  2. Mono-XPCOM bridge
    Yes, there is one, and it would be the most elegant solution... unfortunately it's not nearly complete enough to begin using for a project like this just now, and I'm not familiar enough with XPCOM to fix it up myself. I can see switching to this when it becomes stable enough.
  3. Web server
    This would cause the editor to effectively become an "AJAX" application. Ouch. A horrible hack, and a horribly-named technology. On the upside, this would be relatively quick and easy.
  4. C++ wrapper and P/Invoke
    Similar to the Gecko# abuse, but strangely, more elegant, despite the additional dependecies and build steps this method entails. The handle from Gecko# can be passed to a C/C++ wrapper via Platform Invoke. The wrapper function then uses GtkMozEmbed's "gtk_moz_embed_get_nsIWebBrowser" function to access Gecko's internals, does interesting thisgs to it with XPCOM, and optionally even returns values.

Well, I initially tried the fourth method, until I realised how much easier the first would be, and cursed XPCOM and the days it had taken from my life.

Fate has twisted sense of humour. Two days into the initial implementation of the editor's high-level architecture, as I began to flesh out the message passing system, I discovered the fickleness of Gecko#'s streams, and had to revert to XPCOM and P/Invoke.

More on this story later, once I have something working.

ASP.NET GUI Designer

Hello everyone! (waves to as-yet nonexistent audience)

I finally bring to you some useful content in my blog. I have been accepted onto Google's Summer of Code and will be working with the Mono Project to bring you a user-friendly graphical designer for ASP.NET, which will be integrated into the MonoDevelop IDE.

I will be chronicling any interesting developments right here for your amusement and gratification. Stay tuned!

How embarrassing

Three months since I last posted on this site, and all of those early posts were just about setting the site up. Seems lie the site's a bit pointless, really. Not that I've been sitting idle; I've been snowed under with academic work. I'll get something interesting up here eventually, I promise.

For now, let it be known that I am procrastinating my exam revision by upgrading the site to Drupal 4.6.

Spam, spam, spam, spam....

The site's only been up for five days and I'm already getting referrer spam. No comment spam yet, but I'll probably disable comments and trackbacks until I have some interesting stuff up, and sort it out then.

Thanks to some helpful advice on Caveat Lector I used a bunch of Apache .htaccess rules to filter out domains containing spam-like words. It's likely that there will be some false positives but until I find another way, it'll have to do.

In other news, Drupal's project module is giving me trouble; it refuses to track my projects' releases. I think it's PostgreSQL compatibility-related, but the exact reason is proving to be difficult to track down.

Pages