Blue Ink
Blue InkHomeBlue Ink SolutionsArticlesBlue Ink Net CommunityBlue Ink Demo ApplicationAbout Automated Architecture
My Profile
login/register
0

Blue Ink Best Practices: Displaying More Columns

Suppose you want to display additional columns in the results of a Blue Ink generated search page. If this were the Orders table of the Northwind database, and you wanted to display the Orders.ShippedDate field, you could simply set the IdentifyingField Blue Ink meta-data attribute. Using this approach you could also have Blue Ink display data from related database tables. For instance if you want to display the shipper of an order you could set the IdentifyingField attribute of the Orders.ShipVia foreign key.

When you use this approach you indirectly determine what is displayed in the Orders_Identify and Orders_ViewMultiple web user controls, which are used on multiple pages in the generated application. For instance Orders_Identify is used on the OrderDetails_ViewDetail.aspx page to show which order an order detail belongs to. Orders_ViewMultiple is used on the Customers_ViewDetail.aspx page to display a customer’s orders.

But suppose you only want the fields to display on the ViewMultiple web user controls and not the Identify controls? Or perhaps you want to display something more complicated, like the number of products in the order? Or perhaps you want to display something many tables away that requires multiple joins? Solving these problems within Blue Ink generated code requires an understanding of the generated architecture and how to customize it, but is still considerably less work than writing the functionality from scratch. This article will show you how, and additionally provide the best practices along the way.

As this is a moderately technical article, you may want to review the Application Architecture and Code Samples pages before continuing.

Adding Custom Columns

There are different approaches you can take, but generally there are three tasks you need to consider: retrieving, storing, and displaying the additional columns. In approaching each task you will want to keep in mind that the ViewMultiple web user control may be used on different pages, and the data may come from different stored procedures. Therefore displaying additional columns on one page may mean that other pages may break. You may choose to simply customize a single page (it may be easier), but this article will outline how to update the web user control to display additional columns on all pages it is used for.

Updating Blue Ink’s Stored Procedures

With regards to retrieving data, all related stored procedures will need to be updated to return the additional columns. If Orders_ViewMultiple.ascx is the control you are adding columns to (from Northwind), then you will need to update the bisp_Orders_Search as well as the bisp_Orders_SelectByCustomerId and bisp_Orders_SelectByEmployeeId stored procedures. The Search stored procedure is obviously used to display Orders on the Orders_Search.aspx page. The bisp_SelectByCustomerId and bisp_SelectByEmployeeId stored procedures are used when displaying orders on the Customers_ViewDetail.aspx and Employee_ViewDetail.aspx pages respectively (e.g. orders a particular customer has placed).

There are a set of best practices for updating stored procedures. First of all, never update generated stored procedures directly as they are all deleted and recreated upon regeneration. Instead, create a new stored procedure and update the data access tier to use the new stored procedure. All Blue Ink generated stored procedures are named bisp_. A good approach is to name all custom stored procedures usp_ (note that naming them sp_ degrades performance as SQL Server will look in the system database first). Once you have created a new stored procedure that returns all the old columns plus a few new ones, you need to update the data access tier. The code looks like:

public class Orders_Dao : Orders_Dao_Base { 
    public Orders_Dao() {
      this.mstrSproc_Search = "usp_Orders_Search";
      this.mstrSproc_SelectByCustomerID = "usp_Orders_SelectByCustomerId";
      this.mstrSproc_SelectByEmployeeID = "usp_Orders_SelectByEmployeeId";
    }
}

This basically says that when Orders_Dao is instantiated by the business tier, use the three custom stored procedures instead of the defaults.

Storing Data

As far as storing retrieved data, this may be extremely simple, or you can make it cleaner and slightly more complicated. If you look into the generated code for the data access objects you will always see the following line in methods that fill up DataSets:

da.MissingSchemaAction = MissingSchemaAction.Ignore;

This basically means that any data that is returned from the stored procedures will be added into the underlying DataSet, even if it was not defined by the strongly typed dataset. This means that by default you need to do absolutely nothing if you want the dataset to hold additional information. You will, however loose the benefit of early binding and thus may need to refer the column by:

dsDataSet.Tables[0]["Column"];

This is probably a reasonable tradeoff for convenience.

If you would like to update the typed dataset and regain the benefits of early binding, this is fairly easy. Blue Ink creates a base and an inherited version of every typed dataset. To add columns to a typed dataset you can simply have the inherited class inherit from a new dataset you will create instead of the Blue Ink generated one. A best practice is to put the dataset in a folder called CustomEntities under the Common project and name the dataset [RelevantTableName]_[Action]_[DataSet].xsd.

Displaying Data

Displaying the new columns in the ViewMultiple control requires adding a new line to the .ascx page and possibly overriding the Page_Load_Base method to update the order the columns are displayed in. The line you add to the .ascx control is fairly standard and may look like:

<asp:BoundColumn DataField="NewColumn" DataFormatString="{0:d}" HeaderText="New Date Column" />

DataFormatString in this case simply says to display the column as a date (drop any time element).

If you add the column anywhere but the end, you will change the order of the columns and there is one additional step you will need to take. The ViewMultiple_Base.cs page, where all the functionality happens, will sometimes need to set the visibility of some columns to false. This primarily happens for ViewDetail pages who are displaying associative tables. For instance in Northwind, the OrderDetails_ViewMultiple.ascx control shows product as well as order information. When used from the Orders_ViewDetail page, you don’t want to see order information since you already know it. Column visibility is set by column number, and if column numbers are off between the .ascx and the code behind page, then the following technique must be used to hand set the column order:

protected override void Page_Load_Base(object sender, EventArgs e) {
    mintFK_Orders_Customers_CompanyName = 0;
    mintFK_Orders_Customers_CustomerID = 1;
    mintFK_Orders_Employees_LastName = 2;

    base.Page_Load_Base(sender, e);
}

Setting the columns to the order they appear in will solve all issues of inappropriately disappearing columns.

Conclusion

Understanding the techniques described in this article will provide a great deal of flexibility to your Blue Ink solutions. At first there may appear to be many steps involved, but you will likely find that even with the learning curve, it is far less effort than writing the pages from scratch.





FAQ's:

What types of database relationships does Blue Ink support?

Does Blue Ink support Object Oriented Design?


Related Links:

Application Architecture

Code Samples

Blue Ink Technical Details


ARTICLES

What is Rapid Application Development?


QUESTIONS?

Call us toll free:
(877) 756-3595

Or Visit Forums

    

Copyright © 2017 Automated Architecture, Inc. All rights reserved.