Conversation
dnikolov-prg
left a comment
There was a problem hiding this comment.
Left some comments on the general explanations. I am not sure how "complex" we want this article to be, so some of them can be ignored if the suggestions are too advanced.
yordan-mitev
left a comment
There was a problem hiding this comment.
Use consistent terminology.
Co-authored-by: Yordan <60105689+yordan-mitev@users.noreply.github.com>
Co-authored-by: Yordan <60105689+yordan-mitev@users.noreply.github.com>
…k/reporting-docs into dess-data-binding-context
Co-authored-by: Yordan <60105689+yordan-mitev@users.noreply.github.com>
…k/reporting-docs into dess-data-binding-context
Co-authored-by: Yordan <60105689+yordan-mitev@users.noreply.github.com>
|
The initially provided feedback was addressed. |
|
There are 3 separate articles to be reviewed: |
There was a problem hiding this comment.
- Terminology inconsistency: The overview article introduces both "data scope" and "data context" but then alternates between them unpredictably. Pick one term and use it throughout.
- Frontmatter:
descriptionfields in two of the three files are well below the required 100-character minimum. - Missing alt text: Every
<img>HTML tag across all three files is missing analtattribute. - Voice and tense: Section headers in the tutorials use first-person plural ("We will filter…") and future tense instead of the imperative mood required for step-by-step instructions.
e.g./i.e.: Should always be written out as "for example" / "that is" in running prose.- Information flow: The articles chain together well as a series (overview → expressions → filters). However, the See Also sections do not yet reflect those relationships completely.
todorarabadzhiev
left a comment
There was a problem hiding this comment.
We reviewed the PR with @dnikolov-prg.
There are some things that are not entirely correct technically.
Let's discuss the articles in a meeting.
elkinmilen
left a comment
There was a problem hiding this comment.
A lot of conceptual explanations with examples. I believe this is a valuable addition for those targeting understanding to implement more complex reports. Thank you!
todorarabadzhiev
left a comment
There was a problem hiding this comment.
I suggested some minor improvements.
Please consider updating the slug syntax and code snippets notation for consistency with the rest of the Reporting docs.
|
|
||
| * Setting the SubReport Data Source from the Parent Report—The SubReport item exposes a DataSource property that allows the parent report to supply data directly to the inner report. When this property is set on the SubReport item, the provided data source is used during report processing instead of the data source defined in the SubReport’s report definition. | ||
|
|
||
| * Passing Data from the Parent—You can also use a DataObject as a data source for nested data items, meaning the child item’s entire data source can derive from the parent. A common scenario is when a parent data row contains a JSON column with child items. A similar approach is demonstrated in [Creating Nested Hierarchy with SubReports]({%slug wrd-user-guide-create-nested-hierarchy-with-subreport%}). |
There was a problem hiding this comment.
This may be done only with Bindings - I think this is worth mentioning.
|
|
||
| * **Aggregates** (like `=Sum(Fields.Amount)`) calculate over the current data scope by default. That is why the same `=Sum(Fields.Amount)` expression returns a group subtotal when placed in a group footer, but returns the grand total when placed in the report footer. | ||
|
|
||
| The Reporting engine provides the [Exec]({%slug telerikreporting/designing-reports/connecting-to-data/expressions/expressions-reference/functions/data-functions%}) aggregate function to perform calculations outside the current data or item scope. Unlike typical aggregate functions such as Sum, Avg, or Count, which operate only on the current data scope, Exec allows you to reference another parent’s scope. |
There was a problem hiding this comment.
Use (slug:telerikreporting/designing-reports/connecting-to-data/expressions/expressions-reference/functions/data-functions) instead of ({%slug telerikreporting/designing-reports/connecting-to-data/expressions/expressions-reference/functions/data-functions%}). We already migrated all slugs to this new syntax.
This is valid for the other slugs in the articles.
| * **Aggregates** (like `=Sum(Fields.Amount)`) calculate over the current data scope by default. That is why the same `=Sum(Fields.Amount)` expression returns a group subtotal when placed in a group footer, but returns the grand total when placed in the report footer. | ||
|
|
||
| The Reporting engine provides the [Exec]({%slug telerikreporting/designing-reports/connecting-to-data/expressions/expressions-reference/functions/data-functions%}) aggregate function to perform calculations outside the current data or item scope. Unlike typical aggregate functions such as Sum, Avg, or Count, which operate only on the current data scope, Exec allows you to reference another parent’s scope. | ||
| This makes Exec extremely useful when you need to display aggregated values in headers, footers, textboxes, or other parts of the report where normal aggregates are not allowed. |
There was a problem hiding this comment.
I would rather say that 'This makes Exec extremely useful when you need to display aggregated values over a grandparent scope rather than the default one.'
| |`ReportItemName`|The name of the parent (one or more levels up the hierarchy) data item (for example, a table, group, or list) that defines the scope.| | ||
| |`AggregateExpression`|A valid aggregate function (for example, Sum(Fields.Price), Avg(Fields.Quantity)).| | ||
|
|
||
| The following example shows how to display Total Sales in a TextBox placed in the header: |
There was a problem hiding this comment.
This makes sense for a group header. In the Report and Page Header, you have the report scope by default.
|
|
||
| ## Data Scope Inheritance | ||
|
|
||
| By default, a non-data item (like TextBox) automatically uses the data scope of its parent. That's why you do not need to connect every item to a data source manually—the Web Report Designer passes data downward through the report's items and data scope levels for you. |
There was a problem hiding this comment.
It is more correct to say 'the Reporting Engine passes data downward ' rather than 'the Web Report Designer passes data downward'
|
|
||
| 1. Add a CSV Data Source to the report with the following data: | ||
|
|
||
| ````CSV |
There was a problem hiding this comment.
Use ``` (3 ` ) for the snippets
|
|
||
| 1. Add fields to columns: | ||
| * Column 1: | ||
| ```` |
There was a problem hiding this comment.
For the Expression snippets, we decided to use (```Expression) - should have as language Expression
|
|
||
| You can filter data at multiple levels in your report. Each data level controls which records are available to the next level down. Parent scopes (like Tables) inherit all data unless you filter them. Child scopes (like Groups) inherit parent data (filtered or not) and can apply additional filters to the inherited data. | ||
|
|
||
| This article builds on the example demonstrated in [Data Scope in Expressions]({%slug data-scope-in-expressions%}), which demonstrates how expressions in group-level scopes default to operating over the subset of records belonging to the group. Aggregates placed outside the group (like table header/footer) compute over all records that the Table receives. That is why for the *Grand total we calculated 2850*, for **Accessories**, *Subtotal Amount is 150* and for **Electronics**, the *Subtotal Amount is 2700*. |
There was a problem hiding this comment.
The word 'demonstrate' repeats in the same sentence. You may use 'show' or another alternative in one of the places to avoid repetition.
No description provided.