We are on 7.4 We are starting on a new implementation and we have a difficult si

senthilar over 10 years ago

We are on 7.4 We are starting on a new implementation and we have a difficult situation to tackle. There are several Request Types and based on what Request Type is chosen by the user, the Questions which the user should answer via form would vary. The Questions could be text inputs, dropdowns, or booleans. We would be fetching dropdown (say, list of states) and boolean options values from DB. Now, to design the form, we are confused between 2 approaches:

1) Store all the questions in DB. And based on the Request Type chosen by user, query the database for the questions to be displayed. Then create the form elements dynamically.

2) Create form(s) at design time with all possible list of questions. Each question's (form element) visibility will depend on the Request Type chosen by the user.

This seems to be a common scenario. Pls post your ideas around this. What would be the pitfalls? What would be the challenges? There are hundreds of fie...

Discussion posts and replies are publicly visible

0 senthilar over 10 years ago

...lds in total.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Tim
Certified Lead Developer
over 10 years ago

I would definitely recommend approach 1 as we are currently having great success displaying dynamic SAIL forms using the a!applyComponents function. Your database query can return the questions and also the meta data required to render the fields. Very simple to then just loop through the dataset at runtime.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 jamesw353 over 10 years ago

How's the performance using this approach? I've run into similar situations and considered this method but have never seen it in use. My concern is that the DB server is getting queried every time the SAIL form is refreshed, which if you have "refreshAfter" set to keypress on any fields could get expensive. You could save the data to build the form outside of the SAIL rules, but this would only work inside of a process. I'm thinking there's another way to load a local variable only once when a rule is being refreshed, but that method is escaping me. I think that means it's time to hit the coffee pot again.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 Tim
Certified Lead Developer
over 10 years ago

Remember that data fetched within a load() statement will only be evaluated once so there isn't any repeat DB interaction on re-evaluation of the SAIL expression. We are generating up to 40 different fields including dropdowns with long lists in under 1 second.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 jamesw353 over 10 years ago

That's what I was trying to think of. Thanks. I'll definitely be checking this out. How's form maintenance using this method? I'm assuming you could have an Action to let process owners manage the field labels, instructions and such instead of republishing to fix typos and wording issues.
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel
0 senthilar over 10 years ago

Thank you for sharing thoughts Tim!
Cancel
Vote Up 0 Vote Down

Sign in to reply

Verify Answer

Cancel