Archive for the ‘Controls’ Category
In the eXtension People application, you can specify what social networks you participate in, and you can choose to make this information public. By making the information public, the eXtension People application will provide a JSON feed containing your information.
Ying Zhou, a programmer with ISU Extension IT, recently wrote a widget that will read this JSON feed, and display it on your web pages. You can see this widget in action at my ISU Extension staff page or this test blog on Blogger. (I’d put it on my blog, but didn’t see a way to embed the widget in a WordPress.com hosted blog.)
Here is the basic code to use the widget:
<iframe src="http://www.extension.iastate.edu/Widgets/SocialNetworksemail@example.com&showContact=false" width="200px" height="180px" frameborder="0"></iframe>
The web page that drives this widget takes the following query string parameters in the URL:
- email: (Required – Text) Email address of the person to look up in eXtension’s system. This email address should match the address given in your eXtension profile.
(In the example: firstname.lastname@example.org)
- showContact: (Optional – true|false) When true, show contact information from eXtension’s system. When false, don’t show it. Default is True.
(In the example: showContact=false)
- showSocial: (Optional – true|false) When true, show the social network information from eXtension. When false, don’t show it. Default is True.
- cssFile: (Optional – Text) Includes the given CSS file in the widget. This way, different sites can give the Widget different looks based on the CSS given.
With these options, especially the cssFile, you can modify the look of the output from the widget. You may need to adjust the height and width of the widget to fit your pages.
Feel free to use this widget on your own web sites. Let me know if you need assistance in using it.
In .NET, it is really easy to check whether a user is entering a date into a form field, although it’s not necessarily obvious how to do so. What you need to do is include a CompareValidator in your web form. The code would look like this:
<asp:TextBox ID="txtBirthDate" runat="server"></asp:TextBox> <asp:CompareValidator ID="CompareValidator1" runat="server" ErrorMessage="CompareValidator" ControlToValidate="txtBirthDate" Operator="DataTypeCheck" Type="Date"></asp:CompareValidator>
The three important properties that you need to set in the CompareValidator are:
- ControlToValidate – This is the ID of the Textbox
- Operator – Default is “Equal”, need to change to DataTypeCheck
- Type – Default is String, set to Date
This will cause the validator to return the error message when an invalid date is entered. It will accept dates such as “4/18/2004″, “9/12/95″ and “02/29/2004″, however would cause the error message to be displayed on “14/14/2000″, “02/29/2005″, and “January 1, 2000″. I’d like to see it accept the last one, however, the date should be in the format mm/dd/yyyy, be sure to tell the users to enter this format.
Of course, to be semantically correct, you’d want to give your Textbox a label on the form, and the CompareValidator a more descriptive error message. Also, be sure to enable server side validation, see “Server-Side Validation“.
The last few evenings, I watched broadcasts from DotNetRocks and dnrTV. I started with three episodes featuring Miguel Castro where he talks about building web controls. In them, he builds a fully functioning e-mail feedback control that can be reused in multiple projects.
- Miguel Castro on Web Controls (DotNetRocks #133)
- Miguel Castro Builds a Web Control, part 1 (dnrTV #1)
- Miguel Castro Builds a Web Control, part 2 (dnrTV #2)
Wow, I wish I would have known this stuff when we started building sites in .NET a few years ago. I’ve always wanted to go in this directions, just have not had a clear picture of it, therefore could not express it in a way our developers understood. These broadcasts help me take a giant step forward.
For a long time, I’ve kept an item on our project list for ISUE Framework. This framework would be a library of reusable controls to share between all the projects we develop. It will take a while to build, and will likely be built by writing code for a given project, then deciding that with some tweaks, it can be customized to add customization for use in other projects.
This week, there has been talk that a few states are planning on working with SharePoint and/or MOSS, and we are looking at ways we might share resources. There are many possibilities for how we can work together. At the very least, I hope that we will share controls what we develop in-house so we all can benefit from them.
Last night I was watching a DotNetRocks TV broadcast by Peter Blum on Web Controls and Validation. During his presentation, Peter said something, in passing, that triggered a major “ah ha” moment. One where you dent your forehead with your palm.
He mentioned a property that was added to the Page object in .NET 2.0 called MaintainScrollPositionOnPostback. I stopped the video right then, pulled up my Visual Studio, and tried it out. It worked!
One of the problems we’ve had in our CMS system is that when you change certain publishing options, it triggers a PostBack of the page. Basically, the page gets posted to the server, then reloaded on the browser. When this happens, it takes you to the top of the page in the browser. The publishing options are at the bottom of the page, so the user needs to scroll back down to where they were. Not cool.
With this new feature in .NET 2.0, we can add one line of code with will make the PostBack return you to the previous location on the screen. The code is:
Page.MaintainScrollPositionOnPostBack = true;
Now I just need to figure out where is the best place to use this feature. Right now I’m thinking it should go in the UserControl that displays the publish options on the edit screen.
In yesterday’s post, “asp:label or asp:literal” I encouraged the use of <asp:literal> instead of <asp:label> because it outputs cleaner HTML. So when is it appropriate to use <asp:Label>?
When you use the “AssociatedControlID” attribute in <asp:Label>, it will output a <label> tag in HTML, rather than the <span> tag it normally outputs. This is useful when you are associating text to an input field of a form as shown in “Forms with CSS (1 of 3) – HTML Markup“. Consider the following two pieces of ASP.NET code:
<asp:Label AssociatedControlID="txtTest" runat="server">Test:</asp:Label> <asp:TextBox ID="txtTest" runat="server"></asp:TextBox>
<label for="<%= txtTest.ClientID %>">Test:</label> <asp:TextBox ID="txtTest" runat="server"></asp:TextBox>
Both output the exact same HTML code as shown here:
<label for="ctl00_MainContent_txtTest">Test:</label> <input name="ctl00$MainContent$txtTest" type="text" id="ctl00_MainContent_txtTest" />
While both pieces of sample code above output the same HTML, I haven’t decided which way I prefer. I’m thinking the one using the <asp:Label> tag might have more semantic meaning, which should make it easier to maintain in the long run.
One of the issues I hear raised with ASP.NET is that it doesn’t produce valid XHTML code. In some cases, it is true that it’s hard, if not impossible, to do so. In other cases, there are simple things we can do that greatly improve the quality of HTML code from our applications. One of the easiest things is to follow the advice of Phil Haack in “ASP.NET Tip – Use the Label Control Correctly” when he says “Never use the ASP.NET label control when a Literal would do.“
Consider the following lines of ASP.NET Code:
<p><asp:Label ID="lblTest" runat="server">This is a label</asp:Label></p> <p><asp:Literal ID="litTest" runat="server">This is a literal</asp:Literal></p>
This produces the HTML code:
<p><span id="ctl00_ContentPlaceHolder1_lblTest">This is a label</span></p> <p>This is a literal</p>
The <asp:Label> tag produced an extra <span> tag while the <asp:Literal> tag did not. This is the only real difference when the tags are used in this way. You can easily interact with either of these tags in the code behind file to assign additional, or completely different, text to the tags, so in that respect, they are completely interchangeable.
Whenever I modify an existing page that uses <asp:Label> tags, I evaluate whether to change them to <asp:Literal>. In most cases, it only takes a few minutes to make this change. When doing new pages, I always use choose <asp:Literal> over <asp:Label> whenever it will work. In doing so, the application outputs cleaner HTML.
[Updated (Dec 18, 2008): Added link to When to use asp:Label ]