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?
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
Hi Dorine
thank you for your reply!
We will know the data at design time and we will decide what widget to use.
Flexibility: we use 4 columns. The point would be for the user to decide in what column and in what order the widgets would be shown (and whether or not it would be visible).
The business rules will be specified server side as well. So we wouldn’t HAVE to use the built-in validations but it could be handy.
Yes, every user would change it for their specific use case.
How do you think we should built this?
Oke,
i find this interesting, I'll have a think
Hi Pieter, I did something similar a few months ago, but my user case was just about the ordering at runtime, not the position on certain columns.
Here the answer for your question is:
Yes its possible to do in reactive, you need to manipulate the DOM to rearrange the elements on the screen.
But to do that you do at runtime, what mean you see this happening on the screen while is being rendered and the effect on the screen could be a little strange, could be slow depending of the internet connection of the user or if is the first load of the page
My user case were just 8 input fields and I noticed problems with the speed, in your case 60 would kill the UX of the page.
My advice: try to change the requirement, manipulate elements on the DOM is never a good thing :)
ps: If I find my code I will place it here later on
Best regards
Carlos Lessa
Hi Carlos, thank you for your input. This made me think of some additional concerns such as speed.
I would indeed have to manipulate the DOM using jquery to rearrange the inputs.
I think we would only rearrange the screen at first load of the screen. If the user changes the settings/order of the inputs, he/she would have to refresh the page.
As I would only be able to start rearranging at the OnReady event, I would set a loader to hide all inputs and after the re-arrangement is done, I'd show the form. I think I will also need caching on the data to make sure we don't have to go to the database every time. We have over 300 of these forms to build so it's rather important to get this right the first time.
I'll try something out this weekend with a big amount of inputs and I'll see what the speed is.
Any code that you used for your use case would be very helpful! Thanks for that in advance!
I'm not following why you would need to do DOM manipulations ??
I thought you were talking about 1 form, but you are now talking about 300 different forms. 300, really ? are these variations on the same 60 inputs, or 300 sets of each dozens of other inputs ??
Something this complex, why pay for a low code platform like Outsystems, and then put the complex bits in some low level DOM manipulations.
We have 300 different forms with each 20-100 inputs. The requirement is that the user can decide for every form which inputs he sees and what the order is.
The business case for using OutSystems is valid as it will speed up development time of these forms and how they have to get into the db.
There’s only some additional code to add (I believe): to re-order the inputs in the form with jquery based on a list that’s coming from the database.
Do you see any other way of doing this in OutSystems?
Well,
I would think towards building up the screen with a list of widgets
the flow would go something like
I think steps 1, 6 and 7 are strongly tied to how you model your data and strongly tied in with your business rules. But if you are really talking about 300 forms each with on average 50 fields, it could be wurthed to try and store data in a generic way as well, and define business rules in a generic way, making all the translating back and forth much less work.
Steps 2 and 5 is where you transition from specific to generic and back. This would mean 300 retrieve mappers and 300 save mappers where the import/export would be in generic terms that your generic screen understands, and the internal logic of those mappers translating your generic data back and forth to the entities.
Steps 3 and 4 is what we have been talking about so far, I think you could develop 1 screen for all 300 of your forms, and there is no need to manipulate the DOM for this. What is it that you think we can't do in Outsystems itself?
"Steps 3 and 4 is what we have been talking about so far, I think you could develop 1 screen for all 300 of your forms, and there is no need to manipulate the DOM for this. What is it that you think we can't do in Outsystems itself? "
But one of his requirement is to ordering the input on the screen accordingly with the logged user.
Let say you have a design time order for the input of 1 - 2 -3 - 4- 5 but the specific logged user configured(saved) the inputs configs to have an order of 5 - 2 - 3 -1 -4, how do you change that order of the inputs without manipulate the DOM to achieve the proper order?
my suggestion involves making a list of field definitions as a source for a list widget with webblocks, each representing one piece of information. By manipulating the list sort order, the widgets will be in a different order.
Hi DorineHi 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?
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
Hello Carlos Lessa,
I am also looking for similar functionality,
In my case, all I need to do is re-arrange the containers or place the container on another position.
I am using adaptive columns 5 in that I have 10 containers, if one of them is set to invisible then there will be a blank space. I need to re-arrange the containers, so there will be no blank space.
Suppose container number 4 is invisible, then I need all the containers to dynamically re-arrange to eliminate the blank space.
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.