Spiels, they’re spread throughout your application. They’re used for giving user feedback anywhere during the application’s workflow. A spiel is a business term referring to a system generated plain text response to end users in typical programmer jargon. They’re confirmation, notification or error messages. They are text that’s most of the time, not given any real thought by a developer. Besides, a developer more focused on building and coding rather than communicating to the end user using the proper words and phrases. That’s the job of the business proponents, or the subject matter experts.
Developers typically code in this fashion:
Label1.Text = "Registration Successful.";
Here’s a typical scenario the development lifecycle involving... spiels!
1. Developer sets the spiel text after a successful operation. (E.g. User registration screen). Developer would usually give it a straightforward text spiel. (E.g. “Registration successful.”).
2. Developer does practice #1 over and over again, spread through the different pages and modules.
3. Developer presents system to project proponent. Business person says to change this and that spiels, modify grammar and so on and so forth. (Business persons have a knack for being whimsical at times.). They tell you it’s not properly communicating the intended message, or to put in their branding message or some vague and obscure reason that developers really don’t mind not hearing but they have to.
4. Developer does as expected and edits all pages that are affected.
5. System is finally launched in production.
6. #4 happens again.
7. #5 and #6 follows.
8. Months in into launch date passes, #s 4-7 has now become routine for the developer.
Of course I am all about improving developer efficiency. Another possible alternative is storing the spiels in the configuration file.
Example (web.config)
<appSettings>
<add key="successText" value="Registration Successful"/>
</appSettings>
Ergo:
Label1.Text = ConfigurationManager.AppSettings["successText"].ToString();
Using this method would:
1. Blow up the size of the configuration file, like web.config as the spiels increases.
2. Developer has to keep track of the all the keys which uniquely identify
corresponding spiel value.
3. Ultimately make it hard to maintain.
I wanted a convenient model that would enable me to achieve the following goals.
1. Centralized location of a spiels file. I wanted a quicker method of data access other than a back-end storage at the same time I wanted it to be easily editable on the fly. I turned to xml.
2. Storing and retrieving spiels contained in an external xml file would require a key to identify the text block. I didn’t want to memorize the key, nor keep on toggling to the key definition in the xml file. I wanted intellisense to do that for me.
3. Easy model for adding / deleting and updating spiel data.
Completed, I imagine my code to consume my spiel getter class like so.
Label1.Text = Spiels.get(keys.UserNotRegistered);
Below is the sample xml file implementation:
<?xml version="1.0" encoding="utf-8" ?>
<SPIELS>
<spiel title="UserNotRegistered">
<text>User is not registered with the system. </text>
</spiel>
<spiel title="WrongCredentials">
<text>Please select a request group</text>
</spiel>
</SPIELS>
My class definition (Spiels.cs)
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Xml;
using System.Xml.Linq;
public class Spiels
{
public static string get(keys k)
{
string key = getKey(k);
string returnSpiel = "";
string spielXmlFile =
HttpContext.Current.Server.MapPath("Spiels.xml");
IEnumerable<string> myXmlQuery =
from allSpiels in
XElement.Load(spielXmlFile).Elements("spiel")
where (string)allSpiels.Attribute("title") == key
select (string)allSpiels.Element("text");
foreach (string s in myXmlQuery)
returnSpiel = s;
//..return to calling
return returnSpiel;
}
private static string getKey(keys k)
{
string targetKey = "";
switch (k)
{
case keys.UserNotRegistered:
targetKey = "UserNotRegistered";
break;
case keys.WrongCredentials:
targetKey = "WrongCredentials";
break;
}
return targetKey;
}
}
public enum keys
{
UserNotRegistered,
WrongCredentials
}
The meat of the code is in the get(keys k) static method call, passing an enum data type. I’ve also defined a helper class, getKey(keys k) , accepting an enum parameter for retrieving the keys in the xml file. The enum definition is the spiel “primary key”, with an attribute of “title”. I enjoy working with enum data types because of the quick intellisene support it gives me every time I reference them in code. (Image above)
The main method, get(keys k) uses Linq to XML to quickly query for the correct xml element called “text” which is the spiel text block given the key, an attribute called “title.”
Asides from achieving my goals mentioned above, this example can also serve as a starting point of getting into Linq To Xml.