rustygad wrote:
1. On success1 format there is a "valueField": "value" property. I take it that this is required and it has a relation to the "value" field on success2 format. Am I thinking right.
When you do a database-driven dropdown, you have properties called "choice options field" and "choice values field" that determine which of the returned columns are for the choices (i.e. the data the user sees on the screen) vs. the values (i.e. the value sent back to the program). You could not do the same thing with the choices url method because there was no equivalent to these properties.
For example suppose your API returned a row of data like this:
Code: Select all
{ "PRID": 101, "PRNAME", "Cool Product Name Here", "PRPRIC": 15.2 }
How could Profound UI know which ones were to be displayed for the user to select from, vs which one, specifically, is returned to the program? For that reason, the "choices url" was limited in that the "choices" and "values" always had to be the same list of items. The "valueField" property in the returned document overcomes that by letting you specify which field contains the value to be sent to the program. (In the above example, "valueField" would be set to "PRID" most likely to indicate that the product id should be returned.)
rustygad wrote:
2. On success3 format what does "colWidths":[30,5] do?
Hmmm... not sure I totally understand, myself. It has something to do with controlling the sizes of the columns when the popup is shown for the user to display. It tries to auto-calculate this if it can't use the values you supply, though. This was not new with this update, it was always there.
rustygad wrote:
3. How does one supply an additional parameter to the choice URL. For example, a user supplies a transaction type from a dropdown and you what to use that value to only select the specified transaction type when the user types the auto-complete field.
You could try using applyProperty() or similar to update the URL
rustygad wrote:
The example readme needs a couple of modifications.
- 1. No CL program is necessary to call the web service FRUITSUR. My PUIMAPP is to /fruits PUISAMPLES/FRUITSUR.
2. I renamed CL program FRUITSUCL to FRUITSC then changed it to call FRUITSR. The url to evoke the example:
"http://your-system:port/profoundui/start?pgm=PUISAMPLES/FRUITSC".
1. The purpose of the CL is to set the library list properly. If you call it from a Rich Display or Genie session, it will automatically sync the library list from the calling application -- so that might be why you didn't need this CL program. However, sometimes APIs are called from other environments. Personally, I like to test my APIs with tools like PostMan or SoapUI. When you do that, there's no calling display to sync the library list with... so having a CL program to set up the library list is very helpful. Likewise, if your calling program doesn't happen to contain the libraries needed, the CL can be used to modify the library list. As such, I will leave it alone
2. Not sure what you're saying should be modified, here. You renamed FRUITSUCL to FRUITSC on your system... but that doesn't mean that we should change it in the README, since others haven't made this modification.
rustygad wrote:Many thanks to the Profound development team for implementing this enhancement. They did a great job.
Thank you!