This article is the third installment of a four-part series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the past two articles we created a sample web application that allows for numerous law firms to log in to the site and manage their clientele. The application's data model contains a Clients table that defines the fixed attributes for a client - ClientId, CustomerId, FirstName, LastName, and so on. All law firms have these fixed attributes available to them. Each law firm can also define dynamic attributes. For example, a law firm that specializes in personal injury might need to capture client information like type of injury, whether the injury occurred on a job site, and so forth. The custom client attributes for each law firm are stored in a database table named DynamicAttributesForClients.

Part 1 examined the scope of the project and created the data model, while Part 2 showed how to allow customers (law firms) to define their custom client attributes. In this installment we create the web pages for managing clients. This includes two pages: one page to create new clients and manage their fixed attributes, and a second page to manage their custom attributes. Read on to learn more!
Read More >

This article is the second installment of a four-part series that examines how to build a data-driven web applications that offers dynamic user interfaces. Over the course of this article series we will build a complete and functional web application with a dynamic, data-driven user interface. Specifically, the demo application is a fictional website used by numerous law firms to manage their clientele.

The application uses both a fixed and dynamic data model for law firms to manage their clients. The Clients table contains the fixed attributes for a client and is composed of columns like ClientId, CustomerId, FirstName, and LastName. All law firms have these fixed attributes available to them. The dynamic data model allows each law firm to define custom attributes for their clientele. For example, a law firm that specializes in personal injury might need to capture client information that is not needed for a law firm that specializes in family law. The custom client attributes for each law firm are stored in a database table named DynamicAttributesForClients.

Part 1 examined the scope of the project and created the data model. In this installment we create the web pages used by the law firms to define the custom client attributes. Read on to learn more!
Read More >

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 >

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 >

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 >

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 >

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 >