Best practice for value lists

[naio]

I need to update a solution designed for FM9 to FM15, the whole solution has 68 value lists (VL) all of them based on tables but only a few of these are conditional VLs. All of the tables have a primary key and a value field. The solution is designed according to the separation model.

In the user file layout, each of VL data fields is duplicated so one field stores the value id (as dropdown list) and the other -just on top- shows the related value. This design requires a lot of table occurrences just to show related values which makes the graph and layout design more complex and tedious.

As most of the lists are static (their component values will never be changed) I wonder if I should transform these lists into the 'Custom value' kind. Given that the design is quite robust like this, it seems unnecessary to change it but the gains on design simplification and clarity are very tempting.

I would like to know the best practice using VLs. I would also appreciate your criteria about the use of dropdown vs the use of popup menu in the layouts.

 

 

 

Edited November 7, 2016 by naio
improve text

[bcooney]

Hi Naio,

I would not go the Custom value type, because you cannot move that list from one version of the solution to another. Table-based value lists can be imported.

I tend to use popovers with (filtered) portals to select a value list item (its ID), rather than a direct interaction with a popup menu. If the value list is short, then I'll use a popup menu directly. You can still use a popup menu non-editable to display the related value if you truly want to avoid the extra TO. Six of one, half dozen of the other, imho.

As for Best Practice, I think it's a matter of what's best for the particular scenario.