After posting messages to the Spark project and C# WebServer project forums, I decided there was enough interest to make sharing my integration code worthwhile.

You can find it at: http://code.google.com/p/sparkserver/

If you’d like to participate in the project, please let me know. Comments, suggestions, and especially fixes are always welcome!

Related posts:

1. Using Spark View Engine with C# WebServer
2. Support the JQuery Project
3. Looking for an IIS Alternative

Since we’re not using Microsoft IIS, we wanted to avoid a dependency on System.Web, which has the popular but flawed HttpUtility.HtmlEncode() method.

In my research, I discovered Rick Strahl’s post about Html and Uri String Encoding without System.Web. He points out the problems and inconsistencies in the mainstream encoding methods available in the .NET framework, and ultimately decided to roll his own encoding method.

But in this StackOverflow question on HTML Encoding in C#, several folks suggested using Microsoft’s anti-cross-site scripting library, AntiXSS.

After spending some time working with the library, it seems like just the thing to solve the problem of web encoding.

The AntiXSS Library includes helpful methods for encoding HTML, URLs, JavaScript, and XML. It’s based on a secure whitelist model, so anything not allowed in the specifications is prohibited.

Microsoft has made the source of AntiXSS 3.1 available on Codeplex (http://antixss.codeplex.com/), but you can also get the official release of AntiXSS direct from Microsoft. It includes a sample application and thorough documentation.

It’s exactly the solution I was looking for.

Related posts:

1. Using WCF to return HTML
2. JQuery Turns 3
3. How to format the XAML Hyperlink NavigateUri

After weighing the options, we decided to move forward with the C# WebServer. Instead of using one of the two rendering engines currently included in the WebServer project, though, we’ve decided to use the Spark View Engine instead.

Spark has a clean template syntax that makes HTML tags stand out. It also has the most sensible design for creating master layout templates I’ve seen. I think it’ll be fairly straightforward to convert our existing XSLT templates into Spark syntax.

Integrating Spark with the C# WebServer will be a challenge, though. Much of the existing Spark documentation assumes you’ll be using the Spark.Web.Mvc classes. Since the C# WebServer project has its own lightweight MVC framework, we’ll need to build our own integration classes.

The C# WebServer project has a way to add alternative template engines, but the hooks provided don’t look like a clean fit with Spark. I think it’ll take some tinkering to get the two to work together seamlessly.

I’ll post some messages to the discussion boards at both open source projects. If you’re interested in helping out with the effort — or would be interested in the results of the project — leave a message in the comments or send an email to info@infovark.com.

Related posts:

1. 3 Useful Visual Studio Tricks for Spark Templates
2. Introducing the SparkServer Project
3. Looking for an IIS Alternative

We’d decided to use WCF because we wanted Infovark to provide web services, and we liked the fact that we could deploy WCF to client machines. Since WCF is built directly on top of HttpListener, a core part of the Microsoft .NET Framework, we wouldn’t need to use System.Net or Microsoft IIS.

But we’ve struggled with WCF for a variety of reasons. First, we wanted to use a REST model for our web services, and WCF’s support for REST architectures lags behind its SOAP support.

Second, there’s no easy way to return HTML from WCF. We tried transforming our XML with XSLT and returning the XHTML results as a Stream. This works, but the programming experience is frustrating.

Last, because of the previous two reasons, we were left with a website that was way too rigid and programmer-like. It didn’t feel like an organic website. The tool we’d picked was forcing us to compromise on our website design goals.

Infovark’s primary mission is to help human beings, not other computers. That means that the look and feel of the web interface should be our number one priority. Awesome web services are nice to have, but happy users are more important.

Web server alternatives

So for the past few months, we’ve been hunting for an alternative web server. We can’t use IIS because its footprint is too heavy. Most IT departments won’t allow us to install IIS on client machines.

We could use Apache. It has a nice embeddable version, but interacting with it via C# is tricky. We’d prefer something a little more Microsoft-native.

That basically leaves us with one commercial option and two open source options.

1. UltiDev Cassini is a commercial product that’s been around for some time. We’re sure it could do the job, but the licensing model is cost prohibitive.
2. C# WebServer is an open source project on CodePlex. It’s been around for two years, but the pace of development seems slow.
3. Open Rasta is the brain child of Sebastien Lambda, an open source framework for the development RESTful development of web sites and services. It’s been getting a lot of attention recently.
4. Kayak is a promising open source project, but it hasn’t reached its first public release yet.

(If you know of other web servers worth investigating, please let us know in the comments!)

Making the switch

More important than picking an alternative web hosting framework for Infovark is the timing of the switch. We don’t want to impede future development.

As a stopgap, we might try plugging in the Spark View Engine to replace our current XML-XSLT-XHTML rendering path. Who knows? If it improves our web development flow, we might be able to keep our WCF base after all.

Related posts:

1. Using WCF for REST, Part 1
2. Review: Restful Web Services
3. Put the “Web” Back in Web Services

The folks working on HTML 5 are proposing a <time> element for the new standard. This makes sense to me. It will help eliminate some of the objections people have raised to the datetime design pattern proposed by the microformats team.

So, problem solved, right? We use UTC for time, and the usual calendar notation for dates. Neat.

Wait a minute. By “the usual” calendar notation, do we mean the modern Gregorian calendar, or…

There’s always a catch

Peter-Paul Koch, a.k.a. PPK, author of the quirksmode blog, reminds us that calculating historical calendar dates is hard. Really, really hard.

He provides an overview of the major calendar reforms in the Western world and points out that the reforms were adopted by different countries at different times. So forming a consistent timeline requires a knowledge of both time and place.

And many important historical dates float. The rules that determine when Easter occurs in the church calendar are complicated, and Orthodox and Catholic calendars disagreed for many years. In the medieval period, years were often numbered according to the local monarch’s reign. In Roman times, extra days were added to the official calendar by decree to prevent the seasons from drifting too far out of line.

If we want to make the <time> element safe for historical use, programmers would have to deal with this mess.

Leave it to the historians

As useful as having universal, consistent <time> element metadata would be, that’s just too hard. Frankly, I skimmed the last bits of PPK’s article myself, and I’m actually interested in the issue. Most working programmers won’t bother.

While it’d be nice to have trustworthy time data, we’re not likely to get it. The standard should reflect that. I vote for assigning a cutoff date for the <time> element. January 1, 1970 works for me.

Related posts:

1. Digital Watches are a Pretty Neat Idea
2. ISO Date Validation RegEx

And then… nothing happened.

This was not what I was expecting. I expected my web browser to follow up with a GET request to the URI I’d provided. But Firefox 3 wasn’t biting. A problem with Firefox? I checked in IE8 and Google Chrome and got the same behavior.

Had I misread the HTTP spec? Did I misunderstand the REST pattern? I grabbed for my worn copy of RESTful Web Services. Nope. HTTP 201 seemed to be the right status for this situation.

Had I blundered into some common error? I checked Stefan Tilkov’s useful list of REST Antipatterns. But I couldn’t find anything that quite matched my situation.

I started Googling, but couldn’t find much apart from this question about HTTP Post on Stack Overflow. There were some cryptic responses (to which I’ve added my own answer now).

Eventually, I discovered what I needed to know from Ben Ramsey’s article on HTTP redirection. It’s part of his series discussing RFC 2616, which describes the HTTP/1.1 protocol.

The answer is that while web service clients will often “take the hint” provided by a HTTP 201: Created response, web browsers won’t. If you actually want a web browser to go somewhere else, you need to send a status code in the 3xx series. In this situation, the status code you want is HTTP 303: See Other.

Once I changed the status code returned by the server, all the web browsers followed up the response with a GET to the new URI.

Related posts:

1. Using WCF for REST, Part 2
2. Using WCF for REST, Part 3
3. Using WCF for REST, Part 1

The question was: What is the best / most flexible way to have WCF output XHTML?

Here’s how we do it at Infovark. While I’m not sure that our approach is the best way, it does the job.

Our approach is to use the DataContractSerilizer to generate XML, then apply a Complied XSLT transform and return the result stream, which should now contain XHTML. Here’s a simplified version of our code:

It works for us, but if you’ve got other, better ideas, please let me know!

Related posts:

1. Better ways to Encode HTML in C#
2. Looking for an IIS Alternative
3. WCF Bad Request

I still believe that both Resource Description Framework (RDF) and the Web Ontology Language (OWL) are too complicated to gain widespread adoption. But maybe we don’t need their academic rigor. Microformats offer a way to get some of the benefits of the semantic web using plain ol’ HTML.

What are microformats? How do they work? Emily Lewis wrote a great series of blog posts introducing microformats. You can also go direct to the source, the microformats homepage, at microformats.org.

An example

Here’s an example of our company address in hCard format.

The address above is marked up in such a way that (some) web browsers can identify it as a street address. But it’s nothing more than ordinary HTML. Here’s what the code looks like:

It’s simple enough that it just might deliver where RDF and OWL fail, becoming part of every web developer’s toolkit.

Get started

You can experiment by creating your own hCards using the hCard creator.

And if you’re using Mozilla Firefox, you can download the Operator add-in to see — and use — microformatted data embedded in ordinary web pages.

Hat tip: Ajaxian for Getting Semantic with Mircoformats

No related posts.

I really want to see this go into production. I really do…

But it won’t. Our designer used Photoshop.

There’s nothing wrong with Photoshop, of course. Nor Gimp, nor Paint.Net, nor any other image editing tool you could mention. And there’s nothing wrong with our designer, either. She really knows her stuff. But I can’t help but feel that perhaps you shouldn’t let your designer touch an image editing tool when she’s working on a web design.

The web is visually limited

When you open an image editing tool, you’re presented with a blank canvas. And the first instinct of any artist or designer is to fill that canvas.

Web pages aren’t canvas. On canvas, or on paper, it’s just as easy to paint one corner as another. This isn’t true of the web. With a web page, one corner is much easier to reach than all the others. In languages written left to right, it’s the upper left hand corner.

Not all sides of the image are equally easy to reach, either. The top and left edges of your canvas are much, much easier to paint than the right or bottom edge.

It’s as if the upper left corner has its own gravity, and draws all other page elements toward it. Like a black hole, it warps your grid.

It is many times harder to place elements in the bottom right corner of a page than the upper left. You’re fighting the pull of gravity the whole way. You’ll have to build on top of block elements like DIV to get there. And beware of the CSS float property. As its name suggests, it isn’t supported by anything. It can wreak havoc on your layout, setting off a cascade of unwanted effects.

The web also suffers from typographic poverty. In an image editing tool, your designer will have access to hundreds — perhaps thousands — of fonts. They can be used to create images freely. But all but a handful of these fonts can be used on the web. Most designers know what fonts are actually available for use. You can cheat in certain cases, and use images instead of text for certain headers and buttons, but many of the effects you’d like to achieve with typography are simply not possible today.

Your web canvas won’t take all kinds of paint, either, unlike an ordinary image file. Not all browsers support transparency in images, for example. Placing gradients and shadows can be tricky.

The web is in motion

But the biggest challenge can be the dynamic nature of a web page. Looking at a design, it can be hard to imagine the effect a blinking, spinning animated widget will have on your audience. It’s also hard to visualize what rollovers or pop-ups might do to the overall feel of the page.

Unlike paper or canvas, a web page can be stretched and scrolled. What does that do to the positioning of its elements? What happens when a user adjusts the font size in the browser, but embedded gifs and jpgs remain the same size?

But the biggest drawback to having your designer work in Photoshop is that to the layman, the web site looks almost finished. They’re pretty, these Photoshop Sirens, and they sing! They will draw you in…

Only the lonely code monkey hacking away at HTML, CSS and JavaScript knows that a screenshot is as far away from a working web page as a screenplay is from a feature film.

No related posts.