Thanks Michael!

This looks quite simple but you probably saved me two to four hours of figuring out which lib to use, how to invoke the completion and how to shape the server response. Will try to use it in my app tomorrow.

And since there has been a question on this list recently which sites are built on BaseX, I will add to the list the site that I’m currently working on (Hogrefe Publishing’s Clinical Handbook of Psychotropic Drugs) probably in September, when it will have been relaunched. Accessing the site requires a subscription though, but maybe the publisher will decide that at least the search be free, enticing more mental health practitioners into subscribing when they want to access the search results…

Gerrit

On 26.06.2020 16:34, Michael Seiferle wrote:

Hi Gerrit,

I came up with the following example — https://git.basex.io/basex-public/mailinglist-autocomplete

Hope this helps — feel free to ask for more. I simply chose the first autocomplete library that showed up when asking google for "autocomplete lightweight“ ;-)

Probably the most relevant changes compared to the default BaseX Config files are here:

Changed the Servlet mapping, so RESTXQ is output at `/api` (and not /)

...

https://git.basex.io/basex-public/mailinglist-autocomplete/-/blob/main/webap...

And static-files are output at: `/` instead of the default `/static`

...

https://git.basex.io/basex-public/mailinglist-autocomplete/-/blob/main/webap...

If you simply clone my repo, the relevant parts should be „correct“ — according to my personal taste ;-)

Feel free to ask for more help.

Michael

...

Am 25.06.2020 um 18:31 schrieb Imsieke, Gerrit, le-tex gerrit.imsieke@le-tex.de:

Hi List,

Can anyone recommend a lightweight vanilla Javascript autocomplete library that can easily be used together with BaseX RESTXQ? Maybe even a readily cloneable/modifiable example? I don’t have a preference for a server response format. The RESTXQ service may be configured to return XML, JSON, or HTML No CORS restrictions need to be considered, the query host is the same that delivers the HTML pages.

Gerrit

Hi Michael,

Just to let you know that I finally and successfully used the full text index for autocompletion, based on your prototype code.

My endpoint for the lookup is like this:

declare %rest:path("/chpd/{$work}/complete/{$what}") %rest:single (: only run 1 query per client :) %output:method("json") %rest:GET function chpd:complete($work, $what) { element json { attribute type {"array"}, let $tokens := ft:tokens('CHPD_' || $work || '_hobots_FT')[starts-with(., $what)] return for $t in $tokens let $c := number($t/@count) order by $c descending count $rank where $rank le 10 return element _ { attribute type {"object"}, element label {string($t)}, element value {string($t)} } } };

As I previously wrote, the site will (re-)launch later in September, and I will post a link then. Although it is behind a paywall, I will look into making the full text search and navigation lists available publicly in order to lure people into subscriptions.

The full text search is satisfyingly fast, at least when I’m the only user on the server.

Most other pages will be cached as HTML (with some placeholders for login/logout & user name) by the access control application, written in Ruby on Rails. This is because I render them dynamically from BITS with Saxon, and although the rendering is fast, it would be a waste of resources and a worse user experience if each page serving took additional ~ 200 ms of XSLT rendering time.

Among other reasons, I do render them dynamically (instead of serving statically rendered HTML) because there is a drug comparison functionality that takes 2 or more drug description pages (CHPD = Clinical Handbook of Psychotropic Drugs) and presents a side-by-side diff. The possible drug combinations for diffing are to manifold to pre-render them as HTML. Diffing the HTML instead of the BITS XML was not an option due to accidental changes in the output (the document structure of the BITS sources are more stable than the HTML output). Since all other pages use the same rendering XSLT as the comparison pages, I thought it would be too complicated to serve specific pages as pre-rendered HTML while dynamically rendering other pages. Therefore this HTML rendering happens dynamically, and it is cached also for the comparison pages.

Some more details: The BITS→HTML rendering is powered by our jats2html library (https://github.com/transpect/jats2html/blob/master/xsl/jats2html.xsl). In the XSLT you see imports like <xsl:import href="http://transpect.io/xslt-util/lengths/xsl/lengths.xsl%22/%3E. These URIs don’t resolve immediately. They need a catalog resolver in order to resolve to local resources. A shoutout to Liam Quin (and to Christian) for making catalog resolution available to xsl:import and xsl:include, https://github.com/BaseXdb/basex/issues/1719, which has been quite a hairy issue.

If there is an XML Prague next year and if it features a BaseX user meeting (nudge nudge), I will be happy to present the application in greater detail.

Gerrit

On 28.06.2020 22:56, Michael Seiferle wrote:

You’re welcome. Glad I could help save some time, I agree it looks simple, yet wrapping ones head around those small details can be a real showstopper sometimes :-) Feel free to ask for more details anytime.

Looking forward to seeing said search portal!

Best from Konstanz Michael Von meinem iPhone gesendet

...

Am 27.06.2020 um 14:13 schrieb Imsieke, Gerrit, le-tex gerrit.imsieke@le-tex.de:

This looks quite simple but you probably saved me two to four hours of figuring out which lib to use, how to invoke the completion and how to shape the server response. Will try to use it in my app tomorrow.

Am 27.06.2020 um 14:13 schrieb Imsieke, Gerrit, le-tex gerrit.imsieke@le-tex.de:

...

...

...

This looks quite simple but you probably saved me two to four hours of figuring out which lib to use, how to invoke the completion and how to shape the server response. Will try to use it in my app tomorrow.

This seems to be a year old, but since Gerrit just mentioned it, I realized, that some additions (for the archive, should someone search for it) may be nice. I had good success with [EasyAutocomplete](http://easyautocomplete.com)

EasyAutocomplete is a highly configurable jquery autocomplete plugin:

• It supports local and remote data sets (JSON, XML and plain text),
• Uses ajax method calls,
• Allows to search, sort and match the response phrase,
• It lets you use a couple of different list templates and even offers

you possibility to create your own list template,

• As one of the best jquery autocomplete plugins, EasyAutocomplete

supports callback handles, so it can be configured to run functions on specific events,

• It has a couple of interesting, clean, modern build in css styles

(no images requirement).

It is an MIT licensed and supports XML out of the box.

From the docs:

EasyAutocomplete plugin can be connected to an xml data provider. It

requires more configuration than json, but nothing is overly complex with this jquery autocomplete plugin.

I never used it in production, only for hobby, so I can not guarantee for good performance, but, overall, I liked working with it very much.