Previously, we explained how to build a “Suggestion Widget Using a Custom Directory Filled By a Web Service”. Today, we are doing the same thing:
- Create a Suggestion Widget,
- Fill it with data coming from a Web Service.
Well…
“If it is the same”, you may wonder, “why is he writing a new post?”. You would be right to wonder.
The point is: It is not exactly the same. In the previous post, the query to the web service was done once and the values found by this query were stored in memory (hence, the InMemory part in the name of the JsonInMemoryDirectoryConnector class). Narrowing the list to the value entered by the user was done in this pre-fetched list. It’s cool, it works, it’s good.
But we may also want to query the value every time the user changes the characters entered in the suggestion widget, so that, for example, we could reduce the memory used.
To achieve this, we are, of course, still using the base code Thierry Delprat(1) wrote in his nuxeo-directory-connector. This code handles the complex part of having a custom directory in a plug-in. I mean, you don’t even really need to dig into this part if you don’t want. The code I wrote in this new plug-in, is the same as in the previous post, except that it now also shows how to dynamically connect to the web service, using a new class: NuxeoDemoComDynamicConnector.
You will find there are a lot of explanations in the README file, in the NuxeoDemoComDynamicConnector class and even in the miscDirectoryConnectorsContrib.xml file. Yes. A lot. Looks like I am punishing myself for writing so few comments during the last hundred years(2).
The main differences between the two approaches are as follows:
- Number of requests to the web service:
- The “InMemory” connector example sends only one request to the server, whatever the number of characters the user enters in the suggestion box,
- While the “Dynamic” connector potentially sends a lot of requests:
- One request to get the documents every time the user changes the value in the box.
- Then, one request for each found document, in order to display their titles in the suggestion widget. So if the request finds, say, 50 documents, there will be 50 more requests to get the 50 titles.
- Memory used:
- The “InMemory” connector caches all the JSON returned by the query until the widget is closed,
- While the memory is cleaned up for right after every request for the “Dynamic” connector.
- Query statement:
- The “InMemory” example uses a hard coded URI, so the first request, the one which fills the list on documents, is triggered when the user clicks in the widget. If you want two different kinds of queries, you have to write two classes,
- While the “Dynamic” connector tunes the URI dynamically.
There is no specific advice to give here aside from stating the obvious. For example, if your web service is an internal service, inside the network of the company, with a very fast network, then, querying the service 50 more times may not be a problem.
Notice that possibly, we could even dynamically change the web service used, and sometime query one, then another, depending on the previous results, for example(3).
(1) Since the last post, he still is our CTO, and still writes code. Sometimes. (2) I started very early. (3) The current example does not do that, but it would be fun. And easy, once you get how all this works.(4) (4) Which I hope you get by now, after two posts on the topic.