So, this is our Sales document report and this is how it works. Here is the template containing named areas, parameters as well as some static text and formatting options like fonts, borders and such.
This template gets filled out by this code over here, and here we go.
Now let’s try and build the very same report with the Data Composer to really grasp the difference between these two approaches.
OK, let’s get started. I’m creating a new report, and this is where I can create a structured collection of the Data Composer settings called schema. This is what it looks like, but before we dig in let me show you one thing.
This schema (a.k.a. DCS) is just another template that was created and attached to the Metadata Object when we clicked this button. So, we could have added it manually like this and then select it here as the main Composer schema. But anyway.
Back to the Data Composer. This first page is for telling the Composer where to get the data from. We use query in the original report, so let’s add the query data set here. The query text lives in this module So, I’m copying it like this and pasting it right here.
As soon as I click outside of this frame, the Composer parses the query text and fills out this Fields table for me. All the fields taken from the Products tabular section are autotitled by the Composer like this. So, I’m switching the autotitle off. And this will be the new field title, which I’m completely fine with.
Now I’m doing the same with the rest of the Products fields. Let’s not worry about apparent complexity and abundant functionality of this page just for now.
We will be talking Data Sets and field settings in details later on in this module. So, I’m jumping straight to the Parameters page.
This Ref parameter is a reference to the Sales document that is passed by the Composer to the query when the report gets created.
There are two things I need to do with the parameter. Turn off this Value List flag that allows a user =to assign several values to the parameter, and deselect this Availability Restriction flag preventing users from setting up the parameter value from UI.
All of the things we set up so far are under the sole developer’s control. A user has no access to any of these whatsoever.
This Settings page is a completely different animal. This is where a developer specifies the default settings which can (and probably will) be changed by a user at the runtime.
First of all I’m going to tell the Composer to let a user select a document we want the report on. Now, let’s bring back our original template to look it up while building our Data Composer report.
First of all, let’s give our report the same title. These are the settings of the report as a whole. So, I’m going to the Others page, and here is the report title. Setting it to Sales.
I also need to set this setting to not display the parameter values in the report. Another static area - the product list table header - will be shown by the Composer automatically, so we just ignore it.
As for these three guys, their closest analog in the scheme is this Grouping thingy, so I’m adding one. I don’t need to group the data by anything, so I’m leaving this field empty, and giving the area the name Header.
Now I’m going to tell the Composer what fields should be output to this area, and these are: Number, Date, PaymentMethod, AdditionalInfo, AmountPaid and LoyaltyCard.
I also need to tell the Composer that I want these fields displayed vertically.
Next area - the Products table. Adding the grouping. Giving it a name. Selecting the fields.
And the same deal for the Footer area: New grouping, area name, Fields, vertical placement, done.
Now, let’s add the reports to the Documents subsystem, and, let’s see. So, this is out template-based report. And this is our brand-new DCS-based report.
Looks pretty much the same, doesn’t it? And here is the best part for you. This emplate-based report’s content and appearance are hardcoded in the application. A user can edit it to some extent: delete the footer, change the table header’s colors, etc.
But it won’t change the report’s template or code. So, the next time I create the same report all my changes are gone and I’m back to square one.
As for my DCS-based report, I can open these Data Composer settings, like this, and, first of all, say: Wow. Then I can disable the footer, change the products table appearance and do many other things impossible with the template-based reports - like changing the sort order and stuff like that.
After I save the changes, I can not only get the new-looking report but also save the settings under any name, close up the report and move on doing whatever I’m busy with today.
When I need the Sales document report again, I can choose my saved settings and here we go. So, I get much better functionality and flexibility than with the template-based report. And how many lines of code I wrote?
That’s right: none.
So, this is how the template-based reports differ from the DCS-based ones. In terms of development complexity the Template-based report loses hands down. As for the functionality and flexibility the DCS-based reports win again.