As an opendatahub developer i want to have a configurable Component in the databrowser v2 that is reusable and resolves a lot of Edge cases in the tourism api

[RudiThoeni]

As discussed here all informations about a General Configurable Component in the Databrowser V2 for Displaying and selecting data from a ODH URL

the component is part of an edit view of a single record. Instead of making a component for each use case, we could implement a configurable generic Component which could be used on many fields....

This are the required functionalities

• where to get the data from
  The Component should have a configurable URL where the data comes from.
  This configurable URL could contain variables of the current edited record at example with a %districtid% this value is passed to the configured URL. Special features could be: make use of the ODH Tourism searchfilter, that on each keypress the api is re requested with searchfilter=value. So we could avoid large lists problems. This functionality should be switched on by config on need. The combobox should be not only selectable but also allow insertion of text and present the search results Within the searchfilter it should be also possible to pass the current language.
  But inserting free text is not allowed only selection is possible

• what is visible in the combobox for the databrowser user the Component should have configurable Json Fields to Display in the Combobox. Maybe lets go an easy way and show this columns concatenated with a spacer character (-).
  Also here at least the language should be possible to pass, because this is needed often At example it should be possible to define items.Name[%lang], item.Id, etc... (To discuss maybe this can already be done in the api url)

• what is written to the Json of the opened Record The Component should have configurable Json Field Mapping to write to the Json of the Record currently opened. Example The Fields (items.id, items.locationid, items.accoid - activity_id, location_id, acco_id) To discuss: Maybe it could be possible to indicate if the result should be written in a list or in an object

This config allows to deal with almost all edge cases we currently have in the tourism api.

This component could be reused with his own config for Related Highlights, Related Content, Webcams Assignments, etc... also on already implemented Lists like it could be reused. Everywhere the data is available from an api.

Goal is to have a reusable component for future requirements like this to only add the data on Backend side Data Model, and on databrowser side to reuse this component with an appropriate configuration.

TODOLIST:

We agreed to omit complex object writing. The Component only writes the KEY to the actual Json.
We agreed to To investigate, how often is complex object writing (Related Content, Webcams, .....) needed

• [ ] We reuse the Components InputReferenceCell & TagReference (rename to Reference / ReferenceList).
• [ ] To discuss: use 1 component for objects and lists or 2 components
• [ ] Get data: Investigate possibilities to pass a value of the current json to the api URL (and react if the value changes), Example i will pass the DistrictId as part of the URL, what should be done if the DistrictId is changed by the editor.
• [ ] Display data: Here we have two possibliities of displaying other Labels:
  • [ ] String Format Config, where at example a additional field is shown as part of the label,
  • [ ] the second is to display an additional column (List) example publishedOn URL

[gappc]

Hi @RudiThoeni, thank you for this suggestion, it provides a lot of information and acceptance criteria that help to shape the component, i like it :+1:

fyi: there is already a similar component in place, the InputReferenceCell, that covers the use cases you mentioned. At the moment, it supports single values only and not complex objects or JSONs. We should have a refinement meeting where we further detail out how the final component should behave and then we see if / how we could modify the InputReferenceCell to meet the requirements.

@RudiThoeni, @sseppi: what do you say?

[sseppi]

@gappc Thank you for your valuable feedback! As next steps of this activity I see:

1. Have an internal meeting to discuss and finalize the behaviour of the components internally also with Patrick
2. Have a meeting also with you to define how implement the solution we identified

[sseppi]

@gappc today we reviewed the issue and we need now to plan it. Shall we organize a short dedicated meeting? If yes, can you send me your availabilities?

[gappc]

@sseppi yes, please send me your and @RudiThoeni availability.

[RudiThoeni]

Hi @gappc

I had a deeper look and investigated on the Data where the called "complex" object writing is needed, where it can be recreated on the backend, where it can be eliminated etc... Here some examples

• Webcam The WebcamInfo Here it makes sense to mark all properties instead of ID as obsolete and create temporary the logic of filling the Webcam Object on the Backend.

• ODHActivityPoi.LTSTags Here it makes sense to mark all properties instead of ID as obsolete and create temporary the logic of filling the LTSTag Object on the Backend.

• Event.Topics Here it makes sense to mark the saved additional property TopicInfo as obsolete and remove it completely,

• Related Content On RelatedContent it is very tricky. Related Content can be assigned from different Apis, example Events / ODHActivityPois / Articles. So in the Related Content List we need at least a property like a "Type" to identify where the Data came from....... Having the Id isn't enough because the "Self" Link cannot be created. So here we have to save maybe the _Meta.odhtype has to be assigned

• Accommodation.AccoRoomInfo Here the source of where the Room was synced is needed. Filling it in the Backend "could" be an option At the moment no manual room assignment is done by the redaction so maybe this can be simply set as readonly

• ODHActivityPoi.Tags (new) Here the Source of the Tag is needed. This should be the future Tagging system.

I identified two use case (RelatedContent, Tags) where some complex object writing is needed. Maybe we should have a short meeting on how we could manage this

To clarify

• Creating a custom Component or extending the InputReferenceCell & TagReference for this use cases
• What i am not sure also to clarify. Can the InputReferenceCell/Tagreference Component only write to a simple Array ["blah","test"] or write also to an object at example[{"WebcamId":"xyz"},{"WebcamId":"asdf"}]
• How can we manage if Related Content from more sources (example from api Events, api ODHActivityPois) can be added? To Discuss simplest solution: Adding more Components at example for Related Content where a configured property/string is written to the object example: one Component is for Adding Events, filters the Event Api and adds the property "event" to the Type field. The second component is for adding ODHActivityPois, filters this api and adds the property "odhactivitypoi" to the Type field..... The List of the Assigned Related Content of this Components however should also filter on the assigned Type (i can explain better in the meeting)

[gappc]

@RudiThoeni yeah, lets discuss this in a meeting 👍

[sseppi]

OK, @gappc I'll send you proposals for a meeting in a dedicated email.

I add another consideration from my side. In my point of view, in the future, it could be nice to have the possibility to assign related contents to all datasets and from all dataset in the Open Data Hub. So maybe in the future STA could add related content coming from different sources to their Charging station or Dolomiti Superski add related content coming from different sources to their lifts.

This means that we have to identify a generic solution that allows us to create relations between all Records present in the Open Data Hub.

[RudiThoeni]

We have this possibilities

Components

1. Specific Component for each Use Case (Related Content Component, Webcam Component, AccoRooms Component)
2. Generic Component configurable for each Use case

How should the data passed to ODH

1. We use the Self Link and shift the logic of complex object writing on the backend side (backend loads data x and fills the rest) Performance vs Data Quality etc
2. We use the current implemented complete Object Writing of ODH

[sseppi]

@RudiThoeni do you think we still need to implement this component, or with the last updates did we solved the problem?