Creating a Dynamic Data-Driven User Interface (Part 1)

Most data-driven web applications have a fixed data model and user interface. What I mean by "fixed" it that the data it needs to be captured is known in advance. Consequently, the database's tables are created before a single line of code is written and the application's user interfaces are dictated by this pre-determined data model. While most applications work with a fixed data model there are scenarios where the parts of the data model need to be defined by the end user. Such applications are more difficult to create because both the data model and user interface need to be flexible enough to allow the user to specify the information to be captured.

Imagine that you were creating a web application to be used by small law firms for managing their clientele. You would need a database table to capture information about each client. This table would have columns for each attribute of a client, such as: FirstName, LastName, Email, Address1, Address2, City, and so on. Regardless of what attributes you define for this table you can be certain that there will be a law firm that needs to store additional information not already captured. To allow for this level of flexibility you could enable each law firm to define additional client-related attributes specific to their law firm.

This article is the first in a four-part series of articles examine how to build a data model and user interface to allow for such dynamic, data-driven websites. In this installment we look at how to capture such dynamic, end user-defined information in the database. Read on to learn more!
Read More >

Creating a Databound Label Control

ASP.NET includes a number of data source and data Web controls that make it remarkably easy to work with data from a web page. For example, to display the results of a database query simply add and configure a SqlDataSource control and then bind that to a GridView, ListView, or some other data Web control. There's no need to write any source code; the data source controls allow declarative access to data. For more information on working with data in ASP.NET see my Accessing and Updating Data in ASP.NET article series and Working with Data tutorials.

The GridView and ListView controls are great for displaying a set of records, while the DetailsView and FormView controls are ideal for displaying information about a single record. There are times where we only need to display a single column from a single record. While you can certainly use the DetailsView or FormView controls for this, it would be easier to use a Label Web control. However, the Label control does not natively support data binding. As a result, to display a database needed in a Label Web control you need to write code (or put the Label in a FormView templates or a DetailsView TemplateField).

The good news is that the .NET Framework offers appropriate base classes that we can extend to build a databound Label Web control. This article shows how to create and use such a control. The control, which I named DataboundLabel, and its complete source code is available for download at the end of this article, along with a demo of the control in use. Read on to learn more!
Read More >

Displaying a Message in Response to Some Action and Then Hiding It on Subsequent Postbacks

ASP.NET web pages commonly display messages in response to user actions. For instance, a typical CRUD (Create, Read, Update, Delete) web page might display the message, "Record deleted" immediately after deleting a record and the message "Record updated" immediately after updating a record. Likewise, there would be messages displayed for inserting a new record and messages displayed in the event of an error. Such messages are typically displayed using a single Label Web control. This control may be located at the top of the page and have its Text property initially set to empty string. Then, when particular events transpire, the Label's Text property is updated accordingly.

The problem with this approach is that the Label's Text property value is remembered across postbacks. Consequently, if a user deletes a record the "Record deleted" message is displayed. If the user next sorts or pages the CRUD grid or perform some other action that results in a postback, the Label control continues to display the message "Record deleted," which is now outdated. What we want is to have the Label's Text property revert to an empty string on subsequent postbacks.

There are two simple and straightforward techniques at our disposal for implementing such functionality. This article examines these two approaches and includes a working demo available for download that highlights both approaches. Read on to learn more!
Read More >

Helping Visitors Search Your Site By Creating an OpenSearch Provider

One of the nicest features of modern browsers like Mozilla Firefox and Microsoft Internet Explorer is the search bar in the upper right corner. With this tool you can quickly search any number of websites without having to first visit their search page.

This functionality is most commonly used to search the Internet using search engines like Google or Live.com. I recently was reading Scott Hanselman's blog and found an interesting entry on how to let your visitors add your website to their search bar. In a nutshell, you need to provide information on how to search you site in an XML file according to the OpenSearch standard. Next, reference this file in the <head> element on each web page in your site via a <link> tag. When a user visits your site their browser detects this information and allows the user to add your site to their browsers search bar.

Using this technology you can create a custom search provider for your website that your visitors can add to their browser search bar. Once added, users can search your website directly from their browser search bar, just like they can search Google or other search engines from the same interface. This article shows how to create an XML file that conforms to the OpenSearch standard and how to link to it from pages in your website. Read on to learn more!
Read More >

Examining ASP.NET 2.0's Membership, Roles, and Profile - Part 12

Several of the earlier installments in this article series examined how to apply authorization rules in order to prohibit particular users, roles, or classes of users from accessing particular resources. For instance, Part 2 showed how to define URL-based authorization rules in web.config for roles. With just a bit of XML markup, it is possible to block particular users or roles from visiting certain web pages. Just installments also looked at using the LoginView control, which displays different markup based on whether the user is authenticated or not (and can also be used to display different markup based on the currently logged in user's role). There are also programmatic techniques you can use to determine the identity of the currently logged on user and what roles she belongs to.

The URL-based authorization, LoginView control, and programmatic techniques can be used in tandem to ensure that a user does not visit a page or perform some operation if she is not authorized. But what if you forget to implement one of these safeguards? For example, imagine that you have a web page that includes a button that, when clicked, perform some task that is only intended for administrators. You could put this button in a LoginView control or you could use programmatic techniques to ensure that only users in the appropriate role (say, Admin) saw the button. But what if sometime later you, or another developer, removed this check by accident? The net result would be that any user visiting the page could perform the administrator-only operation! Whoops!

To reduce the likelihood of such security mishaps, the .NET Framework includes capabilities for declaratively asserting permissions (via attributes) on methods and classes. In a nutshell, you can add such attributes to ASP.NET pages, their code-behind classes, and your business logic and data access layers. With these attributes in place, your visitors will be barred from performing unauthorized actions, regardless of whether there are any security holes in the user interface. Read on to learn more!
Read More >

Displaying Detail Records for User-Selected Master Records :: Saving the User's Search Preferences

Last week's article, Using a Dynamic IN Clause, showed how to display detail records for a set of user-selected master records. This entailed creating a User Defined Function (UDF) in the database that would translate a comma-delimited string into tabular data that could then be parsed by SQL's IN keyword. Following that, the user interface was created using a CheckBoxList to enumerate the master records and a GridView to display the details records for the checked master records. The demo available at the end of this article includes the exercise created in last week's article, which uses the Northwind database and the Categories and Products tables as the master and details records, respectively.

Most users who view a master/details report are interested in a particular subset of master records. Such users will quickly become frustrated when visiting the master/details report because each time they visit they have to tediously check each master record checkbox of interest before seeing the results. This frustration is heightened when there are many master records that need to be selected. The user experience can be greatly improved by allowing a user to save their default master record choices and then having the master/details report's master records pre-selected accordingly.

This article takes the master/detail report demo created in the Using a Dynamic IN Clause article and extends it so that the report's master records are pre-selected based on the user's preferences. Read on to learn more!
Read More >

Displaying Detail Records for User-Selected Master Records :: Using a Dynamic IN Clause

The master/detail report pattern is used to display information in two database tables that share a one-to-many relationship. Typically the user is shown a list of the master records and can pick one to view the corresponding detail records. Consider the Northwind database that models product information using two tables, Categories and Products, where each product is assigned to precisely one category. Categories represent the master records and products the detail records. In a master/detail report, the user would choose a category to see the products that belong to it.

Imagine, however, that instead of letting the user pick one category we needed to let them pick any number of categories and then show the products that belonged to any of those selected categories. SQL includes an IN keyword that can be used to return detail records within a set of master records. Unfortunately, there are challenges using the IN keyword with values supplied at runtime. The good news is that with a little bit of work, we can overcome these limitations.

This article is the first in a two-part series that looks at displaying detail records from a set of user-selected master records. This first part looks at extending the IN keyword functionality to allow for the parameters in the IN keyword to be supplied at runtime. The second part shows how to save what master records the user wants to search on by default and how to have these selections automatically applied when visiting the report page. Read on to learn more!
Read More >