Workshop module builders configure custom (descriptive) external IDs for input parameter use via variable module interfaces. When embedded into a parent module, these external ID names are auto-detected and optionally configured to pass input to the module. However, when embedded on an Object View, the custom external ID cannot be used. The Object View uses the external ID object as a standardize external ID for all embedded modules. This is not public knowledge, not intuitive, and easily overlooked as the Object View editor gives little mention to this practice and it is only mentioned as such under one line in the documentation. Thus, unsuspecting application developers may experience differing behavior between modules embedded in other Workshop modules versus those embedded in an Object View.
Today, all workshop module builders must be educated on the use of this standard practice in order to get their embedded Object View modules to display properly. In the likely case that they experience unexpected results, the discovery of this practice in the documentation during diagnostics will require the module’s external ID be changed.
Documentation:
When adding a new Workshop tab on an object view, the current object is passed as an object set parameter to Workshop’s module interface variables with the external ID object.
Given the increased potential for error, I propose the Object View editor’s process for module embeddings be changed to match the Workshop embedded widget, and support custom external IDs. Provide a dropdown of the module’s interfaces that match that Object type. Allow the developer to use any of those interfaces (custom external IDs) or knowingly opt for the use of the standard object external ID.
