November 2005 - Posts
In the Photo Album Handler, one of our goals is to have everything in a single file for easy deployment (we still need an additional separate dll in version 2.1 but we're getting there). I also wanted the handler to be able to act like a Control so that it can be integrated in an existing site. Even when used in control mode, the handler part is still necessary to serve the thumbnail and preview versions of the images. We also want to enable the handler just by dropping it into the image directory without having to modify or create a web.config file, which forces us to use a .ashx file.
So how can a single file and even a single class describe both a HttpHandler and a Control?
The first idea that comes to mind is to just implement a WebControl that also implements IHttpHandler. The only way to reference the control in a page would be to use a @Reference directive with a virtual path to force the compilation of the ashx file and to make its types available to the page. Unfortunately, this doesn't work because the types in question will not be available at parse-time, which is when we'll need them if we're going to use the declarative ASP.NET syntax on the page (it works fine if you only need to instantiate the control through imperative code). The solution is to derive from UserControl instead of Control or WebControl. User controls can be referenced and still work at parse-time. The Album is not essentially a user control, but a user control being a Control itself, it does the job. I sealed the class, though, so that nobody has the weird idea to create a .ascx file that derives from it.
This all works perfectly well, but there's still one problem to solve. In Visual Studio's design view, the file will be mistaken for a regular .ascx file and the designer will show the handler's source code instead of any useful design view. I don't think there's a way to make the design view be actually useful for this kind of control (it is, after all, pertty hacky), but we can make things behave a little better by tricking the design view. At the beginning of the .ashx file, I added a comment in the form of:
// <b>This is what will be displayed in the design view</b><!--
This way, the design view will ignore the rest of the file (the source code) as it seems to be in an HTML comment. Of course, I also have the following line at the end of the file:
to end the comment.
Last night, I uploaded the source code and release package for version 2.0 of the photo handler. I'll post more about the details of this new version in the next few days, but I can tell you that most of it has been rewritten, and it can now be used as a standalone application or as a control. What's more, the control is fully templatable, so if you don't like the default rendering, you can take it over and create your own. I've included a template example that reproduces the default rendering, which should give a good starting point.
Download the handler from here:
UPDATE: the handler is now hosted on Codeplex.
Well, if you have not pre-ordered six months ago and weren't ready to spend a good part of yesterday and last night freezing in front of Best Buy, your chances of scoring an Xbox 360 were near zero. So if you're like me, you just made fun of the guys waiting during this wet and cold night and just resigned to go home and wait for the next shipments.
Oh, just in case you're wondering, no, being a Microsoft employee does not give any priviledges when it comes to buying an Xbox (except if, like Julien, you work in the Xbox division, thanks for reminding me, Julien, it's doesn't hurt. At all). We just wait in line like anybody else. Well, we do get prices on games and accessories, which is always good, but for some reason my old Xbox does not seem to like the new PGR.
Here's a misconception I see a lot on the forums lately. There is this idea that controls on a master page should always keep their state across content pages that use it.
When you navigate away from a page (i.e. when you click a link), you go to another page, with another instance of the controls on it, so of course the new controls on the new page have no way of knowing about the state of the controls on the other page.
Having a master page does *not* mean that all the controls on the master page have a unique instance that would be shared by all pages that use this master page. The master page is nothing more than a template, it's not any kind of singleton.
So the only way you can maintain the state across different pages (whether you use a master or not) is by storing it in Session and using that information when a new page is loaded. This can have severe performance drawbacks as you store state for each user but is more or less what WebParts do with their personalization data...
Another approach is to consider that if you need to maintain state across all those pages, maybe they are the same and you need to move from a many-page model to a single-page model.
Please note that the navigation controls (a.k.a. Menu, TreeView, SiteMapPath) will automatically select the current node in the site map according to the URL you're on, giving a minimum version of this application-level state management some were expecting from master pages.
If you want to check out what a real-world complex Atlas application would look like, Nikhil put together an amazing Atlas app around Virtual Earth and a few other web services such as Flickr and Amazon.
Not only is this application technically impressive (check out the source code: the page is purely declarative, using only XHTML and XML-script markup), it's also nicely designed and has the classical "Nikhil touch" that you know if you read his blog. Of course it still has a few rough edges like Firefox compatibility and performance but still it's impressive to see what can be done with pre-alpha technology like Atlas.
It's amusing to note that like anything great, it attracts some pretty stupid comment, like this one: "If it's not web standards, it does not belong on the web. Please take that down."
The Virtual Places blog post: http://www.nikhilk.net/VirtualPlaces.aspx
The Virtual Places page: http://apps.nikhilk.net/VirtualPlaces/