A chance conversation this week brought up another design pattern that is quite common. The request is a simple one – I want to ask the user in an interview to create some instances of an entity.

There are essentially several options – using both the standard Entity Collect control or an Entity Container. It all depends on the desired effect and the level of control you want to give the user.

Option 1 – Basics

Use a fixed value or a dynamic attribute value to control how many Instances of an Entity are presented to the end user. Consider the following. I want my interview user to record lost luggage. I want users to be able to specify how many luggage items they want to record, and then do it either in a Table ( single Screen) or Form (one Screen per Luggage item).

Upside : it’s completely standard and requires nothing other than an entity and some attributes. The first Screen collects the number of items, and the second Screen (if using a Table) collects the luggage items as Instances of an Entity.

Downside : the user can add and remove as many Instances of an Entity as they want. The property controls the initial display of blank instances, but does not stop the user from either deleting or adding as many as they see fit. So the level of control is low. As we just mentioned there are some solutions to remove features such as the buttons but it’s not as flexible as we would maybe need.

But this is all good, still, since there is no code and no configuration beyond simple control properties. Where the “other option” comes in is usually in a highly controlled situation with some requirements for the Instances of an Entity:

1. The luggage must have a numeric identifier like 1,2,3,4 and the user must not be able to change that.
2. The user can only create a specific number of luggage items, with upper and / or lower bounds

At this point, you can look to option two:

Option 2 : Still No Code – Use an inferred Entity and an Entity Container

Again this is no code – there is absolutely no need to use any JavaScript to do anything (although you might restyle the container but that doesn’t affect the outcome). You can, as in the first example, use either a Form-based (one luggage item per Screen) or a table-based (all items on one Screen) approach. This makes no difference to the outcome either.

This time around to save space the number of luggage items is collected on the same Screen. It does not have to be. Notice that there are two areas for entering the number of luggage items.

What I don’t want to do is have to provide a drop-down with every imaginable number in it, just in case the user wants to create, say, 8 items. So I create Value List for the initial dropdown and a second, numeric entry, for larger numbers.

For the end user we make it obvious by including a different display text in the dropdown once we reach the larger numbers.

The actual luggage is created using a loop. Now, loops can be bad if they are not controlled and not managed properly, but here the risk is very small given how much we control the value of the number of luggage items.

To save space I have put all the rules together so you see visibility and inference rules in one place – not good practice but it keeps the number of screenshots to a minimum. You can see we infer the first luggage item if there is at least one, and the others are inferred if the number is larger. In total therefore we have two reference relationships added to the model.

The end result is rather pleasing – the luggage items are directly identified by their numeric indicator and the user can add all the details.

The end result looks a little like this demonstration. The project can be found here in the Online Shop.

For more about relationships and entity inference, see our series about Relationships (1, 2 , 3, 4, 5, 6, 7, 8, 9). There are also some good examples in the Online Documentation of the Example Projects. Of course the example shown can be further tweaked and enhanced, even can have code added (but only with a good reason to want to customize the behaviour or display of the Entity Container for example).