Using the data structure in your first post …
[ "PRJ1077,A plus ...,2,blah,bloh", "PRJ1078,A ..." ]
This is a list of comma-delimited text. This list can be sent to a custom state (list of text) or a repeating group (data type text).
A repeating group’s data can be set in its properties (so it picks up from a source dynamically), or by a workflow step (so the workflow determines when the data is updated).
Each item you could extract into separate text fields with :extract with Regex
. This could be done in the RG cell, for example.
The disadvantage of this is having every value in a text format, making it a little harder to work with.
For your next data structure …
{“project name”:[“AU1”,“AU2”],“project status”:[“In Progress”,“In Progress”],“project startdate”:[“2/8/2017”,“17/8/2017”]}
You end up with a list of project names, a list of project statuses, a list of start dates. The lists are related to each other by position.
You could assign each list to a different custom state.
Then have, for example, a RG based on the list of project names, and in each cell, show the nth item in the list of start dates; n being the current cell index.
The disadvantage to this, is your lists are vulnerable to being altered severely by Bubble’s “duplicate value removal”, that happens whenever you do a Bubble list function on it, like add item.
I think Nigel was pointing you to having a structure like this, so that Bubble would behave nicely with it:
[ { "project name": "AU1", "project state": "going somewhere", "start date": date-format-that-bubble-likes },
{ "project name": "AU2", "project state": "going elsewhere", "start date": date-format-that-bubble-likes } ]
List of project objects, each object having properties: name, state, start date.
Then Bubble would have a list of objects, each object having a property you can use like item’s project name.