March 2004 - Posts

Come Hear Me Talk About Accessible Web Applications
31 March 04 06:35 PM | Scott Mitchell

On Saturday April 24th, I'll be giving a talk at the Day of .NET conference here in San Diego (well, about 15 miles north of San Diego in Carlsbad, to be specific). I'm one of five speakers, the others are all quite accomplished and include:

  • Michele Leroux-Bustamante - Michele is a great speaker, having presented at ASP Connections, Dev Days, and other conferences and will, this year, be speaking at three sessions in TechEd here in San Diego this year! Go Michele! I also co-teach a Web Services Fundamentals class with Michele. Her Day of .NET talk is on WSE 2.0, looking at WS-Security and WS-Policy.
  • Bernard Wong will be looking at Visual Studio tools for Office.
  • Chris Rolon will look at Writing Secure Code in .NET (a great talk he gave at DevDays).
  • Author Bill Sheldon will look at the .NET Compact Framework and SQL Server CE.

The conference includes lunch and a lot of free give aways, such as a slew of books kindly donated by Sams Publishing, and some goodies from asp.net PRO magazine. The day-long conference costs $45 for members of the San Diego .NET User Group and $75 for non-members (if ordered before April 17; add $10 to the cost if ordered after April 17).

Hope to see you there!

Filed under:
Don't Make Me Use IE
31 March 04 02:13 PM | Scott Mitchell

I have been using the Mozilla browser and Mozilla Phoenix/FireBird/FireFox browsers for a while now (as far back as when Mozilla Phoenix 0.4), and have happily cast off Internet Explorer. Or so I thought. If you use Mozilla FireFox, take a moment to view my latest MSDN article as linked to by the ASP.NET Dev Center. Scroll down to a code section. You'll see that there's no whitespace in the code, just a blurb of text, like:

private void Page_Load(object sender, System.EventArgs e) { if (!Page.IsPostBack) BindData(); } private void BindData() { OleDbConnection myConnection = new OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + Server.MapPath("Northwind.mdb")); const string productSQL = "SELECT ProductName, UnitPrice FROM Products WHERE CategoryID = 1"; OleDbCommand myCommand = new OleDbCommand(productSQL, myConnection); myConnection.Open(); dgProducts.DataSource = myCommand.ExecuteReader(); dgProducts.DataBind(); myConnection.Close(); }

Which, while syntactically correct, is far from readable. If, however, you visit the same page with IE, the spacing is present. What gives? What was especially odd was that if I visited the same page through the MSDN library link FireFox displayed the spacing and line breaks in the code sections. (This anamoly is a fairly recent one; I'm certain I've used FireFox dozens of times before to read MSDN articles from the Dev Centers without such problems...)

A bit of digging revealed that the Dev Center articles link to an external CSS file that has the following rule:

PRE
{
  background:#EEEEEE;
  margin-top:1em; margin-bottom:1em; margin-left:0px;
  padding:5pt;
  white-space:normal;
word-wrap:break-word; }

The culprit is the italicized white-space attribute. And I blame IE. Why? Well, the W3C defines the whitespace attribute to have three legal values: normal, pre, and nowrap. For normal, the W3C has this to say (emphasis mine):

This value directs user agents to collapse sequences of whitespace, and break lines as necessary to fill line boxes.

So this is what Mozilla FireFox is doing! It's collapsing sequences of whitespace - tabs, spaces, and carriage returns. But why isn't IE 6 doing this? IE 6 does support the whitespace attribute, but has its own, bastardized version of it. The normal value for IE 6 does the following:

Lines of text break automatically. Content wraps to the next line if it exceeds the width of the object.

Whoops! They forgot the collapse sequences of whitespace part! So this is why IE 6 displays the code sections properly, while Mozilla does not - because Mozilla adheres to the standards and IE does not. Meh. Now, why does the Dev Center use this CSS? I'd wager it's so that very long code blocks to not cause the screen to scroll horizontally (note the word-wrap CSS attribute in the PRE tag definition), and that the designers did not test the layout thoroughly with non-Microsoft browsers.

For those who are wondering why the code sections appear fine in the MSDN library version of the article, it's because a different external CSS file is used, which defines the PRE tag like so:

PRE
{
 background:#EEEEEE;
 margin-top:1em; margin-bottom:1em; margin-left:0px;
 padding:5pt;
}

Namely, it omits the whitespace attribute.

I've emailed my MSDN editors about this snafu, and hopefully they can alert the appropriate MSDN folks so I don't have to switch to IE just to read MSDN articles... :-)

Filed under:
Mapping All File Extensions to ASP.NET
28 March 04 03:19 PM | Scott Mitchell

In my article URL Rewriting in ASP.NET I showed how to use URL rewriting to allow for rewriting from a “pseudo” URL, like /Products/Meat.aspx, to a real URL, like /ListProducts.aspx?CatID=1. (By “pseudo” I mean that on the Web server the file /Products/Meat.aspx doesn't exist. Rather, when the request comes in for that file and is handed to the ASP.NET engine, the ASP.NET engine examines user-defined rewrite rules to determine to (behind the scenes) rewrite the incoming requested URL to /ListProducts.aspx?CatID=1, which does exist and displays the meat-related products. The benefit to the user - they get to see/use a memorable URL, one devoid of messy querystring parameters.) Additionally, if a user visited the directory /Products/ (or /Products/default.aspx), the user would see a list of the product categories.

One of the subtleties of this approach is that while the file /Products/Meat.aspx did not really need to exist, the directory /Products/ needed to exist in order to serve requests to /Products/ (but not to /Products/default.aspx). Why? Because if a user entered into their browser www.yoursite.com/Products/, IIS would handle the request and not hand it off to the ASP.NET engine. IIS would say, “Hey that directory doesn't exist,” and return a 404 HTTP response. (The request to /Products/default.aspx would work because IIS would hand off the request to the ASP.NET engine since the request was clearly for an ASP.NET resource - default.aspx.) Therefore, to implement this end user-friendly URL scheme, you would need to create a /Products/ directory and a dummy default.aspx. That way, when a request came in to /Products/, IIS would say, “Yes, that directory exists. And yes, it has a default.aspx file, so let me hand off the request to the ASP.NET engine.”

In my article I discussed a workaround to needing to create these “dummy” directories was to map all incoming requests from IIS to the ASP.NET engine. This way, even a request for /Products/ will get routed to the ASP.NET engine without IIS checking to see if /Products/ exists and if there is a default.aspx file in that directory. Unfortunately, completely implementing this solution is not just as simple as flipping the switch on IIS to pass all incoming requests to the ASP.NET engine. In fact, there has been a good discussion on my previous blog entry announcing the URL rewriting article. Some of the problems noted is that the default page for a directory won't load. That is, a request to /Products/ won't bring up /Products/default.aspx. Also, requests to non-ASP.NET files - such as images, CSS classes, external JavaScript files, etc. - don't work.

The problem arises because all requests are being mapped to the ASP.NET engine. Requests to image files. Requests to CSS files. Requests to just the directory path /Products/ (not /Products/default.aspx). So, if you want to use this approach of mapping all files to the ASP.NET engine, you're going to have to make the ASP.NET engine a bit smarter (and tell it how to handle all of the potential file requests that might come in). This is most easily done by creating HTTP handlers for different types of content that might need to be served. For example, you could create an HTTP handler that would know how to serve content like images, CSS files, external JavaScript files, etc. Your “catch-all” handler would need to know that if a request came in that looked like /Products/, that it would have to append default.aspx to the request and retry.

To get a good understanding of how to accomplish this, check out the .Text source code. In the Configs/Multiple1_Web.config file you can see an example of mapping image/CSS files to a static HTTP handler:

<HttpHandler pattern = "(\.gif|\.js|\.jpg|\.zip|\.jpeg|\.jpe|\.css)$" type = "Dottext.Common.UrlManager.BlogStaticFileHandler, Dottext.Common" handlerType = "Direct" />

In Code/Dottext.Common/UrlManager/BlogStaticFileHandler.cs you can see how static content (images/CSS files/ZIP files) are served. In Code/Dottext.Common/UrlManager/PageHandlerFactory.cs you can see how directory requests - like /Products/ - are handled. There's even examples of URL rewriting at work in Code/Dottext.Common/UrlManager/UrlReWriteHandlerFactory.cs class.

The point is, if you map all requests to the ASP.NET engine, then you have to essentially replicate the work IIS does through custom HTTP handlers. Hope this helps some folks struggling through mapping all requests in IIS to the ASP.NET engine!

Filed under:
Some More Interesting (To Me) Comment Statistics
28 March 04 11:03 AM | Scott Mitchell

After posting yesterday's analysis of comments on my blog, I decided to run a few more statistics. My previous entry examined if there was a correlation between when a blog was posted (either day of the week or hour of the day) and how many comments it received. As the stats showed, there was virtually no correlation between what hour of the day the blog entry was posted and the number of comments, but there was a slight correlation between the day of the week the entry was posted - specifically, entries made on Monday, Tuesday, or Wednesday had a much higher probability of generating more comments than those posted on Thursday, Friday, Saturday, or Sunday. (Andy Smith mused that perhaps I had more interesting things to say on Monday as opposed to Friday; my assumption is that I am equally as likely to say interesting things on any given day of the week.)

Anywho, I decided to examine when, on average, my readers made their comments, both in terms of time of day and day of week. The results aren't too surprising. For the day of the week, people were more likely to post during the week, especially during the middle of the weed (Tuesday, Wednesday, or Thursday):

Day Total % of Total
Sunday 28 8.8%
Monday 36 11.4%
Tuesday 67 21.1%
Wednesday 64 20.2%
Thursday 62 19.6%
Friday 41 12.9%
Saturday 19 6.0%
Total 317 100.0%

As for the hour of the day, the most probable posting time was between 8:00 AM and 12:00 PM PST (GMT -8). This correlates to the working hours during most of the US, especially near the lunch hours in all four mainland US time zones. There was also an increase in posting later at night, 9:00 PM and 10:00 PM. I wonder if this was people posting at home, or people in Western Europe posting at their lunch break.

Hour Total % of Total
12:00 AM 9 2.8%
1:00 AM 10 3.2%
2:00 AM 6 1.9%
3:00 AM 8 2.5%
4:00 AM 2 0.6%
5:00 AM 13 4.1%
6:00 AM 9 2.8%
7:00 AM 11 3.5%
8:00 AM 18 5.7%
9:00 AM 19 6.0%
10:00 AM 19 6.0%
11:00 AM 21 6.6%
12:00 PM 23 7.3%
1:00 PM 17 5.4%
2:00 PM 12 3.8%
3:00 PM 13 4.1%
4:00 PM 20 6.3%
5:00 PM 12 3.8%
6:00 PM 7 2.2%
7:00 PM 16 5.0%
8:00 PM 8 2.5%
9:00 PM 17 5.4%
10:00 PM 17 5.4%
11:00 PM 10 3.2%
Total 317 100.0%

These stats - the distribution of when comments are made, and when comments are made relative to the date/time the blog entry was made - are not on my blog homepage, ScottOnWriting.NET. They are output cached for 15 minutes or so, but if you are interested you can always get a quick glance at when comments are made here on my blog.

The last statistic I was interested in computing was the delta between when a blog entry was made and when a comment was made. That is, does the average person who leaves a comment make the comment in an hour after the entry has been made? 12 hours? 24 hours? 48? I ran the following query to determine this average delta:

select avg(ParentDateAdded)
from
(select dateadded,
(select datediff(hh, c.dateadded, b.dateadded)
from blog_content c
where c.id = b.parentid) as ParentDateAdded
from blog_content b
where b.blogid=0 and b.posttype=3) as blah

The results? The average time between when a blog entry was made and when a comment was left was 253 hours, or ten and a half days. This number is skewed, though, by the fact that there are a handful of comments that are made to a blog entry several months after the entry was made. If we look at the median delta, it is a more reasonable 33 hours.

With all of this information at our disposal, it's not surprising that Monday, Tuesday, and Wednesday are the days of the week whose blog entries generate the most comments. After all, the average commenter leaves his or her comment a day and a half after the blog entry is made, and most people leave comments on Tuesday, Wednesday, or Thursday, so it follows, naturally, that the best time to make a blog entry would be on Monday, Tuesday, or Wednesday.

So, let me leave you with this observation. Assuming your blog's comments follow the same commenting distribution that mine does, if you enjoy comment discussions on your blog and have something interesting to blog about, make sure you save it til Monday, Tuesday, or Wednesday for maximum comments.

Analyzing Your .Text Blog
27 March 04 11:30 AM | Scott Mitchell

I'll be the first to admit it - I love statistics. I like seeing pretty graphs and numbers and sums and averages and calculations and standard deviations and variances and forecasts and trends. Anyway, one thing that annoys me with blogs is that it's impossible to know how many people read it. Yes, there are Web site logs, which say that I had X total Web page requests per day, and Y unique sessions per day, but these numbers, when it comes to blogs, are terribly misleading. The #1 requested page, for instance, is the syndication feed, /rss.aspx. One person, who leaves their aggregator running 24-7, might request this page 12, 24, or 48 times per day. Fine, you say, take the number of requests to the syndication feed and divide by, say, 15, to get a rough estimate on those who read the blog via aggregators. But even that number could be way off. For example, BlogLines might hit my syndication feed 48 times a day, but there could be dozens, hundreds, or even thousands of readers who read the blog from that single requestor.

So I've resigned myself to the fact that I won't ever be able to get a truly accurate guage on my blog readership, but what I can get a handle on is the comments. As the default .Text interface shows, my blog has had - as of the time of writing this - 91 entries and 311 comments. This morning my curiosity got the better of me and I wondered how those comments were distributed. That is, do blog entries that occur on Mondays generate more comments on average than those blog entires made on Friday? Also, when is the best time (relative to my time zone) to make a blog entry? Midnight? In the morning? Around lunchtime? In the afternoon? After dinner? Again, the “best time” I am interested in if posting at a certain time is more likely to generate more comments. (Another metric worth looking at is trackbacks (seeing if the date/time an entry is made increases/decreases the likelihood of folks using trackbacks), but I'll save that anaysis for another day.)

Here are the statistics for my blog, as of March 27, 2004:

Day of Week Avg. Comments Total Comments Blog Entries
Sunday 4.2 21 5
Monday 4.4 44 10
Tuesday 3.2 54 17
Wednesday 4.1 65 16
Thursday 3.7 77 21
Friday 2.3 37 16
Saturday 2.2 13 6
TOTAL: 3.4 311 91

Hour of Day Avg. Comments Total Comments Blog Entries
12:00 AM 7.5 15 2
8:00 AM 0 0.0 1
9:00 AM 7.3 44 6
10:00 AM 3.7 26 7
11:00 AM 2.2 28 13
12:00 PM 4.3 34 8
1:00 PM 3.2 25 8
2:00 PM 3.7 41 11
3:00 PM 2.5 10 4
4:00 PM 0.5 2 4
5:00 PM 1.7 5 3
6:00 PM 3.5 21 6
7:00 PM 0 0 3
8:00 PM 5.2 26 5
9:00 PM 5.5 22 4
10:00 PM 3.7 11 3
11:00 PM 0.3 1 3
TOTAL: 3.4 311 91

The black lines in the graphs are trendlines. As you can see, the later in the week a blog entry is made, the less likely it is to receive comments. However, the hour of the day the entry is posted makes little difference on the number of comments it attracts. Of course, the strongest correlation between a blog entry and the number of comments it receives is likely the quality of the blog entry, but, assuming a "comment-provoking" blog entry is as likely to be made on one day of the week versus any other, the data shows that it's best to make that blog entry earlier in the week than later.

Interested in running these statistical reports on your own .Text blog? If you have access to run queries on the SQL box your .Text blog uses, you can get these reports with just a single SQL statement. To get the comments by the day of week the blog entry was posted, use the following query:

SELECT DayOfWeek, 
       AVG(CONVERT(decimal(5,0),PostCount)) as AvgPosts, 
       SUM(PostCount) as TotalComments, 
       COUNT(*) as BlogEntries
FROM
  (SELECT DATEPART(dw, DateAdded) as DayOfWeek, 
          (SELECT COUNT(*) FROM blog_content bc2 
           WHERE bc2.posttype = 3 AND bc2.blogid = 0 AND
                 bc2.ParentID = bc.ID) as PostCount
   FROM blog_content bc
   WHERE posttype = 1 AND blogid = 0) as SOWBlog
GROUP BY DayOfWeek
WITH ROLLUP

To get the comments by hour the blog entry was posted use:

SELECT HourAdded, 
       AVG(CONVERT(decimal(5,0),PostCount)) as AvgPosts, 
       SUM(PostCount) as TotalComments, 
       COUNT(*) as BlogEntries
FROM
  (SELECT DATEPART(hh, DateAdded) as HourAdded, 
          (SELECT COUNT(*) FROM blog_content bc2 
           WHERE bc2.posttype = 3 AND bc2.blogid = 0 AND
                 bc2.ParentID = bc.ID) as PostCount
   FROM blog_content bc
   WHERE posttype = 1 AND blogid = 0) as SOWBlog
GROUP BY HourAdded
WITH ROLLUP

If enough people run (and publish) these queries, and the day of the week / hour of the day are standardized to some standard time zone, like GMT, we could determine, globally, when the best time to make a blog entry was for maximum commenting. :-) Another interesting statistic to help ascertain when folks were reading your blog would be to determine the average number of comments made per given day of the week / per given hour of the day. (Recall that the above statistics look at the comment count based on the day of the week / hour of the day the blog entry was made.)

Getting the Most Out of Visual Studio .NET
26 March 04 03:34 PM | Scott Mitchell

I have used Visual Studio .NET virtually every day for several years, but it still seems at times that I am haplessly bumbling around this intricate development environment. VS.NET is a beast, with so many options, customizations, and configurations that there's probably only a few dozen people on Earth who actually know all it has to offer.

Anywho, to help myself and others, I have written a short article on 4Guys titled Getting the Most Out of Visual Studio .NET. Right now it's painfully short, highlighting my ignorance of my everyday IDE of choice. There's some tips on setting the default page layout, switching the default design view, adding line numbers, creating custom Web Form Wizards, and knowing the keyboard shortcuts. What I am hoping is that those who read the article have a secret or two up their sleeves, and will drop me a line and share their bit of knowledge. I'll then tack on any submitted tips or tricks to the article...

So, if you have any advice in how to get the most out of VS.NET, either leave a comment here in the blog or submit your comments via the 4Guys feedback form.

REQUEST: Ideas for a Useful HTTP Handler Demo?
24 March 04 01:22 PM | Scott Mitchell

I'm starting work on an article on dynamically generating content using HTTP handlers. Naturally, I'll cover what HTTP handlers are and how they can be created, configured, and deployed. I'd like to wrap up the article with a look at some HTTP handler demos. The cannonical one is to create an HTTP handler to work with images somehow, such as watermarking the image, dynamically thumbnailing the image, or resizing the image on the fly. I plan on a quick demo of watermarking and protecting your images against bandwidth thiefs (namely, making sure that someone doesn't directly link to your images on your Web site from their site), but am interested if the handful of people who actually read my blog might have any ideas/suggestions on a second HTTP handler demo.

My current idea is kind of a contrived one, since it would not make sense to do this at runtime, but... it's an HTTP handler for compressing external JavaScript files. Namely, the HTTP handler is attached to files with the .js extension. Requests that come in for .js files, then, are compressed, removing superlfuous whitespace, comments, etc. (Thanks to regex guru Darren Neimke for some pointers on stripping whitespace effectively.)

If any of y'all have suggestions for other HTTP handler demos that might be more interesting / plausible in a real-world setting, I'd be interested to hear them...

Thanks.

Filed under:
User Controls Article Available
24 March 04 09:19 AM | Scott Mitchell

My most recent MSDN article - An Extensive Examination of User Controls - is now online at the ASP.NET Dev Center. This article takes a look at common User Control tasks, from creating and deploying User Controls, to creating User Controls with public properties, methods, and events. It looks at handling postbacks in User Controls, raising events from a User Control, and dynamically loading User Controls in an ASP.NET Web page.

There are a number of real-world scenarios where the ASP.NET page that contains the User Control must be alerted when some action happens in the User Control. For example, in a project I worked on a few months back there was a menu displayed in a User Control. All ASP.NET Web pages on the site displayed this menu, but some pages needed to know when the user opted to jump to another page. (Some pages would not let the user leave the page through the menu system until they had completed their task on said page.) In another project I consulted on, the developers had two User Controls on a page, each with DropDownLists. When a new selection was made in User Control 1, they wanted to update User Control 2's selections based on the DropDownList in User Control 1.

So, how does one accomplish such tasks with User Controls? There are a couple of ways. One method, as written about by Tim Stall, is to give the User Control a delegate and let the containing ASP.NET Web page assign one of its methods to the User Control's delegate. Then, the User Control can invoke the containing page's method. This could be used in the following manner: the User Control that contains the menu system has a delegate property that can be assigned a method from the containing page's code-behind class. When the user clicks on a LinkButton to go to another page, the LinkButton's Click event handler invokes the delegate. The containing ASP.NET page, then, can take whatever action is necessary: either displaying a warning to the user informing them that they cannot yet leave the page, or using a Response.Redirect() to whisk the user to their desired page. For more information on this technique read Tim's article Trigger Page Methods from a User Control.

For the scenario just described, I prefer the technique of giving the User Control an event. This event, then, is raised when the LinkButton is clicked, and the page can create an event handler for the User Control's event. This technique I discuss in An Extensive Examination of User Controls, and have used in many User Controls that I've created when the containing page might be interested in something that occurs within the User Control. What's especially nice about this technique is that it closely mimics the approach with working with the built-in server controls. Drag and drop onto the designer, and then create event handlers.

I'll leave you with this interesting factoid I learned about User Controls from a student in one of my ASP.NET classes (Bob Mohler). As you may or may not know, User Controls cannot be added to the Toolbox in Visual Studio .NET. Therefore, I reasoned, there is no drag and drop support for User Controls, so I've always manually added the needed <%@ Register %> directive by hand in the HTML portion, as well as the declarative syntax. What VS.NET does allow, though, is the ability to drag and drop a User Control from the Solution Explorer. It will then automatically add both the <%@ Register %> directive and declarative syntax. Cool, eh? Of course, if you need to programmatically access the User Control in the code-behind class, you'll still need to manually add the member variable, but at least this little tip cuts down on some of the steps. :-)

Filed under:
Question: Do you use AndAlso and OrElse?
23 March 04 02:24 PM | Scott Mitchell

By choice I program in C#, but this month I am working on a couple of consulting projects (hire me!) that use VB.NET. I find myself using the short-circuiting operators - AndAlso and OrElse - quite a bit. There are times when you'd need to use them if you wanted to do something like the following on one line of code:

If reader.Read() AndAlso reader(”FirstName”) = “Scott” then
...
End If

I don't find myself doing things like the above, but I still find myself using AndAlso and OrElse a lot. Simple things, like if I want to only proceed if two Boolean values are true, I'll do:

If bool1 AndAlso bool2 then ...

I'm curious if the everyday / regular VB.NET programmers find themselves using the short-circuiting operators or not. The only reason, I fathom, why you'd not want to use short-circuiting is if the evaluation you were performing had some side-effects, which is a bad programming practice. It's a real shame the VB.NET language designers buckled to the pressure of the VB community and didn't just made And and Or short-circuiting, as initially planned.

Filed under:
URL Rewriting in ASP.NET
18 March 04 09:36 AM | Scott Mitchell

My latest MSDN article has been published, URL Rewriting in ASP.NET. This article looks at how to use either HTTP handlers or HTTP modules to perform URL rewriting in the ASP.NET HTTP pipeline. URL rewriting is the act of taking an incoming URL and seemlessly changing it to a different one. For example, you might have a page that lists products from different categories using a URL like /ListProducts.aspx?CategoryID=XXX. However, you might want to provide a more user-friendly URL, like /Products/Meat.aspx, and /Products/Dairy.aspx. URL rewriting is intercepting a request to, say, /Products/Dairy.aspx, and mapping it to the actual page, /ListProducts.aspx?CategoryID=XXX. The benefit is that the user can enter a friendly, memorable URL, while you can still use the less-user-friendly URLs with complicated querystring values.

If you have done any significant examination of URL rewriting in ASP.NET you've likely noticed that URL rewriting isn't really that easy to implement. There are a number of “gotchas,” like URL rewriting evaporating when using postbacks; or URL rewriting not playing nicely with forms authentication. This article addresses many of these subtlties.

[UPDATE 2005-10-26: Fixed URL to article (was broken)]

Filed under:
There Will Be a Part 7 to the Extensive Examination of Data Structures Article Series
16 March 04 09:33 PM | Scott Mitchell

My Extensive Examination of Data Structures article series was originally slated for six installments, five of which have been published at this time. (The sixth part is on sets and efficiently maintaining disjoint sets; it's been written and is going through the editing process at MSDN.) Throughout the run of the article series I have received a lot of great questions and feedback from readers. A recurring request from readers was to have an installment on linked lists. While I did discuss linked lists briefly in Part 4, they do warrant an entire installment as opposed to just a few paragraphs. Fortunately, my MSDN editor (Duncan Mackenzie) has given me the go ahead for a seventh installment on linked lists!

I expect the article will go something like:

  1. Overview of linked lists.
    1. Historical Context
    2. Comparison to trees and graphs
  2. Flavors or linked lists
    1. Vanilla linked lists
    2. Linked lists with forward/previous references
    3. Circular linked lists
    4. Other linked list structures
  3. Real-world examples of linked lists

If you have any suggestions for additional content areas to be covered or expounded upon, I'm all ears.

Filed under:
Is ASP.NET Too Hard?
16 March 04 12:11 PM | Scott Mitchell

On a listserv I'm on some folks were discussing the adoption rate of ASP.NET compared to other server-side Web programming technologies. Someone mentioned that they had read that there were more new projects being started with classic ASP than with ASP.NET. Even though ASP.NET has been out for several years, more developers are still using classic ASP, and not just for maintaining old projects, but for starting new ones too! Why is this? I can only think of two reasons:

  • Said employee's company has not yet adopted .NET.
  • Said employee finds ASP.NET over his or her head.

Hardly a week goes by where I don't receive at least one email from a 4Guys reader or from a reader of one of my books that goes something like: “I am having trouble doing X in ASP.NET. This was so easy in classic ASP!!” This begs the question: is ASP.NET too hard?

Part of classic ASP's appeal was that non-programmers could quickly pick it up and start using it. The concepts behind ASP were simple enough - procedural programming in an English-like syntax (VBScript). Where things got more tricky - like needing to connect to a database, read a text file, use a regular expression, etc. - there was always a plethora of code samples available online, and since ASP pages were simple text files, one could just cut and paste the script into their page and give it a whirl.

ASP.NET is a different beast altogether. It's object-oriented. It's compiled. While it is possible to develop using Notepad, it's not easy. Trying out new source code is not as easy as cut and paste. Sure, Visual Studio .NET makes many facets of Web application development a breeze. Need to display data on a page? Simply drag a DataGrid onto the Designer, and then a connection object; set some properties through VS.NET's GUI, and you're done. Trouble is, if you want to deviate from the path the GUI tools provide, you have to write code. And ASP.NET code, to the non-programmer, may seem backwards and confusing. For example, consider the following: you are displaying monthly sales data in a Web page and want to make the background color of the month's data red if the sales goal for that month was not met. In classic ASP, you can see where your HTML <table> is built up, and non-programmers can intuitively reason the precise location where such a check must go. In ASP.NET, you need to know that the DataGrid has an ItemDataBound event that fires for each item added to the DataGrid. For someone whose background is not in computer science, the notion of creating an event handler may be foreign.

Now I'm not decrying ASP.NET in favor of classic ASP. The last classic ASP page I created was back in 2000, and I don't plan on ever doing classic ASP again. I love ASP.NET, but I have a computer science background. I've talked to folks who lack the background, or who work with people who lack the background, and they notice just how much trouble these people have transitioning from ASP to ASP.NET. Part of the power of ASP (and Visual Basic) was that it empowered non-programmers to create computer solutions, but .NET has raised the entry-level, for better or for worse.

So what does the future bode for these non-programmers? Do they migrate from programming to some other task? Keep doing classic ASP / Visual Basic? Start using .NET once the tools become so advanced that virtually no code has to be written by the so-called “developer?”

An Extensive Examination of Data Structures, Part 5 Available
12 March 04 11:44 AM | Scott Mitchell

Part 5 of my Data Structures article series is now available on MSDN. In the previous two installments (Part 3 and Part 4), I talked about trees, which are a collection of nodes that are arranged in a particular manner. Generalizing the rules of trees, we arrive at graphs, which are merely a set of nodes and connections amongst said nodes. Part 5 turns to an examination of graphs, including two ways to represent graphs with a data structure (adjacency lists vs. adjacency matrices), common uses of graphs, and famous graph algorithms. The article also provides a C# class for maintaining an graph using the adjacency list technique.

Note to Mike Singer - Dijkstra, Prim, and Kruskal get their due props here in Part 5.

Filed under:
RssFeed Version 1.5 Available
11 March 04 06:30 PM | Scott Mitchell

A new version of RssFeed is now available. (RssFeed is an open-source custom ASP.NET server control that displays an RSS syndication feed in an ASP.NET Web page.) The latest version, Version 1.5, had two features added:

  • Support for proxies - if your Web site uses a Web proxy to connect to the Internet, you can create a WebProxy class instance and assign it to RssFeed's Proxy property.
  • A Timeout property - when accessing RSS feeds from a remote URL, if the remote URL hangs or takes a long time to return its response, it can seriously impact the rendering time for the page using RssFeed. The Timeout property lets you specify how many milliseconds, at most, to wait, before giving up (and throwing an RssTimeoutException).

For more information on RssFeed, check out some of the live demos; questions, suggestions, bugs, and code enhancements should be discussed at the RssFeed GDN Workspace.

Filed under:
New Article: Building DataBound Templated Custom ASP.NET Server Controls
10 March 04 09:14 AM | Scott Mitchell

My latest MSDN article, Building DataBound Templated Custom ASP.NET Server Controls, has been added to the ASP.NET Dev Center. This article is a follow-up to a previous one of mine, Building Templated Custom ASP.NET Server Controls. In Building Templated Custom ASP.NET Server Controls I showed how to add templates to a non-databound control to provide page developers a means to finely tune the control's rendered HTML. In the current article, Building DataBound Templated Custom ASP.NET Server Controls, I show how to create a templated, databound control (the Repeater is a prime example of such a control). Specifically, the article looks at RssFeed, a custom ASP.NET control for displaying RSS feeds that provides template support.

Filed under:
More Posts Next page »

Archives

My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.