Layer dataviews target

[dbauszus-glx]

Layer dataviews should behave similar to location dataviews. It should be possible to create dataviews in the layer view dataviews panel without the need for a tabview.

The forEach iteration of dataview object entries wasn't very elegant.

The method will now use a for of loop of the dataview object entries.

The chkbox element generated by the mapp.ui.Dataview() method will be added to the contents array for the dataview drawer.

The for loop will continue if the tabview has been identified on a mobile.

The dataview.target will be added to the content array if no target is defined in the dataview entry. This is the same behaviour used for location view dataviews.

It should be possible in the future to add the content from any panel method without the drawer element to the layer view. #1719

[simon-leech]

This section in the location/entries/dataview.mjs is wrong.
An entry does not (ever) have a class. So entry.class is undefined, resulting in a class for the entry of location undefined. Instead I think this should use entry.query or entry.key as the class name?

    // Dataview will be rendered into location view.
    entry.locationViewTarget = mapp.utils.html.node`
      <div class="${`location ${entry.class}`}">`

[dbauszus-glx]

@simon-leech I am ok for you to ammend this PR. Is the location class even needed for the dataview target element? It should be assumed from the element being positioned inside the location view grid.

Can you also review this item? I didn't want to add this to the layer dataview logic as I don't think this is ever used. I believe this to be some legacy logic from ancient 'report' application views. I believe in modern view scripts the dataview is created by calling the dataview method directly rather than calling the infoj method.

  // Dataview will be rendered into target identified by ID.
  if (typeof entry.target === 'string' && document.getElementById(entry.target)) {

    // Assign element by ID as target.
    entry.target = document.getElementById(entry.target)

    // Create and update the dataview.
    if (mapp.ui.Dataview(entry) instanceof Error) return;

    entry.update()

    return;
  }

[simon-leech]

This section in the location/entries/dataview.mjs is wrong. An entry does not (ever) have a class. So entry.class is undefined, resulting in a class for the entry of location undefined. Instead I think this should use entry.query or entry.key as the class name?

    // Dataview will be rendered into location view.
    entry.locationViewTarget = mapp.utils.html.node`
      <div class="${`location ${entry.class}`}">`

I have addressed this in this PR #1786 - as part of a patch, which will subsequently be merged into this PR once approved.

[simon-leech]

@simon-leech I am ok for you to ammend this PR. Is the location class even needed for the dataview target element? It should be assumed from the element being positioned inside the location view grid.

Can you also review this item? I didn't want to add this to the layer dataview logic as I don't think this is ever used. I believe this to be some legacy logic from ancient 'report' application views. I believe in modern view scripts the dataview is created by calling the dataview method directly rather than calling the infoj method.

  // Dataview will be rendered into target identified by ID.
  if (typeof entry.target === 'string' && document.getElementById(entry.target)) {

    // Assign element by ID as target.
    entry.target = document.getElementById(entry.target)

    // Create and update the dataview.
    if (mapp.ui.Dataview(entry) instanceof Error) return;

    entry.update()

    return;
  }

On the second part of this example - we actually do still use this sometimes. You are right it came from legacy but I think we should still support it or it will mean re-writes to all 'report' application views when upgrading?
An example is like this, where we use a skipEntry dataview with a target to be rendered as follows:

  {
      "skipEntry": true,
      "label": "Demographics",
      "type": "dataview",
      "target": "demographic-details",
      "query": "report_demogs",
      "table": {
        "placeholder": "No Demographics",
        "layout": "fitColumns",
        "columns": [
          {
            "title": "Field",
            "field": "field",
            "headerSort": false,
            "resizable": false
          },
          {
            "title": "Value",
            "field": "value",
            "headerSort": false,
            "resizable": false
          },
          {
            "title": "Field",
            "field": "field2",
            "headerSort": false,
            "resizable": false
          },
          {
            "title": "Value",
            "field": "value2",
            "headerSort": false,
            "resizable": false
          }
        ]
      }
    }

  // Create tableviews that are stored on the report layer
    location.infoj
      .filter((entry) =>
        new Set([
          "demographic-details",
        ]).has(entry.target)
      )
      .forEach((entry) =>
        mapp.ui.Dataview(entry).then((table) => table.update())
      );

[simon-leech]

I put this into draft until we merge the other dataview PR as i think they'll be merge conflicts to resolve.

[gitguardian]

️✅ There are no secrets present in this pull request anymore.

If these secrets were true positive and are still valid, we highly recommend you to revoke them.
While these secrets were previously flagged, we no longer have a reference to the
specific commits where they were detected. Once a secret has been leaked into a git
repository, you should consider it compromised, even if it was deleted immediately.
Find here more information about risks.

---

^{_{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}}

[dbauszus-glx]

The show/hide methods in the dataview layer panel are only required for dataviews in tabviews. For dataviews in the layer panel itself the default dataview methods assigned by the dataview ui module should work as expected.

[RobAndrewHurst]

I am all happy with this!

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AlexanderGeere]

Working as expected.