Dynamic Language Runtime in Pivotal Client

One of the new additions to the .NET Framework 4.0 is Dynamic Language Runtime.  From the MSDN documentation:

The dynamic language runtime (DLR) is a runtime environment that adds a set of services for dynamic languages to the common language runtime (CLR). The DLR makes it easier to develop dynamic languages to run on the .NET Framework and to add dynamic features to statically typed languages.

Advantages of dynamic languages:

  • The ability to use a rapid feedback loop. This lets you enter several statements and immediately execute them to see the results.
  • Support for both top-down development and more traditional bottom-up development.
  • Easier refactoring and code modifications, because you do not have to change static type declarations throughout the code.

The purpose of the DLR is to enable a system of dynamic languages to run on the .NET Framework and give them .NET interoperability.

Like the CLR, the DLR is a part of the .NET Framework and is provided with the .NET Framework and Visual Studio installation packages. The open-source version of the DLR is also available for download on the CodePlex Web site.

The DLR provides the following advantages.

  • Simplifies Porting Dynamic Languages to the .NET Framework
  • Enables Dynamic Features in Statically Typed Languages
  • Provides Future Benefits of the DLR and .NET Framework
  • Enables Sharing of Libraries and Objects
  • Provides Fast Dynamic Dispatch and Invocation

DLR architecture.

DLR architecture

IronPython and IronRuby are implementation of Python and Ruby using DLR on .NET runtime.

IronPython Hosting in Pivotal Client

To host IronPython we need to reference following dlls available for download from IronPython CodePlex site http://ironpython.codeplex.com/

  • IronPython.dll
  • IronPython.Modules.dll
  • Microsoft.Scripting.dll
  • Microsoft.Scripting.Core.dll
  • Microsoft.Scripting.ExtensionAttribute.dll

To run IronPython code, create Python script engine, ScriptScope, ScriptSource objects and execute the ScriptSource using Execute method as shown below.

ScriptScope scope = engine.CreateScope();

ScriptSource source = engine.CreateScriptSourceFromString(this.CodeEditor.Text, SourceCodeKind.Statements);

scope = engine.CreateScope();


In IronPython to access classes from the .NET framework, your application must have a reference to the assemblies you want to use.

import clr


Having added the reference, you can import from the namespace inside the assembly. Usually this will have the same name as the assembly.

from System.Windows.Forms import *

Similarly to reference any custom classes, add reference and import types from it. For example, here I am adding reference of Pivotal.Engine.Client.Services.Interfaces assembly and importing a number of classes, interfaces and enumerations. ActionContent, ActionCommand and ActionTargetWindow are enumerations, ClientContext is a static class and rest are interfaces.


from CdcSoftware.Pivotal.Engine.Client.Services.Interfaces import ( ActionContent , ActionTargetWindow ,

ClientContext , IActionService, ActionCommand, IFormActionTarget, IDataAccessService, ISearchActionTarget )

Design Patterns in Pivotal Client – Form Client Task

In Pivotal Client, Forms provides the most customization. This post describes the design patterns used by Pivotal Client to provide Forms customization.

Form Client Tasks differ from Client Task Commands and Notification Handlers as Form Client Tasks are classes whereas other two client tasks are methods with attributes.

To expose form client task Strategy pattern is used. Any implementation of IFormClientTask interface can be associated as Form Client Tasks to a Client Form. A Strategy pattern has four participants, Strategy, Context and ConcreteStrategy. In Pivotal Client, FormWorkItem is Context, IFormClientTask interface is the strategy and any implementation like FormClientTaskBase is the concrete strategy.

FormClientTaskBase is the default implementation of IFormClientTask interface that comes with Pivotal Client. This implementation provides back-compatibility for migrated Rich Client Forms by first calling client script, if available. FormClientTaskBase uses another behavioral pattern, Template Method to provide extensibility. The FormClientTaskBase has all the methods as virtual, thus any subclass can override the behavior. Please note that FormClientTaskBase is one implementation provided by Pivotal Client and Customizers are free to use any other behavioral pattern like Chain of Responsibility, State pattern to implement Form Client Tasks. One alternative approach to implementat Form Client Task is to use State pattern to separate new and existing record business logic.