Coming in 2014 R1: ClientUI Reporting 2.0

Ever since we released the first version of ClientUI Reporting in 2013 R1, we continuously shaped up the entire reporting lineup with significant enhancements and new exciting features. With our fast-pacing sprint-based development process, we are very excited to announce that the next major release, ClientUI Reporting 2.0, will be available in 2013 R2. We will ship it along with a host of professionally-designed business report samples as well as comprehensive documentation.

In this blog post, I will share some interesting features that will be available in the upcoming release.

Sub Report

We have received tremendous requests asking whether sub report will be supported in ClientUI Reporting. Today I’m pleased to announce that sub report will be included as built-in report components in 2013 R2.

Sub-Report is Available in 2013 R2

As one of the most anticipated features, sub report allows you to embed one or more reports into a single report document. This can be useful when there is a particular report structure which have a consistent appearance and functionality that needs to be included many times in a report. In addition, you can also use it to easily create side-by-side reports similar to the screenshot below.

Create Side by Side Report using Sub-Report

Entity Definitions

I expect, at a glance you must be wondering what Entity Definitions is? What is it for? Is it related to the data definitions in a Report Document? Yes, it’s close enough. But before discussing furthermore, I will give some flashback on how do we define data definitions in a report previously.

Suppose you need to display sales in 2012 and sales in 2013 separately inside a report. The generated report XAML will look like the following.

<DataDefinitions>
    <DataDefinitions.ObjectDataSources>

        <ObjectDataSource Name="Sales2012" Guid="ab5ee58b31fd440aa34aaec8735abf29">
            <ObjectDataSource.PropertyDefinitions>
                <PropertyDefinition Name="OrderID" Type="System.Int32"/>
                <PropertyDefinition Name="ShippedDate" Type="System.DateTime"/>
                <PropertyDefinition Name="Sales" Type="System.Decimal"/>
            </ObjectDataSource.PropertyDefinitions>
            <ObjectDataSource.MemberParameters>
                <MemberParameter Name="Year" Type="System.Int32" Value="2012"/>
            </ObjectDataSource.MemberParameters>
        </ObjectDataSource>

        <ObjectDataSource Name="Sales2013" Guid="a8a466e9180a4aa88bd0d37567e58783">
            <ObjectDataSource.PropertyDefinitions>
                <PropertyDefinition Name="OrderID" Type="System.Int32"/>
                <PropertyDefinition Name="ShippedDate" Type="System.DateTime"/>
                <PropertyDefinition Name="Sales" Type="System.Decimal"/>
            </ObjectDataSource.PropertyDefinitions>
            <ObjectDataSource.MemberParameters>
                <MemberParameter Name="Year" Type="System.Int32" Value="2013"/>
            </ObjectDataSource.MemberParameters>
        </ObjectDataSource>

    </DataDefinitions.ObjectDataSources>
</DataDefinitions>

If you look into the above code, you can notice definition redundancy in the data sources. In the next version, we’ve greatly improved our reporting architecture in our mission to reduce report size and increase overall performance. Thanks to the new Entity Definitions, the data sources definition look much cleaner. And the good thing is, it’s highly reusable. See the following code.

<DataDefinitions>
    <DataDefinitions.EntityDefinitions>
        <EntityDefinition Guid="e68bf3c60eb74f019a5f7b3e5c5fbb44">
            <EntityDefinition.PropertyDefinitions>
                <PropertyDefinition Name="OrderID" Type="System.Int32"/>
                <PropertyDefinition Name="ShippedDate" Type="System.DateTime"/>
                <PropertyDefinition Name="Sales" Type="System.Decimal"/>
            </EntityDefinition.PropertyDefinitions>
        </EntityDefinition>
    </DataDefinitions.EntityDefinitions>

    <DataDefinitions.ObjectDataSources>

        <ObjectDataSource Name="Sales2012" Guid="ab5ee58b31fd440aa34aaec8735abf29" EntityGuid="e68bf3c60eb74f019a5f7b3e5c5fbb44">
            <ObjectDataSource.MemberParameters>
                <MemberParameter Name="Year" Type="System.Int32" Value="2012"/>
            </ObjectDataSource.MemberParameters>
        </ObjectDataSource>

        <ObjectDataSource Name="Sales2013" Guid="a8a466e9180a4aa88bd0d37567e58783" EntityGuid="e68bf3c60eb74f019a5f7b3e5c5fbb44">
            <ObjectDataSource.MemberParameters>
                <MemberParameter Name="Year" Type="System.Int32" Value="2013"/>
            </ObjectDataSource.MemberParameters>
        </ObjectDataSource>

    </DataDefinitions.ObjectDataSources>
</DataDefinitions>

With this improved architecture and design, it will effectively suppress the size of report document thus enhancing overall user experience.

Enhanced Table Cell

We have been intensively working to bring some great enhancements to the table component. You would love to see that our table now supports cell merging. As seen in the following screenshot, the table cells can be merged either horizontally or vertically. Furthermore, some new commands have been added to ribbon bar, allowing you to easily merge and split the cells.

Table Cell Merging

In addition, our table component also supports image and checkmark, allowing you to create truly appealing business reports. Definitely, you can easily customize it from the ribbon bar.

Designer Lock

Another interesting feature not to be missed is the ability to prevent end-user from editing the report document at runtime. It will ensure there is no changes can be made to report document at runtime. As can be seen in the screenshot below, all of editing commands is disabled while this feature is turned on.

Runtime Designer Lock

Not only for an entire report document, the designer lock can also be applied on specific pages, or on specific report components.

Custom Report Templates

While working with reports, sometimes you need to ensure consistency between each reports. In this case, it’s necessary to use report template to provide standard layout pattern. Some repetitive tasks while creating a new report can be skipped, so you can focus on the specific requirements of the new report. These tasks may include customizing page layout, defining data definitions, headers, footers, and also styling.

Custom Report Template

It’s easy to create a report template, you only need to create a new report which contains customized page layout, data definitions, headers, footers, and styles, then store it as a resources in your application.

That’s all for now. I hope you liked these enhancements and new features. As usual, feedback and comments are warmly welcomed.

Warm Regards,
Jack

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s