Public Class GeoffAppleby

Cool things i've discovered.

Have you got here via some sort of google search for serializing hashtables in .net? If so, you'll get more/better info from a newer entry of mine: How to Serialize a Hashtable (and a Date). Many people come here via this sort of search, so I wrote something better :)

I discovered a few interesting things over the last couple of weeks. We've been working hard to get a prototype done by tomorrow, as a proof of concept of a) what we vision needing to write and b) let's prove right now that we can do the hardest bits that we expect to face.

Most of those 'hardest' bits weren't rocket science, just more time consuming than anything. and besides, i didn't need to do that much of the hard bits, so why do i care? :)

It's a data driven app that needs to have both a web interface and (eventually) a desktop rich client. As a result, it's all driven via a web service, so the web site and desktop app can both have a common place to call. this is all fine. My bit was to hack up a database (only hack, which is good, because SQL is my weakest point) and write the web service.

So what have i learned?

1. We're dealing with a lot of data, so we don't want to return it all at once. returning bits and pieces at a time is a good thing. So the bits i send to the client (web server for the web app) are generally a collection of 'objects' - custom classes that encapsulate the data. But i like to be able to search these collections quickly, so i keep them in a hash table. But you can't serialize a hash table. So you implement your own serializer. But you still can't pass it a hash table. What's the best answer i found? You can copy all the items out of the hash into an array, and serialize that. Deserializing on the other end just means feeding the array back into the hash table. Sweet.
2. We're navigating the data in a windows-explorer-like interface. A tree and a list, with a property grid type thing beneath the list. Items in the tree and items in the list are much lighter weight than the item that goes in the property grid, so for populating the tree and list, i use one class, and for the property grid i extend it by inheriting that class into another one with further properties and stuff. I cast the derived classes to the base class, and then I'm always passing around what appears to be the same objects all the time. But the xmlserializer only deals with one type any given time, right? It appears not. In a couple of the constructors for the xmlserializer, you can specify an array of extra types - these being extra types that it's allowed serialize. So i have Class B (derived from Class A), cast it to Class A, then serialize that, my first thought was that it would only serialize the Class A parts of it - but no, it throws an exception. In the constructor for the xmlserializer, if you tell it Class A and Class B, then cast a Class B item as Class A then serialize it, it will serialize as Class B. And deserialize too, even if you return a Class A object, it will really be a Class B object. This is long winded and rambling, but how cool is that?!
3. Continuing on from 2, they don't need to be related types either. One of the properties of Class B was an object of Class C. If i include class C in the xmlserializer constructor, then it happily returns that too, embedded within. Wow.
4. Once i stopped and thought about it, it made perfect sense, but when i just rushed into the coding i discovered that you can't serialize a read only property. Not surprising i know, but damn!
5. I spent the last two weeks writing a web service that kicks pretty major ass. A coworker spent the last two weeks writing some funky custom server controls for asp.net. Today we glued it all together and got our prototype up and going with almost 24 hours to spare. I then took an hour out of my day and wrote the desktop app in an hour and a half. An hour and a half real time, that is - i was reading blogs and email at having smoke breaks at the same time. It was only about 120 lines of code, half of which i could have refactored out, but i was only hacking something together to prove a point. Windows forms rocks. (Also, i don't think asp.net is for me - i just can't get my head around it :)
6. My team leader rocks. He's got a hell of a clue, and since we agree on most things, we don't' need to fight nearly as often as we could. He's a whiz at asp and TSQL. But he doesn't know any real programming, especially .net - it changes your way of thinking when you have to explain OO design decisions and implementations to someone who so often views the answer to a problem as 'well, just set a global and ...'. I think the world of you dude, but hurry up and learn to be a real coder! *grin*
7. When forwarding on authentication tokens to contact a web service that might require NTLM or basic auth, from a we sight might require NTLM or basic auth (not necessarily the same), you can't always forward on your current credentials easily. The System.Net.CredentialCache is filled no matter whether you use NTLM or Basic, but you can only forward them on to an NTLM scheme. If you arrived at web site a using basic, and the web service being called from there requires NTLM, then you have to get the user name and password from the server variables and create a new credential object. All other combos work pretty fine. Annoying (but understandable - NTLM  doesn't send a password, just a token, so the web service can't validate against a Basic schema).

And this is why i love coding. Hitting challenges and then finding the answer. I just don't have much interest in ASP.net it seems :) I just need to get this toolbar finished now! Things have been so busy of late i keep trying to work on it but not having time :(