Index to this series of articles

To successfully let business logic drive the user interface, you need an extensive library of business rules. Here are the additional business rules available as attributes. In my “Peter’s Soapbox”, you will find attributes that I feel need to be provided to complete the library.

• DefaultValueAttribute – Supplies the initial value for the column when creating a new record. Generally this value is assigned to the user interface to establish a default. ASP.NET Dynamic Data supports it in the FieldValue property of FieldTemplateUserControl class. FieldValue is generally assigned to the data entry control when generating the HTML output. If in Insert mode, it uses the default. Otherwise it uses the value previously stored.
• DisplayFormatAttribute – Column values that need to be displayed as strings use the DisplayFormatAttribute to assist in converting from its native type to the string.
• DisplayColumnAttribute – Applied to the Entity class definition, it specifies which column to display in lists, such as those shown in filters or in foreign key links. For example, you may want to show the Last Name column in lists. By default, Dynamic Data uses the first column of type string that it finds. It also lets you change the default sorting, to specify a different column and sort order.
• EditableAttribute - Introduced in .net 4, it's a bit like a security oriented attribute. It tells the client application whether a column can be made editable or not. It also tells the client application whether insert mode allows an entry. Typically its used to define a read only column and perhaps to express that the user can still enter a value in insert mode.
  
• KeyAttribute – When your Entity class is not generated by Entity Framework or LINQ to SQL, use this attribute to identify columns that are primary keys. Primary keys have special behaviors in the user interface.

Peter’s Soapbox

Is that it? A handful of Validation attributes, 2 DataTypeAttributes, and the rest mentioned in the last few postings? I’ve already mentioned in those posts where I felt the attributes were lacking. Here’s some more.

Security roles attributes

Role-based security restrictions to tables and columns is industry standard stuff. Where’s the support?

My next release of Peter’s Data Entry Suite introduces the ColumnRestrictionAttribute and TableRestrictionAttribute. For example:

[DES.ColumnRestriction("Admin", DES.DenyAccess.None)]
[DES.ColumnRestriction("Sales", DES.DenyAccess.Insert | DES.DenyAccess.Edit)]
[DES.ColumnRestriction("Support", DES.DenyAccess.View)]
public object Photo { get; set; }

Dependency attributes

Often on field is required based on the state of another. For example, when the column “CustomerType” has a value of “Other”, the OtherDescription field should require a value. The user interface would enable and disable both the textbox and validator associated with the OtherDescription field based on the setting of the CustomerType DropDownList. It’s a pretty standard thing and not too difficult to create attributes to describe.

This is already supported in my Peter’s Data Entry Suite.

[DES.RequiredDependency(ColumnNames="PrinterType|FaxType",
    MultipleMode=PeterBlum.DES.MultipleRequiredControlsMode.AtLeastOne)]
public object OutputHeading {get; set; }

Column is sortable attribute

The column headers of the ListView and GridView can usually be clicked to sort them. Another user interface would be to offer a dropdownlist of sortable fields. These user interfaces should be driven by the business logic through a SortableColumnAttribute. It not only determines if sorting is active, but also specifies the Sort Expression to apply.

Again, already supported in my Peter’s Data Entry Suite.

[DES.SortableColumn(false)]
public object Notes { get; set; }

Using the CategoryAttribute

The System.ComponentModel.CategoryAttribute can be used in creative ways. Take a look at my earlier posting on the subject: The CategoryAttribute and Dynamic Data.

Text entry attributes

Often the only difference between string column values is the pattern and character set permitted. Both can be used by textboxes to enhance entry. In addition, they are used by validators. Here’s how.

• Pattern. Think of the “masked textbox” concept. Let’s suppose that you declare:

  [TextMask("999-999-9999")]
  public object SocialSecurityNumber { get; set; }

  
  

  The Text_Edit.ascx Field Template can use this to establish the MaskedEdit Extender control on it’s textbox. With a converter routine, it can also be converted into a regular expression that is applied to the RegularExpressionValidator in the Field Template. (Or the Field Template can create a MaskedEditValidator.)

  I think the TextMaskAttribute should be a subclass of DataTypeAttribute so there can be a standard Field Template called TextMask_Edit.ascx.

• Character set. Many strings don’t have a pattern, but have a limited character set. For example, a person’s first name may be limited to upper and lower case letters. Again the Field Template establishes the necessary javascript to apply the character set, and sets up the RegularExpressionValidator to limit to those characters.

  [CharacterSet(Digits=true, Othercharacters="-")]
  public object SocialSecurityNumber { get; set; }

   

Injection attack attributes

Business logic determines what’s legal within strings. Hackers employ SQL Injection and Cross Site Scripting attacks through your web form’s inputs. String type fields should determine what HTML patterns and SQL statements are allowed or rejected.

Field Templates should use these attributes to generate a CustomValidator control that invokes your Injection detection code (server side only). What? You don’t have one? There’s one in my Peter’s Data Entry Suite called Peter’s Input Security.

Once again: “Is that all?”

I highly doubt that’s all of the business rules for entity objects. Feel free to describe your own cases in the comments.

Index to this series of articles