October 2003 - Posts
Longhorn is a service oriented and XML configurable world. The new OS is finally really different; different to look at and under the hood. The vector graphics UI is really wild. Especially the first time you see a button rotated/scaled by simply setting a property in a form. Avalon offers all kinds of new sexy possibilities for UI in windows. The WinFS data store is yet another layer of new functionality and programmability.
See the Longhorn Dev center for more.
Yukon is just too cool. First, you can write stored procedures in any .Net language. Second, you can write libraries that can be bolted onto Yukon and extend TransSQL. The extensions can be used in queries like native SQL syntax. Third, TransSQL has been extended with nice solutions to cursors and other troublesome things. Fourth, exposing stored procedures as web services is just as simple but now there is a direct mapping to the database that no longer needs IIS. Fifth, XQuery.
See “Yukon“ for more
You know all those things that you wonder about in the back of your head while building web services? Things like what happens if the other side of the wire is down, the security handshake across boundaries, the diverging model from OO and style in service orientation. Well, all these protocols, specifications, and messaging tools are rolled into a nice set of namespaces, classes, and are exposed as the framework called “Indigo”. For more see “
Code Name Indigo” by Don Box.
For those of you hungry for the new stuff, you can start reading about it at http://msdn.microsoft.com/events/pdc/
Several big pieces of infrastructure being deployed at the same time. In no particular order, they are: Longhorn (Avalon, WinFS), Yukon, Indigo, and to a lesser degree Whidbey. Everything is extremely cool. All the way from the vector graphics of Longhorn’s UI to C# in stored procedures.
If you follow the approach in my last entry, you will need to write a section handler for every section type you have. Andera has a better solution. His approach is to write a handler that will work for any section type.
public class XmlSerializerSectionHandler : IConfigurationSectionHandler
{
public object Create(
object parent,
object configContext,
System.Xml.XmlNode section)
{
XPathNavigator nav = section.CreateNavigator();
string typename = (string) nav.Evaluate("string(@type)");
Type t = Type.GetType(typename);
XmlSerializer ser = new XmlSerializer(t);
return ser.Deserialize(new XmlNodeReader(section));
}
}
This handler is generic and you can handle any type. For example, consider the following config file:
<configuration>
<configSections>
<section name="MyStuff" type="ConfigurationHandler.XmlSerializerSectionHandler, ConfigurationHandler"/>
<section name="MyNewStuff" type="ConfigurationHandler.XmlSerializerSectionHandler, ConfigurationHandler"/>
</configSections>
<MyStuff type="ObjectTemplate.MyStuff, ObjectTemplate">
<Foo>1.234</Foo>
<Bar>A bunch of information</Bar>
</MyStuff>
<MyNewStuff type="ObjectTemplate.MyNewStuff, ObjectTemplate">
<Foo>1.234</Foo>
<Bar>A bunch of NEW information</Bar>
</MyNewStuff>
</configuration>
The “MyStuff” and “MyNewStuff” classes are:
public class MyStuff
{
private float foo;
private string bar;
public float Foo
{
get { return foo; }
set { foo = value; }
}
public string Bar
{
get { return bar; }
set { bar = value;}
}
}
public class MyNewStuff
{
private float foo;
private string bar;
public float Foo
{
get { return foo; }
set { foo = value; }
}
public string Bar
{
get { return bar; }
set { bar = value;}
}
}
The configuration would be called in the following manner:
MyStuff ms = (MyStuff) ConfigurationSettings.GetConfig("MyStuff");
Console.WriteLine(ms.Bar);
MyNewStuff mns = (MyNewStuff) ConfigurationSettings.GetConfig("MyNewStuff");
Console.WriteLine(mns.Bar);
I was writing an application this weekend and needed to extend the predefined sections in the .Net config file. I am sure many of you will want to do the same at some point. This entry is a how-to.
Let’s assume you want to make the application owner part of the config file. You want to have a something like:
<UserInfo>
<UserName>doval</UserName>
<Email>doval@mit.edu</Email>
</UserInfo>
The first thing you need to do is write a configuration handler.
public class UserInfoSectionHandler : IConfigurationSectionHandler
{
public object Create(
object parent,
object configContext,
System.Xml.XmlNode section)
{
XmlSerializer ser = new XmlSerializer(typeof(UserInfo));
return ser.Deserialize(new XmlNodeReader(section));
}}
The code above implements the IConfigurationSectionHandler, picks up the section, and returns an object. Next you need to register the config section handler in the config file.
<section name="UserInfo" type="ConfigurationHandler.UserInfoSectionHandler, ConfigurationHandler"/>
Your entire config file would look like
<configuration>
<configSections>
<section name="UserInfo" type="TypedConfigurationHandler.XmlSerializerSectionHandler, TypedConfigurationHandler"/>
</configSections>
<UserInfo type="ObjectTemplate.UserInfo, ObjectTemplate">
<UserName>doval</UserName>
<Email>doval@mit.edu</Email>
</UserInfo>
</configuration>
Note that in type="ObjectTemplate.UserInfo, ObjectTemplate", the first part refers to the class you binding the information into and the second refers to the library (DLL) name. In this sample the class is:
public class UserInfo
{
private string userName;
private string email;
public string UserName
{
get { return userName; }
set { userName = value; }
}
public string Email
{
get { return email; }
set { email = value;}
}
}
Dan pokes at knowledge hierarchy indirectly. If we think of the web space as the raw material, the bottom of the knowledge tree, then sites like slash dot are a node up on the tree. I see Dan’s database storage discussion as an effort to go up another node. As I reflect on this idea I am sensing an emerging structure. Is there a practical, agent-based, structure at work here?
Note: my use of “knowledge” is very loose in the previous paragraph.
I was thinking of Dan’s observations on intellisense. Is there a parallel between intellisense and ms-word’s autocorrect/spellcheck?
Admittedly, I am a bad speller. Thinking back, I think my spelling away from the word processor has improved for my commonly misspelled words. However, I think my sense for spelling infrequently used words has deteriorated. On the plus side, my grammar sense has improved. Knowing ms-word often misses spotting bad grammar, I have gotten used to double checking anything word thinks is incorrect. After some time you start picking up the rules and can spot the real mistake from the false alarm.
I appreciate the grammar check because I feel it improves my writing by helping think about grammar and structure. Wouldn’t something similar be useful in computer code? Like the use of grammar check I described, the check need not solve the problem. In many cases the check may simply warn the coder something is odd, unusual, or bad style. Something basic should not be too difficult.