Dynamic number of fields in widget builder

CM1 Ideas and Feature Requests
1

I really like the widget builder as a flexible way to create user-friendly custom widgets. However, I feel like part of its power is hindered by only allowing a fixed, static set of fields for a widget.

For example, imagine a custom image slider widget. In the current version, a widget can have fields (such as title and source) for several images. So:

  • Image 1 Title
  • Image 1 Source
  • Image 2 Title
  • Image 2 Source
  • Image 3 Title
  • Image 3 Source

However, what this widget cannot do is allow for an arbitrary number of images. There is no way for the user to add more images to the slider.

It would be very useful to allow the user to add or remove fields from a widget, according to certain rules set by a developer. An example of how to do this would be to allow the developer to define a group of inputs known as an “image”, which has a title and a source, and then allow the user to add or remove these groups of fields from the widget. On the developer side, these arbitrary number of images could be accessed through some sort of loop statement.

So it’d look something like:
(user editing the widget)

  • Images
  • Image 1 [delete]
  • Title
  • Source
    -Image 2 [delete]
  • Title
  • Source
    [add]

(widget display html code)

{{for $image in $images}}

{{endfor}}

I think this would greatly increase the flexibility of the (already flexible) widget builder.

Thanks!

2

Richard,

This is great feedback, thanks for sharing! I know we’re talking about adding optional fields in a future iteration of the Widget Builder, with the use-case you outlined as one of the driving reasons. Would this be sufficient, or do you think the ability to delete the unused optional fields would be a cleaner, more user-friendly way of handling this?

3

Optional fields would be a step in the right direction, but it really needs more than that. In the example above, users of the image slider widget have arbitrary numbers of images they want in the slider.

Let’s say Bob in the athletics department has six pictures from the last game he wants to put in a slider, while Sue in admissions has three pictures of campus she wants to put in her slider and Frank in housing has ten pictures of different dorms he wants in his slider.

We can’t really support these use cases with the current widget builder. In the current version, every image slider widget needs to have the same number of images, because there is the current widget builder only supports a fixed number of fields. It’s impossible for one user to have three images in her slider, while another user to have ten.

The most you can do with the current widget builder to address the use case would be to have ten image fields, and have the users leave blank the image fields they don’t use. Then your image slider code would have to be smart enough to ignore empty fields. But this doesn’t even solve the problem completely, because what if a new user wants eleven fields?

Optional fields would clean up the situation outlined in the previous paragraph, but still don’t solve the issue of having an arbitrary number of fields. With optional fields alone, there’s still going to be a maximum on the number of fields.

So what is needed is a way to have an end user of a widget arbitrarily add or subtract fields, in a controlled manner as defined by the widget creator. For example, a creator of a custom widget could designate fields or groups of fields that could have an arbitrary number of instances. The end user of the widget would have the ability to add or subtract instances as their needs require.

See the example in my previous post, under “So it’d look something like”. The [add] button would add another instance of the image set of fields (which contains a title and a source). The [delete] button would delete that instance of the image. Meanwhile, in the widget display code, a looping statement is used to iterate over the images defined by the user and display their field contents.

That’s just an example of how it could work. I’m sure there’s other ways it could work.

Thanks!

4

+1 for you Richard. I like this idea!

5

Yes, great post, Richard. This illustrates a very clear use-case, and I can see the value in some mechanism to add and subtract fields (or groups of fields), with some logic to append a unique item ID to the duplicated field’s names. This would take some work of course, but I definitely see the value here. Thanks for the follow-up!

6

Totally agree with Richard on this diea. I think I may have eluded to this in one of our Widget Builder Beta sessions as well, but maybe I didn’t hit on it as well as Richard has here.

7

I agreed with Richard on this idea. It would be nice to have the ability to add/remove certain fields dynamic. I’m glad you brought that up before I created a post about it!

8

Any update on this one?