I infrequently find myself on Joel Spolsky's site as the result of a search for something or other. It's not really a blog but a collection of articles on many different (it/web/developer) topics. The stuff he writes is ALWAYS interesting.
With that in mind, I finally added his Article Archive to the list of sites I visit regularly, just to see what's there.
I don't know how I missed this article previously, given it's relevance to me and my work, but The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) is my 'read of the week'.
Sunday 16 May 2004
Saturday 15 May 2004
More on... Client-Side Validation in Downlevel Browsers
This article ASP.NET.4GuysFromRolla.com: Client-Side Validation in Downlevel Browsers summarises the issues with validation in 'downlevel' browsers [although calling them 'downlevel' is Microsoft techmarketing at it's best]. Why not call them 'more standards compliant than IE' browsers instead?
More and more clients will be using non-IE browsers (Safari, Firefox, Mozilla) and non-PC-devices in future, so it makes sense to try and provide the same user-experience (ie. faster, client-side validation).
Go to the article to finds links to standards-DOM-based validation controls; or the longhorn beta documentation, which contains simplified versions of the validator controls that ship with the .NET Framework. Unlike the validator controls in the SDK, which work only with Internet Explorer, these controls comply with the World Wide Web Consortium Document Object Model Level 1 specification (W3C DOM Level 1) and support a number of browsers such as Internet Explorer 5, Netscape Navigator 6, and Opera 5.
More and more clients will be using non-IE browsers (Safari, Firefox, Mozilla) and non-PC-devices in future, so it makes sense to try and provide the same user-experience (ie. faster, client-side validation).
Go to the article to finds links to standards-DOM-based validation controls; or the longhorn beta documentation, which contains simplified versions of the validator controls that ship with the .NET Framework. Unlike the validator controls in the SDK, which work only with Internet Explorer, these controls comply with the World Wide Web Consortium Document Object Model Level 1 specification (W3C DOM Level 1) and support a number of browsers such as Internet Explorer 5, Netscape Navigator 6, and Opera 5.
Thursday 13 May 2004
Automating Word with C#
The Microsoft Word MVP FAQ is a useful reference, however it's annoying that so much Office Automation code on the web is still in VB/VB.NET. It appears very few people are using C# for automation projects (so far).
Also, there is no more frustrating phrase in programming than finding this: Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article on MSDN in relation to a problem you are having, like automating OrgCharts in Excel. Argh!
Also, there is no more frustrating phrase in programming than finding this: Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article on MSDN in relation to a problem you are having, like automating OrgCharts in Excel. Argh!
Wednesday 12 May 2004
HttpHandlers and HttpModules
Both these articles are very useful if you want to understand the handler/module concepts, and get some sample code.
You'll want to know about this if you are doing URL-rewriting, sophistication accept-language-detection or other early-in-the-pipeline processing.
You'll want to know about this if you are doing URL-rewriting, sophistication accept-language-detection or other early-in-the-pipeline processing.
Monday 3 May 2004
Unicode to Html Entity and back again
WorldPay with C#/.NET [2] also discusses encoding "double byte" (unicode, really) values as Html Entities. The 'final' code is
But it's also fairly easy to get your 'original' string back... this code can go anywhere
as long as this method is available
UPDATE: list of HTML 4 entities which could be used to write a robust ResolveEntity() method using the 'pattern' abpve/
private string HtmlEntityEncode (string unicodeText) {
int unicodeVal;
string encoded="";
foreach (char c in unicodeText) {
unicodeVal = c;
if ((c >= 49) && (c <= 122)) {
// in 'ascii' range x30 to x7a which is 0-9A-Za-z plus some punctuation
encoded += c; // leave as-is
} else { // outside 'ascii' range - encode
encoded += string.Concat("",
unicodeVal.ToString(System.Globalization.NumberFormatInfo.InvariantInfo), ";");
}
}
return encoded;
}
But it's also fairly easy to get your 'original' string back... this code can go anywhere
System.Text.RegularExpressions.Regex entityResolver =
new System.Text.RegularExpressions.Regex (@"([&][#](?'unicode'\d+);)|([&](?'html'\w+);)");
string outputString = entityResolver.Replace(inputString,
new System.Text.RegularExpressions.MatchEvaluator (ResolveEntity) );
as long as this method is available
private string ResolveEntity (System.Text.RegularExpressions.Match matchToProcess) {
string x = "X"; // default 'char placeholder' if cannot be resolved
if (matchToProcess.Groups["unicode"].Success) {
x = Convert.ToChar(Convert.ToInt32(matchToProcess.Groups["unicode"].Value) ).ToString();
} else {
if (matchToProcess.Groups["html"].Success) {
switch (matchToProcess.Groups["html"].Value.ToLower()) {
// this could be expanded to as many as you like, or (maybe)
// System.Web.HttpUtility.HtmlDecode will work on
// the whole 'entity' string... ?
case "nbsp": x = " ";break;
case "copy": x = "(c)";break;
case "lt": x = "<";break;
case "gt":x = ">";break;
case "amp": x = "&";break;
}
}
}
return x;
}
UPDATE: list of HTML 4 entities which could be used to write a robust ResolveEntity() method using the 'pattern' abpve/
'Securing' data on client round-trips
When my website users go 'off-site' I want to set some information that I can check later, with some confidence that they have not altered it.
OK, I can put it in a Session variable, but I don't have Sessions enabled. What I want to do is encrypt a little chunk of data which can be added to the ViewState, hidden FORM field or Cookie (ie. it will be "client/transport implementation independent"), and check it again later on...
I think these two articles: String Encryption With Visual Basic .NET and Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication might be what I'm looking for... perhaps using Base64 if there's binary data being generated.
If I get it working I'll post it here (as always)
OK, I can put it in a Session variable, but I don't have Sessions enabled. What I want to do is encrypt a little chunk of data which can be added to the ViewState, hidden FORM field or Cookie (ie. it will be "client/transport implementation independent"), and check it again later on...
I think these two articles: String Encryption With Visual Basic .NET and Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication might be what I'm looking for... perhaps using Base64 if there's binary data being generated.
If I get it working I'll post it here (as always)
Subscribe to:
Posts (Atom)