Include form ID and request type ID in dynamic content request body

[keison-tang]

I am planning to display dynamic content based on the tags on the form and request type.

Currently, the dynamic content POST request body does not include any information about the form or request type that the statement field is in. This would mean I need to create a specific endpoint for each form I intend to implement this for.

If this information was included, I could then use the same endpoint for all of the forms. When processing the POST request I can then include logic to find the tags.

This may also be useful for dynamic fields as well.

[Nness]

Just to be clear. request type is an optional info. When form is used as inline form, the request type does not exist in that context.

Form ID itself won't bring much help unless you hard code it. If you want to reuse and understand the context, pass form tags would be better in my opinion.

We have two options.

• Include tags as parameter in content query API. (by system)
• Include parameter that manually pass in by user who set this up. So system doesn't care. If we pass tags from forms, there could be chance someone remove that tag from form that broken your implementation.

In such case, I think you request may not be optimal. Please think again.

[Nness]

Until we can get an reasonable conclusion this is declined. Declined towards idea of pass request type ID and form ID.

[keison-tang]

Yes fair enough, we can hard code any required information to the query parameters of the dynamic content form field URL. 👍

[Nness]

The tag's use case is for categorize request type or forms. If we have hidden relationship between tag and it's dynamic content, then anyone who can alter form need to aware of that. Include admin, master admin etc. Or any people new who start manage form or request type.

On the other hand, tag's context is for whole form. Use such global level context on an single field is also problematic. Where if anyone want to included multiple dynamic content, which tag is for which field?

The best way of dealing with this is use hard coded parameter on content API. such as following.

https://content-url.com/api/dynamic-content?widget=feature1&widget=feature2&widget=feature3

That way, unless someone modify the field, else the content is very consistent. No accident could alter the dynamic content.

The downside of such approach is user need to aware how to use those parameter when they create dynamic field. But that's same as any other tutorial, the benefit of that is after setup it won't break. Unless the field been modified again.

[Nness]

There are several things we need to consider when we design an functionality.

• Ease of use.
  • Tag is easy to add and remove. It is too easy to add and remove, also anyone can alter as long as they have access to form editor.
  • Query parameter in API is hard to alter compare to tag, both require documentation. The benefit is no accident will happen.
• Consistency
  • No random event will be able to alter the outcome. When we have 5 people who are managing user experience. We need 5 people to all aware which tag could alter the outcome of the form content, else there is consequence of broke the contract on any given point.
• Explicit is better than implicit.
  • In Zen of Python we have explicit is better than implicit. Tag to alter the outcome of dynamic content is an implicit effect. It is not the original intention of the tag. Use it for something unexpected, no one will expect it.
  • Query parameter on API URL has direct relationship with the API and it's response. No one will have question, which is an explicit design.