Search results / Configure related records type depending on template. #7376
Conversation
fxprunayre
force-pushed
the
4-searchresults-relatedconfig-cleanup
branch
from
737688b
to
de36d86
Compare
The search API provides the possibility to load related records
for each hits. This allows to easily display them in search results
but it also slow down a bit the search.
Currently only the `list.html` template was displaying them based
on the following configuration:
```
resultViewTpls: ...
grid: {
related: ["parent", "children", "services", "datasets"]
},
```
but user may want to customize this depending on the result template.
This move the configuration to the `resultViewTpls` (and preserve
previous mechanism)
```
resultViewTpls: ...
{
tplUrl:
"../../catalog/components/" +
"search/resultsview/partials/viewtemplates/list.html",
tooltip: "List",
icon: "fa-bars",
related: ["parent", "children", "services", "datasets"]
},
```
so that user can more easily define which relations to load during
search depending on the result template used.
fxprunayre
force-pushed
the
4-searchresults-relatedconfig-cleanup
branch
from
de36d86
to
9aaae5f
Compare
Each search results templates display a specific set of fields. Add possibility to exclude unused fields from search to speed up search. At some point, it could be better to declare all required fields for rendering records on a per template basis on top of required fields needed for the JS app logic (eg. privileges, status, draft).
|
Kudos, SonarCloud Quality Gate passed!
|
Added @josegar74
Also updated missing translations. |
|
@fxprunayre something not critical, but defining a for a template an array of related types to load and later emptying the section, doesn't save the change. You need to set value to |
Added default empty array |
|
…plate. (#7376) * Search results / Configure related records type depending on template. The search API provides the possibility to load related records for each hits. This allows to easily display them in search results but it also slow down a bit the search. Currently only the `list.html` template was displaying them based on the following configuration: ``` resultViewTpls: ... grid: { related: ["parent", "children", "services", "datasets"] }, ``` but user may want to customize this depending on the result template. This move the configuration to the `resultViewTpls` (and preserve previous mechanism) ``` resultViewTpls: ... { tplUrl: "../../catalog/components/" + "search/resultsview/partials/viewtemplates/list.html", tooltip: "List", icon: "fa-bars", related: ["parent", "children", "services", "datasets"] }, ``` so that user can more easily define which relations to load during search depending on the result template used. * Search / Optimize field based on current template Each search results templates display a specific set of fields. Add possibility to exclude unused fields from search to speed up search. At some point, it could be better to declare all required fields for rendering records on a per template basis on top of required fields needed for the JS app logic (eg. privileges, status, draft). * Batch edit / Properly init result template config. * Search / Optimize field based on current template / Add admin UI config.
The search API provides the possibility to load related records for each hits. This allows to easily display them in search results but it also slow down a bit the search.
Currently only the
list.htmltemplate was displaying them based on the following configuration:but user may want to customize this depending on the result template.
This move the configuration to the
resultViewTpls(and preserve previous mechanism)so that user can more easily define which relations to load during search depending on the result template used.
Optimize search to avoid loading field not rendered in a template (eg. table mode don't display abstract and contacts)