F9 Group Marketing and Technology Blog

Cascading Style Sheets , or CSS, is a syntax used to describe the look and feel of the elements in a web page. CSS allows a web developer to separate the document content – the HTML, text, and images – from the presentation of that content. Such separation makes the markup in a page easier to read, understand, and update; it can result in reduced bandwidth as the style information can be specified in a separate file and cached by the browser; and makes site-wide changes easier to apply. For a great example of the flexibility and power of CSS, check out CSS Zen Garden . This website has a single page with fixed markup, but allows web developers from around the world to submit CSS rules to define alternate presentation information. Unfortunately, certain aspects of CSS’s syntax leave a bit to be desired. Many style sheets include repeated styling information because CSS does not allow the use of variables. Such repetition makes the resulting style sheet lengthier and harder to read; it results in more rules that need to be changed when the website is redesigned to use a new primary color. Specifying inherited CSS rules, such as indicating that a elements (i.e., hyperlinks) in h1 elements should not be underlined, requires creating a single selector name, like h1 a . Ideally, CSS would allow for nested rules, enabling you to define the a rules directly within the h1 rules. .LESS is a free, open-source port of Ruby’s LESS library

Whenever a browser makes an HTTP request to a web server, it sends along several HTTP headers . These HTTP Headers are used to provide the web server with information to assist with handling the request. For instance, if the browser supports compression it will send along an Accept-Encoding HTTP Header, which lets the web server know what compression algorithms the browser can work with. Any cookies previously set by the web server are sent from the browser back to the server via the Cookies HTTP Header. The browser also sends the User-Agent HTTP Header, which the web server can parse to determine the browser (IE, Firefox, Safari, etc.), the version number, the operating system, and other information. Similarly, the web server includes a number of HTTP Headers when it sends back the contents of the requested resource. These headers are used by the browser to determine how to render the content and for how long to cache the content.

The Microsoft Chart Controls provide ASP.NET developers with an API and a Web control for creating and displaying charts in a web page. Behind the scenes, the Microsoft Chart Controls take the data to be plotted and dynamically generates an image. This image can be generated using one of three techniques: the Chart Web control can generate the image and save it to the web server’s file system in a specified location; the Chart control can generate the image and store it in memory, session, or elsewhere, and have that image served by a built-in HTTP Handler, ChartHttpHandler ; or the Chart control can send back the binary contents of the chart image directly to the browser. The chart image can be rendered using one of four image types: PNG , JPG , BMP , or EMF . And when rendering a JPG you can specify its compression level. Regardless of the image file type and the technique used to generate the image, the Chart Web control renders an <img> element whose src attribute references the image (or the image-producing HTTP Handler or ASP.NET page). When a browser requests a web page with a Chart control on it, it receives this <img> element as part of the page’s rendered markup and then makes a request to the URL specified in the src attribute (just like it does for any other image on a web page). The chart image file the browser requests either already exists in which case its contents are returned, or the image is dynamically-generated. Either way, the end result is that the browser is sent back the chart as an image file, which is displays. This article explores the three different techniques the Microsoft Chart Controls has at its disposal for generating chart images. We’ll look at how to use each option, enumerate the pros and cons, and discuss when to consider using one option over another. Read on to learn more! Read More >

Virtually every ASP.NET developer has, at one point or another, created a page with a Button control that, when clicked, redirects the user to some other page, perhaps sending along a value entered by the user through the querystring. The typical pattern for implementing such behavior is to add a Button to the page and create a Click event handler that executes a Response.Redirect( url ) . If the redirect incorporates some input from the user, then this pattern is expanded to include the addition of a TextBox or some other control to the page and a Response.Redirect( url ) statement that includes this control’s value. While this approach certainly works, it’s not without a couple of flaws. Firstly, this approach involves a needless round-trip to the server: clicking the Button causes the browser to re-request the page and the response from the server is simply, “Please go to url .” Ideally, when the Button was clicked the browser would immediately request the final destination URL rather than have to do a postback to find out the final destination URL. Second, this approach can lead to a confusing user experience in scenarios where there are multiple TextBoxes on the page and multiple Buttons because there may not be the expected correspondence between hitting Enter in a TextBox and having the associated Button control “clicked.” Consider a website with a master page that has a TextBox and Button for searching the site.

Developers using Microsoft’s ASP.NET AJAX framework can efficiently and interactively retrieve data from the web server using the ASP.NET AJAX client API, a bit of JavaScript, and Web services that support script access. Last week’s article, Building Interactive User Interfaces with Microsoft ASP.NET AJAX: Retrieving Server-Side Data Using Web Services , looked at how to create such Web services and how to call them from an ASP.NET AJAX application. With a sprinkle of JavaScript, This functionality can be implemented to provide a user interface that periodically updates, presenting pertinent information to the user without the need for the user to refresh her browser. Consider the following scenario: you are building a website that serves as a front-end for a work item database. The database contains tasks assigned to an employee; throughout the course of the day new tasks may be assigned to an employee by other workers, by automated processes, or by other means. When an employee logs onto the site he sees a hyperlink that lists the number of open work items in the upper left corner of every page, and clicking that link takes him to a page that lists the open work items in his queue. After completing a work item he closes it, which removes it from his list of open work items. In a typical web application the number of open work items in the upper left corner would only be refreshed when the user performed a postback, manually refreshed the page, or visited a new page. Wouldn’t it be nice if that count of open work items would interactively update as new work items assigned to the user entered the queue? This article looks at how to build such an interactive user interface by using the ASP.NET AJAX framework, script-enabled Web services, and a few lines of JavaScript, building upon the techniques discussed in Retrieving Server-Side Data Using Web Services . A complete, working demo is available for download at the end of this article. Read on to learn more! Read More >

In a perfect world all web applications would be snappy and responsive, and there would be no such thing as lengthy postback waits. But in the real world there are plenty of scenarios that take seconds to complete. For example, when a user visits a travel booking site like Expedia and enters his origination and destination information, it’s not unusual for it to take several seconds before the search results appear

I started my career as a web developer with Microsoft’s Active Server Pages (ASP), the predecessor to ASP.NET. ASP was a very simple scripting engine and lacked the tools that ASP.NET developers today take for granted, most notably a debugger. Debugging an ASP script typically involved littering the code with Response.Write statements to output the values of variables at different points in time of the script’s life-cycle. Debugging an ASP.NET page is so much easier thanks to the Visual Studio debugger, which allows you to set breakpoints, step through executing code, use Watch windows to keep an eye on variable values as they change, and an Intermediate window to evaluate statements during debug time. While the Visual Studio debugger has greatly improved the debugging story, there are certain scenarios where a server-side debugger is of little or no help. In certain cases the problem is not in the server-side code but instead in what is being sent from the client to the server (or vice-a-versa).

AJAX applications offer a more interactive user experience by replacing traditional full page postbacks with leaner and more efficient partial page postbacks. These partial page postbacks are executed asynchronously using JavaScript code in the browser. When a web surfer clicks on a link or submits a form (via a full page postback) the browser automatically adds the page being left to the browser’s history