Why was it chosen to put "Search String" to the context object instead of an extra microflow parameter?

[basi01]

Dear authors. Is there a technical limitation that does not allow custom widgets use micrfoflows with two or more parameters or use primitive parameters? Otherwise I don't understand why we have to add a dedicated attribute to our form entity just to hold the search string when we use a microflow as the data source for this widget. The form entity is persistable, setting this new attribute will mark it dirty. Is there a known workaround for this problem? Don't tell me we have to wrap the widget with a data view and a harness of microflows to copy the data back and forth. This is no RAD at all. We just wanted a replacement for a regular reference selector, but with auto complete and server search.

[pratleymatthew]

Hi @basi01,

From memory, I don't believe it is currently possible to pass in multiple parameter's into the search microflow. I believe this may have been a limitation within Mendix when this was originally built (however I'm not 100% sure).

It is possible to use the "Search by microflow (Cached)" functionality to avoid the requirement of a "Search String" attribute (see screenshots). However, this may not be a viable workaround if you are using custom filter logic based upon the search string entered, as this will just filter on a single attribute for the objects returned by the selected microflow.

Hope this helps,

Matt