Expose attribute name or internal attribute identifier to APIs to allow Pluggable Web Widgets to integrate in a less fragile way - Mendix Forum

Expose attribute name or internal attribute identifier to APIs to allow Pluggable Web Widgets to integrate in a less fragile way

0

There is currently a limitation in the Pluggable Web Widget API that does not allow writing to values retrieved from a list datasource.

 

Here is the limitation mentioned in the API documentation:

https://docs.mendix.com/apidocs-mxsdk/apidocs/pluggable-widgets-client-apis-list-values/#obtaining-attribute-value

 

Here is a discussion about this problem from the forum:

https://community.mendix.com/link/space/widgets/questions/105072

 

Due to this limitation it is necessary to use the Client API to make changes to an object and commit it.  The problem with this approach is that the Client API must use names to make changes to attributes.  This is very fragile because those attribute names could change in the data model and the integration would fail for that specific field.  Field names can be passed in the pluggable widget configuration but these are still strings that would not change based on a domain model change.  Attributes can be configured in the widget configuration but the actual field name of that attribute is not available from the custom widget.  There are a couple options that could significantly improve integration.

 

1)  Make the name of the attribute available in the widget.  This way it could be configured as an attribute in the Mendix UI (which would update automatically based on domain model changes).  The widget could read the name and use this for making update calls in the Client API.

 

2) Make the internal attribute identifier available in the widget, and allow it to be used in the Client API to make changes.  It might also make sense to make this visible somewhere in the domain model view.  This solution is not quite as good as option 1 as I don't think the internal attribute identifiers are used in other locations.  Also, this would not allow easy using configuration of the widget by users in Studio Pro.

 

Either one of these solutions would allow the values in the Client API to be specified without concern about changes to the attribute name in the domain model.  This would make the integration much more resilient.

asked
0 answers