This is our sales document report, and this is how it works. Here's 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. Here we go. Now, let's try and build the very same report with a data composer to really grasp the difference between these two approaches. Let's get started. I'm creating a new report. 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. The schema aka DCS, is just another template that was created and attached to the metadata object when we click this button. 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 their regional report. Let's add the query dataset here. The query text lives in this module. 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 the field stable for me. All the fields taken from the products tabular section are auto titled by the composer like this. I'm switching the auto title off. 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'll be talking datasets and field settings in details later on this module. 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 that was set up so far are under the sole developers control. A user has no access to any of these whatsoever. This settings page is a completely different animal. This is where developers specifies the default settings which can and probably will be changed by user at their own time. First of all, I'm going to tell the composer to let a user select a document we want to 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. I'm going to the, Others page, and here's the report title. Setting it to sales. I also need to set the 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, they're closest analogue in the scheme is this grouping thingy, so I'm adding one. I don't need to group the data by anything. I'm leaving this field empty and giving the area the name, Header. Now we will go into tell the composer what field should be output to this area. These are number, date, payment method, additional info, amount paid, and loyalty card. 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. The same deal for the footer area. New grouping, area name, fields, vertical placement. Now, let's add the reports to the documents subsystem, let's see. This is our template based report, and this is our brand new DCS based report. Looks pretty much the same, doesn't it? Here's the best part for you. This template-based reports, content, and appearance, are hard-coded in the application. A user can edit it to some extent, delete the footer, change the table headers colors, etc. But it won't change the reports template or code. The next time I create the same report, all my changes are gone and I'm back to square one. Ask for my DCS based report, I can open these data composer settings like this. First of all say, Wow. Then I can disable the footer, change the products table appearance, and do many other things impossible with a 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 to move on doing whatever I'm busy with today. When I need the sales document report again, I can choose my saved settings. Here we go. I get much better functionality and flexibility than with a template based report. How many lines of code I wrote? That's right. None. This is how the template based reports differ from the DCS based ones. In terms of development complexity, that template-based report loses hands down. As for that functionality and flexibility, the DCS based reports win again.
