| Henry's profileUtterances on Software E...PhotosBlogLists |  Tools  Help |
|
May 25 Frameworks suck... because they fail to do what some/most/any/one developer expects them to do. Say you have a list of key-value-pairs you want to persist. For instance, in a file. In the days of Microsoft.NET 2.0 this obviously is an IDictionary, and, for sake of simplicity, let's assume it's IDictionary<string,string>. Save to file you could write yourself, but we are framework-aware and want full leverage. So, the framework has serialization. BinaryFormatter has issues around typing, security and versioning and SoapFormatter is deprecated and doesn't do generics anyway. DataContractSerialization is 3.0 but we have our good friend XmlSerializer who's as good as it gets. So we write new XmlSerializer(dictionary.GetType()).Serialize(stream, dictionary) and hit the floor of the framework. Good intention, reasonable expectations, utter failure. Of all types in the world, XmlSerializer cannot, will not, want's not serialize IDictionary. It is special cased to fail on IDictionary; it doesn't support it due to "schedule constraints". Blatant ignorance of the fact Dictionary implements ISerializable. So what do we do? We know IDictionary is a list of KeyValuePairs. Since we're not planning on modification, KeyValuePair[] is sufficient. No complaints? Well, KeyValuePair is not exactly XmlSerializable because it's immutable. A good thing anywhere else, but here, it sucks. Long story short?
public struct Pair<TKey, TValue> { public TKey Key; public TValue Value;
public Pair(KeyValuePair<TKey, TValue> pair) { Key = pair.Key; Value = pair.Value; }
public static implicit operator Pair<TKey, TValue>(KeyValuePair<TKey, TValue> pair) { return new Pair<TKey, TValue>(pair); }
public static implicit operator KeyValuePair<TKey, TValue>(Pair<TKey, TValue> pair) { return new KeyValuePair<TKey, TValue>(pair.Key, pair.Value); } }
public class DictionarySerialization<TKey, TValue> { private readonly static XmlSerializer serializer = new XmlSerializer(typeof(Pair<TKey, TValue>[]));
public static void Serialize(Stream stream, IDictionary<TKey, TValue> dictionary) { Pair<TKey, TValue>[] items = new Pair<TKey, TValue>[dictionary.Count];
int index = 0; foreach (KeyValuePair<TKey, TValue> item in dictionary) { items[index++] = item; }
serializer.Serialize(stream, items); }
public static void DeserializeInto(Stream stream, IDictionary<TKey, TValue> dictionary) { Pair<TKey, TValue>[] items = (Pair<TKey, TValue>[])serializer.Deserialize(stream);
foreach (Pair<TKey, TValue> item in items) { dictionary.Add(item); } } } What have I done to deserve this? Please note: source code fragment sample provided "AS IS", without support or warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and non-infringement. In no event shall the author or copyright holder be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software. May 16 Check Please!A colleague of mine just asked me what word to use to initiate checkout in a US restaurant. I immediately replied "'Check, please!', or more polite 'Could I/we have the check, please?'", but I had to look up various references to try and clarify the relation between "bill" and "check". One "source" is this blog entry on dine-out-behavior, that I find too interesting and concise to not juice it for my next search. But that guy's using "check" and "bill" in such a whirl that it's hard to figure out when to use one vs. the other. I guess, "check" is the act of producing the "bill", but who cares about such distinctions? In case somebody's wondering: In German it's a choice of
May 14 I still know for what you searched last summerGoogle reveals why and which information they retain in a blog post on their Official Google Blog. It goes to show, pretty much any search gets retained with it's originating IP address, and how it relates within an entire stream of searches from the same user (using cookies or hidden fields or whatnot). They'll keep it around between 12 and 24 months, for the worlds law enforcement agencies to ask for. Although they're not actively associating a person's identity with the queries (unless they have a Google account), I'm sure law enforcement will overlook that "minor" issue and demand proof that folks have no idea how Bad Query Guy's Google cookie got on their machine. Innocent until proven guilty by search engine. Mad world. May 03 BoundField.DataFormatString="{0:d}" doesn't work for DateTime unless HtmlEncode="false"http://gaskell.org/formatting-data-in-databound-controls/ And, read the f#$%^&king manual. |
|
|
