Caching for SubSonic

I’ve had some time recently to get more comfortable with SubSonic and I’m really enjoying using it.  When they add support for joins, it should rock…  and hopefully they find a way to have it co-exist and complement linq when that is released.  One thing that SubSonic seems to lack is support for caching objects.  I looked around the web, but couldn’t find a helper class/method that did what I wanted, so I whipped one up that you can use as a starting point if you’re looking for some way to cache your objects:

using System.Web;

using SubSonic;

 

namespace Util

{

    public class CacheUtil

    {

        public static ListType FetchAll<T, ListType>()

            where T : AbstractRecord<T>, new()

            where ListType : AbstractList<T, ListType>, new()

        {

            string key = typeof(T).ToString();

            object item = HttpContext.Current.Cache[key];
 

            if (item == null)

            {

                ListType collection = new ListType();

                collection.LoadAndCloseReader(AbstractRecord<T>.FetchAll());

 

                HttpContext.Current.Cache.Insert(key, collection);

                return collection;

            }

            return (ListType)item;

        }

 

        public static void ClearCache<T>()

        {

            string key = typeof(T).ToString();

            if (HttpContext.Current.Cache[key] != null)

            {

                HttpContext.Current.Cache.Remove(key);

            }

        }

    }

}

Mean Fiddler – REST services for nHibernate

I came across the Mean Fiddler project lately, and will definitely take a look at the source when I free up.  It is a replication of Microsoft’s Astoria project, but it uses nHibernate.  The new version supports XML, JSON, and HTML formatting, all http verbs (GET, PUT, POST, DELETE), and much more…

I’ve been hard at work on a pretty significant update to Property Center and haven’t really felt that I could blog about it.  The update will be released in a few weeks and I’ll continue to blog on a more normal basis again.

Upgrade to Windows XP

Well, now I’ve gone and done it… I formatted my laptop last night in order to revert back to Windows XP.  Vista was just running like a pile and really didn’t give me any added joy or features.  The laptop hasn’t run better (except possibly with my Ubuntu install) and I couldn’t be happier with this setup.  Everything feels a little snappier now.  Perhaps Vista is neat and performs well with a top of the line dual core system, but for my entry level laptop, it just wasn’t practical. 

Protoculous

I just became aware of Protoculous, a compressed version of Prototype and Script.aculo.us.  It works the same as the uncompressed version, but reduces the size of both from 215k to 131k.  Using gzip compression seems to bring it down to around 32k.  It’s currently in my development branch and I plan on using it with the next major update for Property Center.  If you’re using Prototype but not Script.aculo.us, I’d suggest having a look at Protoculous anyway.  He includes a compressed version of just Prototype that reduces the size from 96k to 59k.  Gzip compression continues to reduce that to around 16k.
 

Firefox and XML Parsing Error: no element found

I was receiving the following error with only Firefox: XML Parsing Error: no element found.  Basically, I was trying to visit a page that has no content, with Ajax.Request.  The requested page performs a passive operation on the server, using just query string parameters, and it is not meant to return content.  Since my doc type is xhtml, Firefox thinks that the document is an xml document and throws an error because it contains no data.  So, as a quick fix, I just added this as the content of the page.

<html xmlns=”http://www.w3.org/1999/xhtml”>

    <head><title></title></head>

    <body></body>

</html>

 

That fixes things, and since I don’t expect a return value, it’s ignored by my app.  Hope it helps someone tracking down the same issue.

First impression of Windows Live gadgets…

In the tradition of giving our users choices, I was going to add Property Center gadgets for Microsoft Live.  

As always, MS takes the course of the c/c++ developer.  Their gadget api is needlessly complex, imo.  Whereas Google allows a nice mix of html and javascript, Microsoft gadgets are pure javascript.  Not only that, they require that you implement methods such as Dispose and initialize… those should be abstracted away and automatically handled by the widget framework, imo.  Basically they require knowledge of the atlas framework when writing gadgets…

Next… settings/preferences… Google provides a nice easy way of allowing users
to change settings.  The end user experience is consistent across all gadgets and dead simple to implement as a developer.  This is sort of the time that I decided to scrap Property Center Live.com gadgets for the time being.

Another thing that bugs me is that there is no way to view the source of existing gadgets.  I personally think that’s a major mistake, since the majority of people create their gadgets by using someone else’s as a starting point.  Perhaps they do this, though, so that people don’t see how complex creating a gadget for live.com is.

Honestly, how do they expect mass gadget/widget production like Google
and Yahoo have seen, when creating a gadget is such a pain in the ass?

So for right now. I’m going to hold off on Live.com widgets.  When they update their framework to support basic widget requirements, I’ll take another look.  See you in a year or two live.com.

Capture confirm dialog with WatiN

Tonight, I ran into an issue with with WatiN, an automated browser-based test tool for .net.  Let me first describe my setup… I’m using NUnit 2.4 to drive WatiN.  I could have used NUnitAsp, instead of WatiN, but I like the idea of using an actual browser instance rather than mock objects.  Btw, the NUnit support that Resharper provides is just awesome.  I’m sort of pissed that it took me so long to try it out.  Give resharper a try, if you haven’t yet…

So.. back to the problem that I came across tonight.  Everything was peachy until I needed to interact with a javascript confirmation prompt.  This is the solution that works for me:

ConfirmDialogHandler deleteHandler = new ConfirmDialogHandler();

using (new UseDialogOnce(Browser.DialogWatcher, deleteHandler))

{

    Link deleteLink = Browser.Link(Find.ById(“DeleteLink”));

    Assert.IsTrue(deleteLink.Exists);

    deleteLink.ClickNoWait();

 

    deleteHandler.WaitUntilExists();

    deleteHandler.OKButton.Click();

}

Browser.WaitForComplete();

One thing to note is that Browser just represents the IE object that is created in my TextFixtureSetUp method.  The UseDialogOnce class is:

public class UseDialogOnce : IDisposable

{

    private DialogWatcher dialogWatcher;

    private IDialogHandler dialogHandler;

 

    public UseDialogOnce(DialogWatcher dialogWatcher, IDialogHandler dialogHandler)

    {

        if (dialogWatcher == null)

        {

            throw new ArgumentNullException(“dialogWatcher”);

        }

 

        if (dialogHandler == null)

        {

            throw new ArgumentNullException(“dialogHandler”);

        }

 

        this.dialogWatcher = dialogWatcher;

        this.dialogHandler = dialogHandler;

 

        dialogWatcher.Add(dialogHandler);

    }

 

    public void Dispose()

    {

        Dispose(true);

        GC.SuppressFinalize(this);

        return;

    }

 

    protected virtual void Dispose(bool managedAndNative)

    {

        dialogWatcher.Remove(dialogHandler);

 

        dialogWatcher = null;

        dialogHandler = null;

    }

}

It’s important to note that I use the method ClickNoWait() rather than Click(), for the delete link.  This prevents the situation where WatiN is waiting forever for the click event to finish, while IE just sits with the confirm prompt.

Google gadgets for Property Center

I’ve been playing around with Google gadgets over the last day and a half.  Overall, the experience has been fine.  Writing the actual gadget is basically a mix of html and javascript.  They provide helper methods to grab feeds, xml, or just html content.  To go along with this experiment, I had to write a public api for Property Center.  The api is still very much a work in progress, so I’m not going to officially announce it, as it will likely change in the coming days/weeks.  I’ll mention that I chose not to go the wsdl/asmx route and instead opted to use straight http requests.  I feel this gives the most flexibility to support languages outside of .net.  It also allows me to support REST requests in the future with little modification to the api.

The one thing that I did find is that the google gadget api in IE doesn’t like xml documents with encodings other than utf-8.  In my api code, I was using an XmlWriter object to write to a StringBuilder.  I found out that in this configuration, the xmlwriter will ignore the encoding type, opting always for utf-16.  So… I modified my code slightly to use the response stream instead and things are kosher now.  I believe that it’s a bug with Google Gadgets (not reading encodings other than utf-8) and a bug with Microsoft (not following the specified encoding with XmlWriter and StringBuilder objects).

You can check out the Property Center gadgets by clicking here.