I enjoyed the CS Bit from yesterday's Byte capturing a rant about Community Server's use of serialized data in key/value fields from a developer who was frustrated migrating the data in SQL to another application (as opposed to using the CS API to do it.) This isn't about that, but it made me think about how life has been sweet since I've been accessing extended data properties in my custom CS objects as typed class properties. Nothing new here, as it's standard issue in Community Server. An example would be accessing the boolean weblog.AutoNamePosts property. Its pattern is the same as what I'm describing in accessing serialized data as typed class properties, for example, accessing new extended user attributes in a custom DBVTUser object with
MyUser.LastName;
instead of
MyUser.GetExtendedAttribute("LastName");
which brings us to intellisense.
Here are the pertinent aspects of our DBVTUser object.
public class DBVTUser : CommunityServer.Components.User
{
static UserAttributes userAttributes = null;
public DBVTUser() : base() {}
public UserAttributes ExtendedAttributes
{
get
{
userAttributes = new UserAttributes(this);
return userAttributes;
}
}
}
A UserAttributes class holds the properties. An excerpt follows.
public class UserAttributes : CommunityServer.Components.ExtendedAttributes
{
private DBVTUser user = null;
public UserAttributes(DBVTUser _user)
{
this.user = _user;
}
public string LastName
{
get { return user.GetExtendedAttribute("lastname"); }
}
}
We're creating a new UserAttributes class instance within DBVTUser, bringing each of the user.GetExtendedAttribute() items into the DBVTUser fold. Thus, dbvtUser.LastName from a dropdown list and no more GetExtendedAttribute("lastname"). Power up!