Blog: Posts from February, 2012

Code On Time supports automated translation of web application resources from English to other languages with the help of Google Translate API.

You can create a multi-lingual web application by specifying a collection of additional culture sets required for your application.

Start the application generator, select the project name, and choose Settings project action.

Click on Globalization and Localization option.

Select the default culture set for your application using the drop downs and list any additional cultures in Supported Culture Sets text box.

Enter the Google Translate API Key in the input field. Note that the key in the picture is not real.

The support culture sets can optionally start with the default culture selected in the drop downs. The culture set specifies the culture used for internal calculations and the culture of the user interface. Both cultures in a culture set are separated by a comma.

Multiple culture sets can be listed one per line or separated with the semicolon.

This culture set will enable English (US) and Spanish (Mexico).

en-US,en-US; es-MX,es-MX;

The generated web application will offer a language selector on the membership bar.

The screen shot below shows the page presented in Spanish with translated system resources.

Various column labels and page titles are not translated.

Supposes you want to translate the title of the page Customers.

Start the application generator and select the project name, click Design.

Select Customers page in Project Explorer and change Title, Path, Description, and About This Page properties as follows.

Title:
^Customers^Customers^Customers^
Path:
^Customers^Customers^Customers^
Description:
^ViewCust^View Customers^ViewCust^
About This Page:
^CustDesc^This page allows management of customers.^CustDesc^

Localization tokens are “wrapping” the actual text written in English.

Save the changes, exit the Designer and re-generate the application.

Select Spanish as the application language.

The translations of resources wrapped in localization tokens will show up in the user interface.

Business requirements can change hourly in the world of broadband connections and instant messages . Your application will have to be changed no matter how good you are at putting together a detailed requirements specification for the project. Some obscure security rules will be missed, new clients will require special handling – you know the story.

It is virtually impossible to create an application that will adapt to changing security and data segregation requirements unless you are building your web applications with Code On Time.

The unique architecture of generated web applications allows dynamic engagement of access control rules without changing a single line in the source code of your project.

Consider the following screen shot of the Northwind sample with a seemingly random list of ten customer accounts.

The actual web application source code defines a business rules class with an override of EnumerateDynamicAccessControlRules method. This method registers a few access control rules whenever the customer accounts are retrieved from the application database.

Here is the code.

C#:

using System;
using System.Data;
using System.Collections.Generic;
using System.Linq;
using MyCompany.Data;

namespace MyCompany.Rules
{
    public partial class CustomersBusinessRules : MyCompany.Data.BusinessRules
    {

        protected override void EnumerateDynamicAccessControlRules(string controllerName)
        {
            RegisterAccessControlRule(
                "CustomerID", AccessPermission.Allow, "ANTON", "ANATR");

            RegisterAccessControlRule(
                "CustomerID",
                "[Country]=@Country and [ContactTitle] = @ContactTitle",
                AccessPermission.Allow,
                new SqlParam("@Country", "USA"),
                new SqlParam("@ContactTitle", "Owner"));

            RegisterAccessControlRule(
                "CustomerID",
                "select CustomerID from Customers " +
                "where Country=@Country2 and City=@City",
                AccessPermission.Allow,
                new SqlParam("@Country2", "UK"),
                new SqlParam("@City", "London"));
        }

    }
}

Visual Basic:

Imports MyCompany.Data
Imports System
Imports System.Collections.Generic
Imports System.Data
Imports System.Linq
Imports System.Xml
Imports System.Xml.XPath

Namespace MyCompany.Rules

    Partial Public Class CustomersBusinessRules
        Inherits MyCompany.Data.BusinessRules

        Protected Overrides Sub EnumerateDynamicAccessControlRules(controllerName As String)
            RegisterAccessControlRule(
                "CustomerID", AccessPermission.Allow, "ANTON", "ANATR")

            RegisterAccessControlRule(
                "CustomerID",
                "[Country]=@Country and [ContactTitle] = @ContactTitle",
                AccessPermission.Allow,
                New SqlParam("@Country", "USA"),
                New SqlParam("@ContactTitle", "Owner"))

            RegisterAccessControlRule(
                "CustomerID",
                "select CustomerID from Customers " +
                "where Country=@Country2 and City=@City",
                AccessPermission.Allow,
                New SqlParam("@Country2", "UK"),
                New SqlParam("@City", "London"))
        End Sub

    End Class
End Namespace

Let’s review the effect of each individual rule on our data set.

The first call of RegisterAccessControlRule method limits a list of customers to those with the specific customer IDs of ANTON and ANATR.

The second call limits a list of customers to those from the USA and having the title of Owner.

The third call limits a list of customers to those from the United Kingdom and located in the city of London.

The three calls are showcasing various methods of creating a dynamic restriction.

The final result is a cumulative set of 10 records since the rules do not contradict each other.

The access control rules used in the example are registered unconditionally  and hard-coded in the application business logic.

What if you take this rules and store them in the database? The rules can be loaded on-demand based on the user identity and injected in the application without changing anything at all. Better yet, you can enable shared business rules in your project and have only one implementation of EnumerateDynamicAccessControlRules method.

We leave the actual implementation up to you.

If a custom implementation of dynamic access control rules is too much for you or is simply not required then continue using the static access control rules.