Dynamic form best practices

Dear Community,

I have a specification for a dynamic form which might be altered in the future, so I was wondering what would be the best practice.

I though of few solutions, but I am uncertain of which one would be more optimal from the interfaces and (re)usability point of view. And perhaps none of the solutions I thought are good enough. I would like to ask for some suggestions and what would be the best practice, as I rather prefer spending time analyzing a good solution before getting in to the implementation that later could become hard to maintain.

It goes as follows. The main CDT contains many different fields, but the options of being displayed and/or mandatory goes depends on more than one selection. The best way to know the different fields to be displayed it is a form of a table. As an example, it would look something similar like this:

The CDT is the "product" where it has different fields (option 1, option 2 and option 3), but you can save a fix value depending on the selection that you have done previously.

So, if you select Product 1, then a second dropdown will appear where you can select a,b,c,d. If you select a, then you can see a new dropdown with option 1.1, 1.2, 1.3. If you select b (and product 1), then  the field does not appear.

Similarly, the product 2 has the same set of dropdowns, but the option 2 should not be displayed (and keep a null value) and the Option 3 appears with the same values that you could select on the product one.

One of the solutions that I though was to hardcode the selection directly on the interface. Then do the interface in a way that it looks different when it is used for a form or for a record.

another solution i though, much more complex, it is to have stored in the DB the configuration - with a CDT "product configuration" - with many Boolean that determine the dropdowns.

 

Thanks!

 

 

 

 

 

  Discussion posts and replies are publicly visible

Parents
  • Certified Lead Developer
    The most common way to do this would be to basically hardcode your interface to handle the design logic - at least when there's some guarantee that the logic will be static or at least change very slowly / rarely. However if you expect the logic to update pretty quickly or dynamically, it might be better to go with your alternate approach and somehow encode the logic into the database in such a way that i can be updated more easily. The up-fron lift for this is much higher but when needed, it can pay off in the end. The main other disadvantage to this is that you basically need to invent your own markup and your own parser from scratch.
  • Thanks for your answer.

    I agree that hardcoded is the most straight forward approach.

    I don't think the interface would be needing changes that often, but from the best practice point of view I was wondering if there was some kind of indication of how to best do it. I guess dynamic interfaces is not a new thing and I think that it might create much logic on an interface that later would be difficult to maintain and/or to read for another developer. On the other hand, probably is the best for the performance, as you save a couple of calls to the DB.
Reply
  • Thanks for your answer.

    I agree that hardcoded is the most straight forward approach.

    I don't think the interface would be needing changes that often, but from the best practice point of view I was wondering if there was some kind of indication of how to best do it. I guess dynamic interfaces is not a new thing and I think that it might create much logic on an interface that later would be difficult to maintain and/or to read for another developer. On the other hand, probably is the best for the performance, as you save a couple of calls to the DB.
Children
No Data