Question on best practies for implementing reusable choice lists

[fthomas]

Hi all, I’m fairly new to JA. I have a broad question regarding best practices on representing choice lists integrated from an external repository.

We have around 200 lists of items about half of which should be multi-select. In the future we may have to change a list from single to multi-select or vice versa which adds some additional complexity here. Each list consists of anywhere from 2 to 15 options that each consist of a string display name and an integer ID. The lists all live in a repository accessible via REST API. The names of items may periodically change, but the IDs never will.

The way I see it we have two broad approaches (I don’t think 3 makes sense), but I’m open to other suggestions:

1. Represent each Value List as a model. We can then populate the model via API and update display names as needed.
   a. Pros:
   i. Easier and cleaner to integrate. Can use built-in endpoints for instantiating value list item vs the file API to update the model which is messy and requires redeployment
   1. Note that value list contents change fairly rarely, but it does happen
   ii. Reusable across models. We will end up implementing multiple types of Surveys and there are some value lists that overlap
   b. Cons:
   i. Data model bloat. We have to implement hundreds of models and map each of them to the value list in the ECM
   1. This is fairly minor as I understand it. The number of models isn’t hugely important, right?
   ii. The view code gets uglier in the case of multi-select lists. Instead of a simple one-liner multi-select component, we have to implement some JS that instantiates a join table model object.
   1. We can perhaps consolidate this into some common function(s) reused across views?
2. Add a choice list for each value list. Populate the contents either manually or via file API (where is the documentation on the file API?). Pros and cons are largely the reverse of the above
   a. Pros:
   i. Data model and views are by and large cleaner
   b. Cons:
   i. More challenging to integrate. Using the file API sounds messy
   ii. Not reusable across models. When value list items change, they would need to be updated within every model that uses it
3. A single model for capturing JSON serialized value list items as objects and then deserialize this into choice options at runtime? The actual survey field would then be text and selecting from one of these.

[tielman]

Hi Fletcher

Thanks for the question In short, without having seen that actual data, I would recommended a version of Option 1.

You will store the lists and the list items as data in two models, one for storing each list (collection name | list description | list heading) and one for storing each associated list item in those lists.

So let’s assume you have data that looks like this in Excel where each value in Row 1 represents the collection and each entry beneath it in Rows 2+ represent the potential options for that collection.

My data model would look like this.

    <model name="list" label="List">
        <field name="name" label="Name" type="text" />
        
        <has-many model="list_item" name="list_items" />
        <display>{name}</display>
    </model>

    <model name="list_item" label="List Item">
        <field name="name" label="Name" type="text" />
        <field name="itemID" label="Item ID" type="text" />
        
        <belongs-to model="list" />
        <display>{list}: {name}</display>
    </model>

I would therefore have an entry in my list table for each entry in Row 1 (COLORS, STATUSES, CONDITIONS, CATEGORIES), and I would have an entry in my list_item table for each option in Rows 2+ including a belongs_to relationship to the relevant parent list object. You could even store a field on the list model to indicate whether the options in that list should be single-select or multi-select.

You can then reference these objects in a workflow by either using relationships (potentially even join tables - use case depending), or by having 1 more model which represents your users’ selections and this model will have a belongs_to relationship to the list_item model.

So in short, 3 models maximum I would say, but of course your use case may vary.

Hope this helps

[fthomas]

Hi Tielman. Very helpful response, I am happy with the list and list item model approach. However I am still up in the air on the approach for modeling a user selection. My initial approach as you’ve suggested above is:

1. When user selects an item, instantiate a “survey_item” object that belongs-to both the survey and the item

Thus each selection is represented by an object of a different model which looks good from a data modelling perspective on the JA side. However it’s kind of ugly from an integration perspective. While mapping objects into JA, if those objects need to relate to list items, the integration must create an additional object for each of those relationships.

An alternative approach might be to instead have a text field for each question on the survey model. The value of this text field would be set to the id of the selected list item or in the case of multi-select, a delimited list of ids.

What do you think about this? It sounds much cleaner to me, but I may be overlooking something.

Thanks,
Fletcher

[tielman]

I would go with 2 text fields on the survey model, one for the itemID and one for the Text display.

The reason for this is to maintain historical data accuracy. If the display value corresponding to the itemID changes over time, I would imagine you do not want your historical answers to get updated with it.

Ie, if itemID 1 maps to Green now, and I choose Green, then my choice should be recorded as Green, regardless of if the master data changes over time.

That said, I don’t think it makes the integration any more difficult to be honest. I assume you wouldn’t be creating “answers” via the integration, but would rather just need to push the entire survey, including all of the answers, to another system of record. In this case you just need to include those answers in the payload which should be a simple enough mapping exercise.

Assuming a single “answer” model, I would distinguish between the various answers to questions based on specific relationships, 1 specifically named relationship for each question you want the end user to answer. A belongs-to for single-select and has-many for multi-select

Again, the best practice here depends on what you want to optimize for. Data mapping, incoming, integration, outgoing integration, UI and UI Complexity. And as such, there is no single best answer.