Friday, October 17, 2008
System.Reflection Interview Question
Let me give you an example. In your middle tier, you are going to pass a string into a private void HandleColorChoice(string myStrColor), and based on the color, you are going to implement different options. You're only starting out with red, yellow, blue, but over time, your code needs to handle even 100 different color implementations.
You could handle this scenario with a switch (I've done it myself), but if you don't have all the implementations in hand when you go live, that's not a sustainable solution. Instead, think of HandleColorChoice as your switchboard operator who decides which method to call. How does it know? Well, when does it know is the more important question...not until the string is passed, and bingo, that's not until runtime. Deciding which method to call is a piece of cake:
string colorFunctionName=string.format("Handle{0}Color", myStrColor);
We put all of these implementations in a separate assembly which you can build and deploy separately, a much easier scenario for us, and use reflection to call the methods. To use the System.Reflection namespace, you have to become familiar with the System.Type class, it will expose all the metadata for your assembly that you need to load at runtime. Here's a simple implementation for HandleColorChoice:
objAssembly=System.Reflection.Assembly.LoadFrom(str); //enter the path to your assembly
Type objType = objAssembly.GetTypes();
MemberInfo[] arrayMemberInfo;
try { //Find all static or public methods in the Object class that match the specified name.
arrayMemberInfo = objType.FindMembers(MemberTypes.Method
, BindingFlags.Public BindingFlags.Static BindingFlags.Instance
, new MemberFilter(colorFunctionName)
, "ReferenceEquals");
for(int index=0;index < arrayMemberInfo.Length ;index++)
{
objType.InvokeMember(arrayMemberInfo[index].ToString());
}
}
catch (Exception e) { Console.WriteLine ("Exception : " + e.ToString() ); }
}
Now this is just the most basic idea of what you can do with System.Reflection, but be ready for the question! Good luck :)
Thursday, October 25, 2007
GridView must be placed inside a form tag with runat=server
A few simple lines of code would typically handle this:
string listRecipients = ConfigurationManager.AppSettings["candidateTestEmailList"].ToString();
StringBuilder sb = new StringBuilder(2000);
pnlResults.RenderControl(new HtmlTextWriter(new System.IO.StringWriter(sb)));
//---------------------------------------------------------------------
// Send to the mail handler class
//---------------------------------------------------------------------
MailHandler mh = new MailHandler();
mh.SendMail(listRecipients, "Test Results " + tbName.Text, sb.ToString());
But I was getting the error...Gridview must be placed inside a form tag with runat=server. And of course it is, and the panel and the label are not throwing a similar error. I found this nifty fix:
public override void VerifyRenderingInServerForm(Control control)
{
return;
}
found it here: http://blogs.x2line.com/al/archive/2004/10/08/576.aspx
and it worked like a charm. I didn't spend more time investigating which controls require the fix, but if I see the error, I know where to start. Thanks Anatoly!
Wednesday, October 17, 2007
Blow by Blow Heavyweight Fight -Marriage of Yahoo API Widget with ASP.Net 2.0
When I say really simple, that was the theory, the reality was a little different. The problem was, embarrassed to admit this, our job postings and our press releases are static text on our website and when HR comes up with a new posting, it takes a developer time to release a new page. So, I want to free up our developers from spending time on administrative tasks such as these. Duck soup, right? Well, I also wanted to get my feet wet with some of the new widgets in the Yahoo Javascript API library...two birds with one stone!
I already have a project open in my VS2005 IDE, so I created a new page and copied and pasted my Yahoo code in. That took all of 5 minutes. The control that sees all the action is a textarea. I took the default markup from Yahoo and added runat=server attribute; this is all you need to expose your HTML controls server-side. Here are the steps I'm going to take in my code-behind to hook up this control to my html txt job postings files:
- Pass in my job id in my query string; this id will be the name of the txt file without the extension.
- Use the System.IO namespace.
- Use the StreamReader to get the contents of the text file and place it in the text area.
- Use the StreamWriter to get the contents of the text area and write it to the file.
- I have the ability to overwrite the original file or create a new file, but that is just a detail.
This was the code for the Page Load event:
if (!IsPostBack)
{
//read query string and include a job if one exists
try
{
if (Request.QueryString["id"] != null)
{
job = Request.QueryString["id"].ToString();
//get the contents of text file
msgpost.Value = GetJobFileContents(job);
}
else
{
btnUpdateJobPosting.Visible = false;
}
}
catch (Exception ex)
{
msgpost.Value = ex.Message;
}
}
I also needed two supporting methods to do the Getting and Setting of the text file value:
protected string GetJobFileContents(string job)
{
string path = Server.MapPath("../jobs/");
path += job + ".txt";
StreamReader sr = new StreamReader(path);
string strContents = sr.ReadToEnd();
sr.Close();
return strContents;
}
protected void SetJobFileContents(string job)
{
string path = Server.MapPath("../jobs/");
path += job + ".txt";
StreamWriter sw = new StreamWriter(path, false);
sw.Write(msgpost.Value);
sw.Close();
}
Adding all this to the code behind took about 15 min. Then I hooked up my click events, I had two buttons, one for Updating and one for saving a new file with a textbox to put in a filename.
At this point you may be asking why I'm using server-side code with a javascript API. Well, to write a file to the server, you have to use server-side code. I can execute a server-side function with JSON using AJAX on the client, but that's more work than just using the native .Net postback events. The only reason NOT to use the postback events is to minimize round trips to the server (we've already said we have to go to the server!) or to give the user a better experience without an entire page refresh...very valid in most cases, but not in mine; this control takes up the whole page, it's the raison d'etre (raze-on det: reason for being ) of the page.
So yeah, I took the easy road and didn't really go through my paces with the new API, so the payback was, YES, it didn't work! All the events were handled properly, executed perfectly, as planned, files were read, files were saved, but no changes were reflected. Putting a breakpoint on the sw.Write(msgpost.Value) line revealed that the value of the textarea was the old, unedited value. I tried changing the property I was reading, using InnerText and InnerHtml instead of Value, but they all gave me the same data. I also tried reading the Request object with no luck, it also held the old, before-edit value.
I remembered back in the days of 1.1 where the autoeventwireup used to execute all the code twice so I stepped through the code from start to finish to determine that I was NOT reading from my file and overwriting the changes with the old text. My whopping 20 lines of c# code were doing exactly what i wanted. So I commented out my API code on the client (aspx), and made it a plain textbox, and VOILA, I was getting exactly what i wanted, but my rich text editor was gone. Now I actually had to read the documentation to see what my options were.
I found this little property:
handleSubmit -
Boolean
Config handles if the editor will attach itself to the textareas
parent form's submit handler. If it is set to true, the editor will attempt to
attach a submit listener to the textareas parent form. Then it will trigger the
editors save handler and place the new content back into the text area before
the form is submitted.
Default Value: false
So I changed the value to true, and we got some good news and we got some bad news. Good news is that the value of the textarea now reflects the changes made, but the bad news is my buttons now fire the Page_Load event, but not the click events. So now I'm two hours into what I planned to be a half-hour quickie, so I just threw in a hack. I hooked up the following to the else block of my !IsPostBack check:
else
{
//we're saving the contents
try
{
if (tbJobPosting.Text.Length > 0) //we're writing to a new file
{
//remove .txt if it's in the filename
job = tbJobPosting.Text.Replace(".txt","");
//set the contents of text file
SetJobFileContents(job);
//redirect to page
Response.Redirect("../jobs/jobposting.aspx?id=" + job);
}
else //we better have a query string
{
if (Request.QueryString["id"] != null)
{
job = Request.QueryString["id"].ToString();
SetJobFileContents(job);
}
}
}
catch (Exception ex)
{
lblUserMessage.Text = ex.Message;
}
}
It isn't pretty, but it works. It's not even the best, free, rich-text editor out there, and I'm sure I'll be replacing it with something else, but I learned some interesting things! Oh, and if you're going to be allowing html content in your postback, don't forget to add validateRequest="false" to your Page directive, and make sure you're taking care of the security risk of doing so.
Tuesday, October 9, 2007
Quote for the Week
One of the quotes from the book was immediately compelling to me, so much so that I cut it out and pasted it on my computer.
"The person who can most accurately describe reality without laying blame will emerge the leader."There was more description around this point, but the power of the statement hits home without it. In my consulting world, we have a sunset review once a project phase has been completed. There is value to be gained from an analysis of what we did right, but the time and passion is always spent dissecting what went wrong, and the close cousin, who is to blame. The ability to recognize our mistakes and to learn from them is critical in any effort to improve a process, but our need to place the blame undermines trust and infuses a group of people who once acted as a team with a sense of isolation and a motive for CYA.
One of the reasons this was poignant to me is that I'm coming off a rather painful project completion, and I was challenged by the statement and realized that I wasn't exhibiting this critical characteristic of leadership, and yet by my project role and my own self-assessment I am a leader. My takeaway: Everything can be improved, even me!
Wednesday, August 1, 2007
Clearing Items in Repeater (or other) Control in .Net 2.0
I have a search control that dumps the results in a repeater, and to clear the results between search, I use the following line in my search click event:
myRepeater.DataSource = null;
whoop there it is :)
Thursday, July 12, 2007
Date Validation in .Net 2.0
- AJAX MaskedEditExtender
- Range Validator
What does the MaskedEditExtender give you? Only numbers are allowed and the
_ _ / _ _ / _ _ _ _ appear magically when the text field obtains focus. Here's what it looks like in your aspx source view:
<cc1:MaskedEditExtender ID="MaskedEditExtender3" runat="server" TargetControlID="txtBrideBDay"
Mask="99/99/9999"
MessageValidatorTip="true"
OnFocusCssClass="MaskedEditFocus"
OnInvalidCssClass="MaskedEditError"
MaskType="Date"
InputDirection="LeftToRight"
AcceptNegative="Left"
DisplayMoney="None"
>
</cc1:MaskedEditExtender>
The key fields to look at here are the mask and the mask type. The date mask only allows for numbers and the /. If you haven't added the AJAX toolkit to your webprojects, go here http://www.asp.net.
Now for the second piece. When you want a date to fall in a certain range, for example, scheduling an appointment, obviously the date needs to be in the future. Add a RangeValidator to your text field, select a validation type of Date, and put in your minimum and maximum values. For my application, this is what my RangeValidator looks like:
<asp:RangeValidator ID="RangeValidator1" runat="server" ControlToValidate="txtWeddingDate" Display="None"
ErrorMessage="Wedding Date cannot be in the past." Type="Date" MaximumValue="1/1/2050" ValidationGroup="GroupContactInfo"></asp:RangeValidator>
You can see that I don't care very much about the maximum date, setting it waaaaay in the future, and I haven't set a MinimumValue at all. This will throw a runtime error as both values are required for a RangeValidator. I've done this because future is not a definite date, it's dynamic based on the date the user is filling in the form. So I have to add it dynamically, which I've chosen to do in code-behind the first time the page loads:
if (!IsPostBack)
{
RangeValidator1.MinimumValue = DateTime.Now.ToShortDateString();
}
You can also put the value in the aspx page (which won't require compiling to change) with MinimumValue="<% =DateTime.Now.ToShortDateString() %>".
As always with the special validators, a RequiredField validator is needed for the RangeValidator to kick in.
Onward validation soldiers!
Tuesday, June 26, 2007
Aspdotnetstorefront Menu
What we lose here is the dynamic control of the menus for our clients, meaning they have to touch an xml file in addition to setting up the categories, and i don't know many product managers who speak xml.
So what I found was a curious line of code in the templatebase.cs file in app_code. Look at the Page_Load function and the section commented "// Find Categories menu top" and the line which starts with a call to AddEntityMenuXsl. See the final parameter being passed into that method is string.Empty. Well, when i look at AddEntityMenuXsl, I see that we have a piece of code that allows us to add a ROOT level element if the parameter length is greater than 0. So I just made my method call look like this:
AddEntityMenuXsl(doc, "Category", AppLogic.CategoryEntityHelper.m_TblMgr, mNode, 0, "1");
and VOILA! I now have a dynamic menu with the categories across the top! With just a little itty bitty code change. Some days programming is berry berry good to me :)