25
Views
13
Comments
Dynamically show and re-order widgets on form
Question
Application Type
Reactive
Service Studio Version
11.10.1 (Build 35287)
Platform Version
11.10.1 (Build 23852)

Hi

We're currently creating an application in which forms have +60 different inputs that the user can fill in. Some of them are mandatory, but most of them are not. Depending on the user, he or she will want to fill in certain fields. We would like to create a mechanism that will only show the fields that are required and the fields that the user wants to fill in.

The idea would be that we store the information in the database and when the screen is rendered, it changes the form in the way the user wants it. The user should be able to change: the order of the inputs, the tabindex, the default value (for when creating a new object) and whether or not the field should be visible.

Is something like this possible in OutSystems Reactive web? How would we do this?

Rank: #128

Hi Pieter-Jan,

Just for my understanding : the data themselves are known at design time?  In other words, you already know what those 60+ inputs are, how they relate to each other and how you want to store them in the database.  So it's not the case that your users have to be able to invent new pieces of data ??

So in that case, your question is just about building a form in a way that fits the users preference about what he wants to see, in what form and order, and with what prefilled values in case of a new item.

For this, you would, as you say, need some extra data, to model what the user wants to see, and you'd need a screen making use of those data to build the desired user interface.  I don't see why you couldn't do that with Reactive.

Some stuff to think about :

* do you want to give the user the freedom to choose the type of widget they use for a given input (do they want a dropdown or radio buttons to make a choice, do they want an input or a slider to choose a numeric value, do they want a checkbox or a switch to enter a boolean value, etc) If so, that's another thing you'll need to model in your extra data.

* how pretty and flexible do you want it, is it enough to just have all inputs under each other, or in 2 columns (you could use a list of webblocks, each respresenting one of your inputs) or do they need to be able to arrange the inputs anywhere they want on the screen)

* are there a lot of business rules related to these inputs, so where do you imagine to enforce those, you will probably not be able to make use of system generated validations ?

* is it really each individual user that has to be able to customize his form, or would you just have some typical use cases.  If these are just a few, it would probably be cheaper to design them upfront rather than have everything customizable.

On the other hand, if you don't even know what data you are talking about at design time, there's much more that you will have to model generically.  In such a case, you'll probably need to have some generic webblocks available, allow the user to define what webblock to use for what piece of data, store all users data in a generic way,...  I already get a headache just thinking about this.  

Dorine

Rank: #13328

Hi Dorine
Hi Carlos

I think both approaches will work but are just completely different in architectural approach. 

In the DOM approach, ordering and showing fields is almost purely a front-end functionality.
In the Generic Web Block approach, creating a "new" form would be done by adding records to a db.

To bring the data back and forth from the UI to Back-end, would be a challenge in the Generic Web Block approach and the mappers will become incredibly important. Debugging would also become a hastle and developers would have to have advanced knowledge to make changes. 

The biggest fear that I would have in the DOM approach is that the way a widget is shown and the id that is specified for that widget in HTML changes by some OutSystems UI update. That would completely destroy the jQuery method that I would use and I would have to re-create the method or modify it.

Still thinking about it, but I might go for the DOM approach solely for the reason of not overcomplicating the architecture and inner workings of the program. With that, I would create some UI tests that can be done every time we update the OutSystems UI module of an app to make sure we can at least modify the jQuery code if necessary.

What do you think?

Rank: #186

found it.

add to the extend property of the container from the input : data-category-group = value from the config, as you see on the pic bellow, the IFs of the container and from the form are coming also from the config


This was the first version, so no optimisations, the JS could be moved for the on after fetch or another place where will not be triggered all the time

I hope I could help you

Best regards

Carlos Lessa

Rank: #4430

I'd try and and break down the problem into say 3-4 "template" screens that a user can choose from that you save on their user profile to personalise their experience and navigate to the appropriate screen/form. Is the requirement really to be so dynamic with 60+ fields on one screen? In my view, manipulating DOM and resorting to JS could be difficult to maintain and degrade user experience.