Open RudiThoeni opened 1 year ago
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?
@gappc Thank you for your valuable feedback! As next steps of this activity I see:
@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?
@sseppi yes, please send me your and @RudiThoeni availability.
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
["blah","test"]
or write also to an object at example[{"WebcamId":"xyz"},{"WebcamId":"asdf"}]
@RudiThoeni yeah, lets discuss this in a meeting 👍
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.
We have this possibilities
Components
How should the data passed to ODH
@RudiThoeni do you think we still need to implement this component, or with the last updates did we solved the problem?
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
Within the searchfilter it should be also possible to pass the current language.
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
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