PDP portals extract customized subsets of the metadata to serve limited goals (mainly, to this writer's knowledge, to populate the dataset selection dropdowns). In other parts of the code metadata is extracted from a dataset unique_id, which is fragile. Furthermore, this information (e.g., unique_id) is carried in non-obvious locations (e.g., the map layer name), which makes it harder to find and use.
It would be better to inject a full set of metadata (something like that provided by the CE backend) into the global object for a portal app, and refer to that for all metadata needs everywhere. Parallel to this, we would probably want at least a partial app state object, again replacing the distributed form of state. This would be a step towards a MVC architecture for PDP.
Full implementation of this idea would touch quite a lot of code, but it could be done incrementally, at the cost of some confusion to developers in the intermediate stages of the conversion. It will be worth evaluating more precisely the likely effort/code footprint of such a change.
PDP portals extract customized subsets of the metadata to serve limited goals (mainly, to this writer's knowledge, to populate the dataset selection dropdowns). In other parts of the code metadata is extracted from a dataset
unique_id, which is fragile. Furthermore, this information (e.g., unique_id) is carried in non-obvious locations (e.g., the map layer name), which makes it harder to find and use.It would be better to inject a full set of metadata (something like that provided by the CE backend) into the global object for a portal app, and refer to that for all metadata needs everywhere. Parallel to this, we would probably want at least a partial app state object, again replacing the distributed form of state. This would be a step towards a MVC architecture for PDP.
Full implementation of this idea would touch quite a lot of code, but it could be done incrementally, at the cost of some confusion to developers in the intermediate stages of the conversion. It will be worth evaluating more precisely the likely effort/code footprint of such a change.