Category Archives: 2012 R1

ClientUI Preview Part 3: Pageable and Multi-column ComboBox, Enhanced GridView, Items Grouping and more

In the last two posts, I’ve covered many of the new framework features that provide architectural guidelines for building highly extensible and maintainable business applications on Silverlight and WPF. You can check out the first post here which explains dependency injection and IoC containers, and the second post here which unveils the new ClientUI region manager library to implement view extensibility.

Recently, we’ve been working with a number of large clients in migrating their apps to the Silverlight platform. As I’ve mentioned in my previous posts, we can see the increasing demand of Silverlight in enterprises as it provides a true rapid solution for building visually engaging and highly scalable business apps. Check out our recently published Silverlight case study here.

That said, we’re focusing on creating tools that enable companies to succeed in achieving their business objectives with rock-solid and mature solutions today – one that enables them to complete their IT projects on time and on budget. And we’re incredibly pleased to be the part of the succession through the increasing adoption of our toolset in enterprises.

In this post, I’ll share some of the upcoming new exciting tools that were thoughtfully designed to address many challenges that you often find while building business apps.

The very best of ASP.NET WebCombo, now on Silverlight and WPF

Flashing back to a decade ago, Intersoft was founded with only a handful of products, one of them is the WebCombo control for ASP.NET. At that time, web pages are slow and unresponsive due to large view state and postback. There were no AJAX yet – so we invented the very first AJAX-enabled ComboBox with highly efficient data retrieval and blazing fast response which makes it the most popular ComboBox in the industry – till today. Of course, it has evolved over the years and you can try it online here.

Today, I’m very excited to announce that the highly-efficient and advanced WebCombo-like control is now available on the developers’ most loved platform: Silverlight. Meet the brand-new UXPageableComboBox.

The pageable ComboBox includes all the features available in the classic ASP.NET WebCombo, while sports a much appealing user interface, thanks to the rich graphics in Silverlight. Let’s start with the first sneak preview below.

Introducing UXPageableComboBox for Silverlight and WPF

Say welcome back to multiple columns, a favorite feature many of us have missed for a while… And we’ve got a bonus feature for you as well, sortable columns. Note that the multiple columns is a built-in feature now, and is not a workaround that requires heavy re-templating.

UXPageableComboBox with Multiple Sortable Columns

And not to forget the image and templated columns as well.

UXPageableComboBox Built-in Column Type

The pageable ComboBox includes a more sophisticated user experiences than the ASP.NET version of WebCombo in the way users make selection and navigate the items. For example, by default only the matched item is displayed when the selected item is set initially. A ‘Browse All’ button will appear providing a visual hint to users indicating they can choose other items by clicking that button, or  by simply clearing the text.

UXPageableComboBox combines highly-efficient data paging and intuitive user experiences

Another nice feature that we manage to put in this release is the watermark description in the text box. This is one of the most requested features in business apps  particularly for the code-value pair input scenario. Think of chart-of-account code input where accountant can input the account code, but still wish to be able to see the account name at the same time. This is now possible in the new Pageable ComboBox, and the best of all – it’s a built-in feature so you don’t have to make any customizations.

Unique description watermark feature for code-description input

New Powerful LoB-centric Features

The upcoming new version is strongly focused on new features that were driven by real-world business scenarios and usage. One of the data components that receives major new features is UXGridView. It introduces advanced features such as columns collection binding,  column header binding, and batch items validation.

In addition, we’ve also added a new rendering mode in UXGridView that allows the empty space to be filled with virtual rows. This new mode is particularly ideal when the Grid is used to display line details such as transactions. If you’ve used apps such as Quick Book, or any Mac apps, you should be already familiar with this feature.

Virtual rows rendering in UXGridView

As seen in the above illustration, the grid fills the remaining empty space with virtual rows instead of a blank white space. The virtual rows will grow or shrink automatically as the viewport is resized, and better yet, it works perfectly with row virtualization so you don’t have to sacrifice the rendering performance.

And with the empty space virtual rows, we took the grid further by introducing natural inline editing experiences when adding a new item. This feature activates a new row after the last item of the grid for rapid data addition. Users can simply click on the any remaining space, input the data and cycle through the last cell, and then tab out to the next new row and so forth. Activate this feature in your apps with a simple property set, guaranteed your users will thank you a million!

New row position at last item for rapid items addition

Furthermore, the items control architecture has been revamped to introduce new capability such as grouping and style-able group container. This means that most of the common controls that derives from items controls such as combo box and list box now supports grouping out-of-the-box!

Imagine the possibilities that you can do with the grouping capability: displaying contact list grouped by type in a list box, or displaying expandable/collapsible groups within the resultbox of a combo box. Thankfully, you can now achieve all those possibilities without any major efforts.

Grouping in items control made easy

Download the Developer Preview Bits

I hope you enjoy reading my blog post through the detailed feature coverage. And to complete your pleasure, we’ve made the ClientUI Developer Preview available along with the technical samples. Download the developer preview bits today. Explore the technical samples that demonstrate the new controls and features explained above, and test drive it in your apps within minutes.

And by the way, I’ve just received fresh builds from our development labs as I wrapped up this post. I can tell that there are many more new exciting stuff coming down the pipeline, so watch out this spot closely.

Best,
Jimmy Petrus
Chief Software Architect

ClientUI 7 Preview Part 2: View Discovery and View Injection with Region Manager

In my previous post, I’ve discussed about dependency injection and IoC container, and how the upcoming ClientUI release makes it easy for developers to build good quality software. Today I’ll continue to explore the new exciting framework-related features so you can preview these features and try them in your apps.

In this blog post, I’ll particularly focus on the challenges in view extensibility, and discuss the architectural patterns that can be applied to address these challenges.

Understanding View Extensibility

First, let’s get on the same page for the view extensibility definition. Assume that you have an application that shows a list of quick tasks such as illustrated below.

Navigation list

Initially, your application might contain only a few modules such as Customers, Products, and Reports – then define them in the navigation list such as shown above. As you added more modules, you’d have to revisit and modify the navigation list, add the new links and so forth. There are no extensibility points.

In the above case, the ability to add the navigation links when new modules become available without modifying the original codebase is the essence of view extensibility. As you’re becoming more familiar with extensible application development, you’ll realize the real benefits in the way it accelerates your development and minimizes code changes. Not only will your application become easier to maintain and extend, you’ll find yourself building software more fun and enjoyable.

There are two well-known patterns to achieve view extensibility called View Injection and View Discovery.

View injection is a pattern that dynamically inject an element to the target at runtime. The view injection is usually done manually by the controller at a certain event, such as page load. In contrast to view injection, the view discovery pattern performs the injection automatically when the element becomes available in the application life cycle. View discovery is usually implemented with metadata (also known as attribute in .NET) to allow the view to be discovered at runtime. More details on the patterns implementation are discussed in the section below.

Both patterns are commonly implemented with so called Region Manager, which acts as the controller that reside in the application’s shell. A region manager can consist of multiple regions which represent the target placeholder for injection. A well-known library that already provide region manager functionality is Prism from Microsoft, which does the job well but with several limitations.

At a glance, the following illustration shows how the view injection/discovery works together with region manager.

View Injection v.s. View Discovery

Page-aware Region Manager

As I mentioned earlier, Prism provides several functionality related to region manager. I won’t discuss Prism’s region manager concept in details here, but would like to point out the general principles and overview its differences with ClientUI’s region manager.

Prism’s region manager is built around the concept that centralizes on shell (also known as Root View). This means that you will normally define the region manager in the shell, and define the regions within the shell as well. See the following picture for more details.

Region in Prism

While this single region manager concept works well in common scenarios, it falls short on certain scenarios such as multi-page applications. You cannot define the regions within the shell in multi-page application, because the view/content is defined in separate pages, not in the shell. There might be several ways to workaround this using the existing library but that would be less-than-ideal due to the extensive additional code.

With multi-page applications in mind, we built our own region manager to facilitate view extensibility supporting both view injection and view discovery methods. The page-aware region manager is perhaps the most interesting feature in ClientUI’s view extensibility design.

It enables you to simply define the region manager and the associated regions in the pages without needing to know when the regions need to be instantiated or activated. When the page is activated (either through browser journal navigation or navigation link), the defined regions in the page will be automatically filled with the injected view content. This allows view extensibility to be achieved with loose coupling approach.

The following illustration shows the region manager concept implemented in ClientUI.

Region in ClientUI

With page-aware design, our goal is to make modular application development easier and more maintainable. It allows you to simply define the region scope and the regions in each page without concerning when to instantiate or disposing the regions – the framework does it all for you behind the scene.

Implementing View Injection

Now that you’ve got the idea what region manager is about, let’s go further and see how to implement the view injection in ClientUI.

First of all, you define the region manager and regions to the containers that will participate in the view extensibility. The containers can be a simple content control, items control, tab controls, window controls – or any control types that serve as containers.

<Intersoft:UXPage 
        Intersoft:RegionManager.IsRegionScope="True" 
        Intersoft:RegionManager.ScopeName="Home">

    ...

    <Intersoft:GroupBox Header="Quick Tasks">
        <Intersoft:UXItemsControl Intersoft:Region.RegionName="QuickTasks">
            <Intersoft:UXHyperlinkButton Content="View Top Customers"/>
            <Intersoft:UXHyperlinkButton Content="Manage Products"/>
            ...
        </Intersoft:UXItemsControl>
    </Intersoft:GroupBox>

</Intersoft:UXPage>

The example above shows the region manager and scope definition in the UXPage, followed with the region definition for the target container which is the UXItemsControl in this example.

Once the regions are defined, you can now access to these regions using the region manager API. This allows you to instantiate the view element and inject it to the target region from either code behind or ViewModel. Often times, you might want to do the injection in the bootstrapper where the application module is first loaded. Here’s an example.

    public class AppInitializer : IApplicationInitializer
    {

        #region IApplicationInitializer Members

        public void Initialize(ApplicationPackage package)
        {
            // add new links to the Quick Tasks region on-demand ("view injection") when this XAP is loaded
            RegionManager manager = RegionManagerService.FindRegionManager("Home") as RegionManager;

            manager.AddViewToRegion("QuickTasks",
                new UXHyperlinkButton()
                {
                    Content = "New Link 1",
                    Foreground = new SolidColorBrush(Colors.Red)
                });

            manager.AddViewToRegion("QuickTasks",
                new UXHyperlinkButton()
                {
                    Content = "New Link 2",
                    Foreground = new SolidColorBrush(Colors.Red)
                });
        }

        #endregion
    }

As the results, when the XAP is loaded, notice that the new hyperlinks will be added to the Quick Tasks control which can be seen in the following illustration.

View Injection

Implementing View Discovery

Similar to the view injection, you always need to define the region manager and regions in the views that will be extended.

The difference with the view injection is that you don’t write code to inject the element to the target region. Instead, you simply add decorator attributes to the class that will be injected to the target region. When the target region is loaded, it will discover all views that should be injected based on the metadata, hence the injection is processed seamlessly and automatically.

Here’s an example of the view discovery implementation.

    [ViewPart("Home", "Overview")]
    public partial class Overview : UserControl
    {
        public Overview()
        {
            InitializeComponent();
        }
    }

The ViewPart attribute above basically states that the Overview class should participate in the view discovery process which target the Home region scope and Overview region.

And here’s the screenshot that shows the application before and after the view is discovered.

View Discovery

Comparing both view extensibility approaches, it’s obvious that the view discovery is the easiest and most efficient way to achieve the view extensibility goal. I’d recommend to use view discovery pattern whenever possible, unless you need to inject the view based on certain conditions or complex business logics.

More Advanced Features

Of course, we’ve only seen the basics of the view extensibility so far. The region manager in ClientUI also provides many advanced features that I couldn’t share in this single post alone. These advanced features include:

  • Custom region adapter which enables you to extend the region manager service to your own containers
  • Selection control support
  • View activation support
  • Integration with Navigation Framework

Download Sample Code

At this point, you have learnt the basics of view extensibility and how you can implement it using the API available in the next version of ClientUI. The view extensibility can be very useful if you build applications that allow third-party developers to create add-ons on top of your standard functionality. For an instance, consider a standard customer form shown in the screenshot below.

Existing form

With view extensibility, third-party developers can extend the existing form by adding new view elements without changing or even recompiling the original apps, see the below illustration.

Extended form

To preview these new exciting features, we’ve created a complete SDK sample that demonstrates the view injection and view discovery implementation using ClientUI preview builds. The sample also demonstrates how IoC container can be used along with region manager to facilitate really powerful extension capability to your apps. You can download the reference sample here.

In the next series of my blog post, I will do some previews on the upcoming new UI controls and top-requested enhancements. Stay tuned!

Best,
Jimmy

ClientUI 7 Preview Part 1: Built-in IoC Containers

Since its debut two years ago, ClientUI has been designed to facilitate application development toward loose coupling approach. This can be seen from the comprehensive MVVM-ready components and application framework included in ClientUI, then followed with the introduction of Event Aggregator in the latter release. In addition, most of our samples and tutorials are built with the MVVM design pattern as well. In the upcoming releases, we’ll take the design pattern to the next level by introducing a lightweight IoC container which is integrated to many important aspects of the ClientUI application framework.

In this blog post, I’m excited to share what ClientUI has to offer in the next major release. I will focus on the framework enhancements and new advanced library specifically designed to enable you write maintainable code with maximum loose coupling. Before I introduce these new libraries, I’ll discuss the basic purposes of the loose coupling design pattern, so you can see what the new library does, and how it addresses the programming challenges.

Dependency Injection Demystified

Unless you write prototypes or applications that never make it past release 1, you’ll
soon find yourself maintaining and extending existing code bases. To be able to work
effectively with such a code base, it must be as maintainable as possible. One of many ways to make code maintainable is through loose coupling. In short, the main point is that loose coupling makes code extensible, and extensibility makes it maintainable.

One of many techniques to enable loose coupling is Dependency Injection (often called as DI). A lot have been said and written about DI these days – it’s fascinating how most of these literatures make DI sound so complicated, yet it’s really simple in reality. Powerful yet simple. In this blog post, I hope to be able to give a decent and clear explanation about DI and its main concept, and how it differs from Inversion of Control (IoC).

Let’s dive in. Assume you run a new business that started using PayPal as your payment provider. Naturally, you’ll create a website that processes the transactions online, hence the following code.

public class MyStore
{
    public bool ProcessTransaction(Transaction trans)
    {
        PayPalPaymentProcessor paymentProcessor = new PayPalPaymentProcessor();
        return paymentProcessor.ProcessPayment(trans);
    }
}

The code above is very simple and straightforward, and does the job pretty well. First, it instantiates a new PayPalPaymentProcessor class and then call the ProcessPayment method. Nothing’s wrong.

As your business grows, you’d like to switch to different payment processor (or add a new option), let’s pick Google Checkout as an example. To make this happen, it’s obvious that you’ll have to find the piece of code that processes the transaction, modify the code to introduce the new payment option and rebuild your project. You’ll probably come up with the following results.

public class MyStore
{
    public bool ProcessTransaction(string type, Transaction trans)
    {
        if (type == "PayPal")
        {
            PayPalPaymentProcessor paymentProcessor = new PayPalPaymentProcessor();
            return paymentProcessor.ProcessPayment(trans);
        }
        else if (type == "Google")
        {
            GooglePaymentProcessor paymentProcessor = new GooglePaymentProcessor();
            return paymentProcessor.ProcessPayment(trans);
        }
        else
        {
            throw new ArgumentException("Payment processor not supported", "type");
        }
    }
}

Again, there’s nothing wrong with the code above as it does the job pretty well. However, doing the job well doesn’t always mean it has met the requirements to build good applications, for instances, in terms of maintainability and extensibility. In the case above, the code wasn’t really maintainable as you have to repetitively make changes on the same piece of code when you add new payment processors. This, naturally, makes your application more difficult to extend, not to mention if you want to hand over the code to be maintained by different developers.

Architecturally, the main problem with the code above is the referenced dependencies where the MyStore class depends on the concrete payment processor class such as PayPalPaymentProcessor or GooglePaymentProcessor. The concrete type dependency makes it impossible for you to plug-in new payment processors without modifying the code. So what we’re going to do next is take out the dependencies and revamp our code into the following.

public class MyStore
{
    public MyStore(IPaymentProcessor paymentProcessor)
    {
        if (paymentProcessor == null)
            throw new ArgumentNullException("paymentProcessor");

        this.PaymentProcessor = paymentProcessor;
    }

    public bool ProcessTransaction(Transaction transaction)
    {
        return this.PaymentProcessor.ProcessPayment(transaction);
    }

    protected IPaymentProcessor PaymentProcessor { get; set; }
}

Now what do you think? Looks much neater and easier to read, isn’t it? In the code above, the dependencies to the concrete types have been eliminated and replaced by the interface abstraction of the payment processor. The MyStore class now requires the payment processor to be passed in the constructor, which is a common technique known as constructor injection while the Guard in the constructor ensures a valid instance of payment processor is passed, thus ensuring the availability of the payment processor when consumed throughout the methods in the class. Ultimately, this resolution also addresses the extensibility issue as you can now instantiate the payment service externally and simply pass-in the instance.

In essence, the technique of passing (or injecting) the instance (PaymentProcessor) on to the depending class (MyStore) class is called Dependency Injection.

As we’ve just demystified the DI concept, it’s now becoming clear that DI has nothing to do with Inversion of Control (IoC) or any other programming frameworks, although in reality, both are often paired together to achieve the ultimate design goal – “Loose Coupling”.

At this point, still using the payment service scenario above, you will likely consume the MyStore class by instantiating it through manual construction. At the simplest, the code will look like:

public class MainPageViewModel : ViewModelBase
{
    private void ExecuteProcess()
    {
        MyStore myStore = new MyStore(new PayPalPaymentProcessor());
        myStore.ProcessTransaction(transaction);
    }
}

While the code above is much neater and easier to read, there’s still one last problem that violates the law of loose coupling design pattern. Without you realizing it, the MainPageViewModel class (the consumer) now depends on two classes: MyStore and PayPalPaymentProcessor.

Eliminating the dependencies completely in such scenario can be achieved by inverting the flow of control of the system in a way where the objects and its dependency graphs can be instantiated through an external assembler. This technique is called Inversion of Control (further abbreviated as IoC), and that’s where the IoC containers comes into the picture.

IoC Container Comes to the Rescue

IoC is a design pattern that inverts the flow of the application logic, which is achieved through the use of Dependency Injection for its binding process. This approach allows maximum loose coupling where dependencies can be minimized or completely eliminated. This also means that such code allows great extensibility as the concrete implementation can be easily swapped at runtime.

The payment service scenario earlier with the state where it left off is perfectly ideal for our IoC example, so let’s move on revamping our code and see what IoC container has to offer, see the following code.

public class MainPageViewModel : ViewModelBase
{
    private void ExecuteProcess()
    {
        IStore store = Container.Resolve<IStore>();
        store.ProcessTransaction(transaction);
    }
}

To remove dependencies on concrete implementation, one of the common approaches is by abstracting the implementation into abstract class or interface, as shown in the code above. Leveraging IoC container in this piece of code enables us to resolve an instance of the concrete store implementation – anywhere and anytime when required in the business logic flow – without knowing the exact type that contains concrete implementation. This is so powerful because it allows you to change the concrete implementation externally without ever touching this piece of code.

At the heart of IoC container are the Register and Resolve methods, which perform the following:

  • Register: Register a dependency by associating the abstract type or interface to the concrete type
  • Resolve: Resolve an instance of the dependency by looking up the exact registration in the container

Most of the dependency registrations are usually done in a centralized place, commonly invoked when the program initializes. This centralized place is called Composition Root, which allows you to manage the composition of all components and services in a single place. Using the payment service scenario above, the registration looks like the following.

public class AppInitializer : IApplicationInitializer
{
    public void Initialize(ApplicationPackage package)
    {
        IDependencyContainer container = UXShell.Current.Container; // or new IocContainer() for standalone container;

        // Register the IStore interface to compose a new PayPalPaymentProcessor through a direct construction
        container.Register<IStore>(o => new MyStore(new PayPalPaymentProcessor()));
    }
}

The code above is self explanatory – it registers the IStore interface type to a function that returns a new MyStore class complete with the required dependencies which is the PayPalPaymentProvider in this case.

The IoC container along with a set of comprehensive APIs are the new libraries introduced in next major release of ClientUI. It features full-blown IoC container features yet lightweight enough to deliver high-performing and scalable applications. At a glance, the key features are:

  • High-performance object factory
  • Abstract and interface type resolution
  • Open generic support
  • Instance-based resolution
  • Lazy resolution
  • Named containers
  • Lifetime Manager

Integration with ClientUI Application Framework

The IoC container implemented in the ClientUI Framework supports both standalone usage and integration with UXShell. For most common scenarios, it’s recommended that you use the default container instance which is accessible from the shell’s RootApplication.Container property. Using this approach enables you to resolve the registered dependencies anywhere in your code, including the dynamic XAP applications that are loaded on demand at runtime. Click here to learn more about ClientUI Application Framework.

In addition, the application framework now introduces a built-in bootstrapper to facilitate the dependencies composition and registration. Simply add a class that implements IApplicationInitializer interface in your Silverlight project, the Initialize method will be invoked as the application starts. In dynamic XAP scenario, the Initialize method will be automatically invoked when the XAP package is downloaded and loaded to the application domain.

Download Sample Code

In summary, the combination of design pattern best practices – such as MVVM, Event Aggregator, Dependency Injection and Inversion of Control – along with extensible application framework enable you to build great business applications that are easily maintainable and extensible. We see this as important milestones in our development roadmap as we geared our tools toward enterprise and line-of-business apps.

Another important point to keep in mind is that these design patterns aren’t exclusive only for Silverlight or WPF platforms although I picked Silverlight for the samples. We will bring forward these patterns to new platforms as they become available.

To test drive the DI concept and IoC container, I’ve prepared a small Silverlight sample that demonstrates how to achieve good architectural design by implementing Inversion of Control through Dependency Injection. The download package also includes the developer preview version of ClientUI Framework. Click here to download the sample package, and feel free to ask any questions or provide feedback in the comment box below.

In the next series of my blog post, I’ll discuss about several interesting new stuff such as View Regions, View Discovery and View Injection – and how they play well with IoC containers. Stay tuned.

Warning: Do not use the preview Framework assembly in your “live” projects as it will cause version incompatibility issues with the other assemblies in the current release.

All the best,
Jimmy
Chief Software Architect