I just answered a WCF question on StackOverflow, and decided it was worth cross-posting here as well.
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!
I know it’s possible to transmit Internet Protocol by carrier pigeon, but I’m not sure I could recommend it to our customers with a straight face. By the same token, I’m continually surprised to hear vendors and consultants insist that Web Services can be done without the web.
Yet I’ve seen that claim repeated all over the Internet. Sure, it’s true in the academic sense. Technically, there’s nothing wrong with “webless” web services, just like IP by avian carrier will eventually get the job done (though latency and packet loss are a challenge). But practically speaking, why would you use anything other than HTTP?
The “webless web services” meme has infected a number of good ideas. The SOAP standard is a case in point. At first, SOAP was a simple XML wrapper around an XML payload. (Remember when the S in SOAP stood for Simple?) Then a variety of industry heavyweights jumped on the bandwagon, and soon SOAP could be used with any protocol.
With, uh, a few changes. Like five or six additional specifications. And schema. Lots of schema. Maybe a diagram would help? No?
Nicholas Allen recently shared a great presentation on REST and SOA given by Stefan Tilkov at QCon. Stefan makes some great points about how RESTful web service design aligns well with the goals of Service Oriented Architecture (SOA).
Sure, you could use the WS-* stack if you like, but RESTful web architecture is a proven, scalable and truly simple approach, as long as you don’t mind having to use HTTP.
Much of the added plumbing in the WS-* stack is there to help transition older computer-to-computer network communication technologies. It allows applications that depend on CORBA or DCOM to tunnel through firewalls. But unless you’re trying to retrofit a system built before, say, 1998, you can skip all that stuff.
Wasn’t using web protocol the whole point of web services anyway? As Stefan said in his closing comments: “Protocol independence is a bug, not a feature.”
Use a RESTful architecture for new development. Put the web back in web services.
I’m on record as being skeptical of the semantic web. Or rather, I’m skeptical of much of the marketing hype around the semantic web. That’s not to say that semantic technologies won’t be useful.
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.
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.
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
I’m staring at a gorgeous visual right now. It’s an image of how the Infovark UI might look. I can imagine myself clicking on that tab, and navigating off to a world of beautifuly laid out, useful information…
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.
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.
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.
When we began work on the Infovark user interface, we decided to base it on HTML and JavaScript. Both Gordon and I are very comfortable with web development, so it was a natural choice. We also felt this would give us the most flexibility to run on different platforms with different screen sizes. For better or worse, HTML and JavaScript have together become the lingua franca of interactive design.
Both have their drawbacks, of course. HTML and JavaScript have evolved over time. They each have quirks, particularly with regard to the Document Object Model (DOM). Fortunately there are a wide variety of JavaScript libraries that help programmers working with HTML and JavaScript.
After doing a little research, we settled on on JQuery. JQuery makes us love JavaScript again. It’s a simple, small library that works across all major browsers. It deals with all the inconsistencies that emerge from the last decade of tinkering with web standards. Most importantly, it helps us get things done.
Microsoft has decided that they love JQuery, too. John Resig, the progenitor of the JQuery project, announced in September that jQuery will be distributed with Visual Studio. Two prominent Microsoft bloggers, Scott Guthrie and Scott Hanselman, also discussed the news.
Momentum around the project continues to build. The JQuery blog just posted news about the JQuery 1.3 release and the JQuery Foundation. Most exciting of all (from our perspective as developers) is the release of revamped JQuery API documentation.
Congratulations to the JQuery team! It’s come a long way in three short years.