Joshua Arnold

This is the third post in a series of entries that I am using to describe the architecture used in my most recent social networking project. While some of the architecture is omitted from these discussions, I would like to share some of the tricks that my team used to decrease development time and meet the rough and ambitious deadlines that were placed upon us. This entry will continue the discussion on web controls with an emphasis on distinguishing between server and user controls.

During the domain modeling phase of the application, we noticed that Comments were utilized by several different areas of the application:

The first piece of the application to utilize the control was the User profile. As mentioned in the previous post, we constructed useful server controls to facilitate a consistent layout throughout the application. Using one of these controls, the LayoutModule, we constructed what we referred to as a CommentContainer to display comments.

As we expanded the functionality of the control, we realized we needed/wanted two things:

1. AJAX comment posting, deleting
2. Pagination

In order to allow for this functionality, we needed to abstract out the functionality that was required using a variation of the Bridge pattern:

Note: The CommentProvider is an extension of a generic EntityProvider that is used to define the general functionality shared by all of the controls that utilize this pattern.

After the CommentContainer and CommentProvider were finalized, adding comment functionality for additional pages was a piece of cake and the code is very easy to maintain.

This is the second post in a series of entries that I am using to describe the architecture used in my most recent social networking project. While some of the architecture is omitted from these discussions, I would like to share some of the tricks that my team used to decrease development time and meet the rough and ambitious deadlines that were placed upon us. This entry will continue the discussion on role-based security but it will focus on creating role-based web controls.

First, I will discuss the design of the commonly used controls. The layout of the application consistently made use of a Cascading Style Sheet (CSS) class named “module”. This was essentially a tabbed container with varying content that was used consistently throughout our mockups. The other variation of this style was a similar construct without the tabs. This spawned two controls that became the basis of the site:

• LayoutModule
• TablessModule

These controls use a template container approach to ensure that the proper classes are used but allow for complete customization of the inner content. The following is an example using the TablessModule:

<rr:TablessModule ID="contactModule" runat="server">
	<HeaderTemplate>
		<h2>
			Company Information</h2>
		<hr />
	</HeaderTemplate>
	<ContentTemplate>
		<p>Content here</p>
	</ContentTemplate>
</rr:TablessModule>

After creating the skeleton structure of the majority of our pages, we began to observe a pattern: we were showing/hiding controls based on roles that the principal user belonged to. This then spawned a series of controls which utilized the notion of “AllowedRoles” and “DeniedRoles” which then controlled their visibility.

Consider the following helper method:

/// <summary>
/// Parses the specifed <see cref="System.String"/> values into a comma separated
/// list of values.
/// </summary>
/// <param name="values"></param>
/// <returns></returns>
public static string GetCommaSeparatedString(params string[] values)
{
	if (values == null || values.Length == 0)
	{
		return String.Empty;
	}

	StringBuilder retVal = new StringBuilder();
	int last = values.Length - 1;
	for (int i = 0; i < values.Length; ++i)
	{
		retVal.Append(values[i]);
		if (i != last)
		{
			retVal.Append(",");
		}
	}
	return retVal.ToString();
}

Given a TablessModule “userInfoModule”, consider the following example:

userInfoModule.AllowedRoles = SiteUtil.GetCommaSeparatedString(SiteRoles.User);
userInfoModule.DeniedRoles= SiteUtil.GetCommaSeparatedString(SiteRoles.Friend);

This is especially helpful for profile links that are useful for other users viewing your profile. We don’t want to display links like “Send a Message” when you’re looking at yourself. The example above grants Users in the Role ‘User’ to view the module and explicitly denies access to Users in the Role ‘Self’. A simple translation would be:

Given some TablessModule containing information for some User x, some User y may view that TablessModule if that User y is in the Role ‘User’ and that User y is not that User x.

Once again, this was another step towards readability and simplicity for business-rule implementation. Stating the allowed and denied roles in code is easily understandable, in my opinion. This concludes the role-based web control section of this discussion.

Next up: Reusable user controls