/ Development  

Show form sections based on a selection dropdown

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

After all the ‘Management’ posts last couple of weeks, it’s time to do a nice low-code topic. This time a topic on hiding (or showing) the correct information on the correct “context” moment on your valuable form. Let’s say we have a ‘Contact’ entity and this contact is of a certain type. This can be a ‘Natural person’, a ‘Company’, or some un-natural existence like an ‘Alien’ 👽. All these types have their own small set of specific properties and during the creation of such ‘Contact’, we only would like to see the related properties.

FYI: The use-case described is just fiction and can also be solved by creating an abstract ‘Contact’ entity with new subtype entities! Each subtype entity will then have its own specific form with the correct properties. As always…It depends on how you like to build it!?


Let get right into it…

Spin up the VM and login to your favorite organization where you open the ‘Workspace Documents’ artifact with your developer account; awdev in my case. Let’s start with a new ‘Contact’ entity in the entities folder. Keep the below table as properties reference and generate the default BBs.

Name Label Type Length Pattern Used by
cnt_type Type Enumerated text 64 Person, Company, Alien
cnt_name Name Text 64 Person, Company, Alien
cnt_is_married Is married Boolean Person
cnt_id ID Text 64 Person, Company, Alien
cnt_phone_nr Phone-number Text 64 +31(0)612345678 Person, Company
cnt_language Language Enumerated text 32 Dutch, English, Other Person, Company, Alien
cnt_email E-mail Text 128 noreply@domain.com Person, Company
cnt_website Website Text 256 Person, Company
cnt_planet Planet Enumerated text 64 Mars, Jupiter, Venus Alien
cnt_has_spaceship Has spaceship Boolean Alien
cnt_vat_nr VAT-number Text 16 123456789B01 Company
cnt_company_name Company name Text 64 Company
cnt_avatar Avatar Image Person, Company, Alien

You can make it as fancy as you like. For the pattern check on email, phone-number, and vat-nr, I recommend to read this post!

When it’s all in place (incl. the Enum values and Boolean flags), you can go to the next section. There is no need to publish the project yet and create instances in runtime; we first update the ‘Create’ form with sections.


Update the ‘Create’ form

Now open the ‘Create’ form of the just created entity. Remove all the generated fields already available (except for the ‘Type’ dropdown) and add 3 extra sections to it. Our ‘Type’ dropdown will be in the top section, and we’ll create 3 extra sections below it. Make them recognizable with text components like this:

section_001

Next step is to ‘label’ each section with a category…Or better a ‘Rule category’ since the last versions of the platform. Go back to the entity overview and create 3 new ‘Rule category’ BBs with name rc_person, rc_company, and rc_alien. Select those categories on each related section:

section_002

Per section, we now drag & drop the correct properties (according to the last column of the table above) onto it. You can add the properties (belonging to all three types of contacts) to the top section where our ‘Type’ dropdown is available already. This can be the end-result after alignment and text-coloring:

section_003


Business rules to show/hide sections

With all the sections in place, we now need some business logic to show/hide the correct section with the option selected from the ‘Type’ dropdown. We all know by now (from experience), this is a task for the event-type of ‘Rule’ BB. We need several of those BBs for our mission to complete. Let’s first write it out in pseudocode:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
switch(type.getValue()) {
"person": {
BB.rc_person.show();
BB.rc_company.hide();
BB.rc_alien.hide();
}
"company": {
BB.rc_person.hide();
BB.rc_company.show();
BB.rc_alien.hide();
}
"alien": {
BB.rc_person.hide();
BB.rc_company.hide();
BB.rc_alien.show();
}
default: {
//Also, when no type is selected (= empty)!
BB.rc_person.hide();
BB.rc_company.hide();
BB.rc_alien.hide();
}
}

Time to start with the ‘default’ section. For this we create 3 new ‘Rule’ BBs of type event. With names like e_on_change_hide_rc_person, e_on_change_hide_rc_company, and e_on_change_hide_rc_alien. This is a screenshot for one, but the others ‘smell’ the same with different rule category selection:

section_004

There is no need for any condition (yet!); After the publication of the entity and creating an instance in runtime, we will only see the top section.

Next step is showing the correct section based on the selected type-dropdown. So, add another ‘Rule’ BB…

– A FEW MOMENTS LATER –

Well, you will also conclude there is no ‘Show’ or ‘Un-hide’ action available for the created categories (like in our pseudocode)! This requires a “Great ReThink”!!

How about this pseudocode (still with 3 rules!):

1
2
3
4
5
6
7
if(type != "person" || type.isEmpty()) {
BB.rc_person.hide();
} else if(type != "company" || type.isEmpty()) {
BB.rc_company.hide();
} else if (type != "alien" || type.isEmpty()) {
BB.rc_alien.hide();
}

Let’s implement this logic into the first ‘Rule’ BB e_on_change_hide_rc_person:

section_005

Make sure it’s an ‘OR’ statements. The advanced editor looks like this: item.Properties.cnt_type!="person" || item.Properties.cnt_type is null

We can implement this same logic to the other 2 ‘Rule’ BBs too; use the correct type-name and the correct rule category. For the good understanding, we still have only three ‘Rule’ BBs!

Go ahead, do the publication and create a new instance in runtime. After selecting a new type of contact, you should see the corresponding section on the form. Also, when you view/open the entity again the same logic still applies smoothly…GREAT! Job’s done!

WAIT…Questions, questions!…How about ‘Required’ fields on hidden sections?


How about ‘Required’ fields on hidden sections 😂

Well, make the ‘Company name’ required:

section_006

Try it out!? Conclusion: When the section is hidden the validation does NOT take place; as expected!

Did you know there is a “Configurable error behavior in runtime” option…Read all about it here! In 3 short steps:

  1. Edit: sudo vi /opt/opentext/AppWorksPlatform/defaultInst/config/wcp.properties
  2. Add content: platform.ui.application.error.onload = false
  3. Restart: systemctl restart tomee

A nice ‘DONE’ this time; we implemented interesting business logic on a ‘Create’ form. It shows the power of the ‘Rule category’ BB in combination with sections on a form. These principles also implement a better UX for the end-user where only the correct input is asked in context of a selected property. One great lesson I learned from the AWP is that you don’t want to serve overloaded information forms to your valuable end-users. I see you next time…Have a great week-end! Owh yeah…Don’t forget to drink a 🍺 with your UI-expert as he/she will help you in building that one-of-a-kind UX.

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The AppWorks guy”?