
<div dir="ltr"><div>TL;DR:</div><div><br></div><div>The code at these 2 links seems to point the way towards building a Native Select Widget:</div><div><br></div><div><div>(1) <a href="https://github.com/urweb/gui/blob/master/select.ur" target="_blank">https://github.com/urweb/gui/blob/master/select.ur</a></div></div><div><br></div><div><div>(2) <a href="https://github.com/urweb/urweb/blob/master/tests/cselect.ur" target="_blank">https://github.com/urweb/urweb/blob/master/tests/cselect.ur</a></div></div><div><br></div><div>(3) However, even after building a new control combining the two examples above, a 3rd ingredient would be needed: make the control *data-bound* (ie, reading and writing to and from the SQL database).</div><div><br></div><div>(4) Finally, the above probably would only provide a *select* widget (where the user can only select an existing option). So, a 4th functionality would also be nice to have: *autocomplete* (a more flexible kind of widget, where the user can also type in a sequence of characters, and the menu options can be filtered).</div><div><br></div><div>The result would be a compact and hopefully efficient piece of code providing a Native Databound Autocomplete Widget - an essential GUI component, typically available to application developers in nearly all database frameworks (examples of polished JavaScript libraries include Select2 and twitter typeahead.js).</div><div><br></div><div>Any help on this would be greatly welcomed!</div><div><br></div><div>===</div><div><br></div><div>Hints towards an answer to the question I have been asking (on how to build a Native / FRP Databound Autocomplete Widget in Ur/Web - or even a foreign / FFI one) have actually already been published, in 2011, by Adam, here:</div><div><br></div><div><a href="https://github.com/urweb/gui/blob/master/select.ur" target="_blank">https://github.com/urweb/gui/blob/master/select.ur</a></div><div><br></div><div>fun crender r =</div><div>    <xml><cselect source={r.Selected}></div><div>      {List.mapX (fn r' => <xml><coption value={r'.Key}>{[r'.Display]}</coption></xml>) r.Choices}</div><div>    </cselect></xml></div><div><br></div><div>fun crender' r =</div><div>    <xml><cselect source={r.Selected}></div><div>      {List.mapX (fn s => <xml><coption>{[s]}</coption></xml>) r.Choices}</div><div>    </cselect></xml></div><div><br></div><div>and here:</div><div><br></div><div><a href="https://github.com/urweb/urweb/blob/master/tests/cselect.ur" target="_blank">https://github.com/urweb/urweb/blob/master/tests/cselect.ur</a></div><div><br></div><div>fun main () =</div><div>    s <- source "";</div><div>    return <xml><body></div><div>      <cselect source={s} onchange={v <- get s; alert ("Now it's " ^ v)}></div><div>        <coption>Wilbur</coption></div><div>        <coption>Walbur</coption></div><div>      </cselect></div><div><br></div><div>      Hello, I'm <dyn signal={s <- signal s; return <xml>{[s]}</xml>}/>.</div><div>      I'll be your waiter for this evening.</div><div>    </body></xml></div><div><br></div><div>This seems to be a good starting point for creating a Native Databound Autocomplete Widget in Ur/Web.</div><div><br></div><div>However, this stuff is hard to find.</div><div><br></div><div>Remark:</div><div><br></div><div>By the way, you generally are going to want *two* columns in your dropdown / datalist / list of options - so you would also use the `value` attribute, like so:</div><div><br></div><div>fun main () =</div><div>    s <- source "";</div><div>    return <xml><body></div><div>      <cselect source={s} onchange={v <- get s; alert ("Now it's " ^ v)}></div><div>        <coption value="WIIII">Wilbur</coption></div><div>        <coption value="WAAAA">Walbur</coption></div><div>      </cselect></div><div><br></div><div>      Hello, I'm <dyn signal={s <- signal s; return <xml>{[s]}</xml>}/>.</div><div>      I'll be your waiter for this evening.</div><div>    </body></xml></div><div><br></div><div>Fortunately this works as expected, and the text displayed in the browser switches between: </div><div><br></div><div>Hello, I'm WIIII. I'll be your waiter for this evening.</div><div>Hello, I'm WAAAA. I'll be your waiter for this evening.</div><div><br></div><div>(1) Question:</div><div><br></div><div>How can this be made "data-bound" - ie how can this widget be connected to reading and writing an SQL database?</div><div><br></div><div>I guess this could be an interesting exercise for the student to figure out - and if no one else does I probably will manage to eventually, since it's so incredibly important.</div><div><br></div><div>(2) Observation:</div><div><br></div><div>It's odd that the indispensable and ubiquitous *data-bound* version of the nearly standard or universal Select Widget (or, the more flexible Autocomplete Widget) - which is vitally important because it's used in nearly all CRUD applications to allow the user to easily set the value of a foreign-key field - would still be missing or forgotten after all these years in the Ur/Web literature - because, after all, Ur/Web is supposedly oriented towards web databases.</div><div><br></div><div>Try making an end-user-editable database without a Databound Select (or Autocomplete) Widget. It's not practical, nobody does it.</div><div><br></div><div>(3) Observation:</div><div><br></div><div>The fact that one of the function names here is called 'render' is interesting. This actually seems to be in line with the nomenclature in most of the horde of JavaScript frameworks which have suddenly discovered the virtues of being functional FP (and even trying to be functional-reactive FRP). For example, a big deal is made about the workings of the Mithril function 'render', etc.</div><div><br></div><div>Essentially this is all just using dataflow programming for GUI. It's already been proven to be the most compact notionally and the most efficient computationally.</div><div><br></div><div>It was also used for example in Arthur Stanley's k from <a href="http://kx.com" target="_blank">kx.com</a> in C on Windows in the 1990s as well - developed for an investment bank in Switzerland (that particular version, with the declarative functional-reactive dataflow-style Win32 / Posix GUI, got discontinued - I believe it was 2.4, I have a working copy around somewhere which I got off <a href="http://archive.org" target="_blank">archive.org</a> years ago, plus I have the old PDFs showing the layouts.  It is so cool to be able to specify a dynamic, interactive UI simply using a matrix of controls linked to data, in just a few lines of code. The syntax in that language k, for the two words corresponding to Ur/Web's `source` and `signal` - aka Qt's `slot` and `signal`, etc. - was: `trigger` and `dependency`.)</div><div><br></div><div>(4) Observation:</div><div><br></div><div>The code (which I've posted previously - it's at the end of the link below) from a possibly related JavaScript front-end approach (in this case, RxJS + Mithril - which is functional and "FRP-friendly"), may be suggestive here, of how to best implement a native autocomplete widget more efficiently in native Ur/Web</div><div><br></div><div><a href="http://www.impredicative.com/pipermail/ur/2015-July/002047.html" target="_blank">http://www.impredicative.com/pipermail/ur/2015-July/002047.html</a></div><div><br></div><div>Also, in particular, the "function pipeline" from the above RxJS+Mithril code is suggestive:</div><div><br></div><div>var AutoComplete = {</div><div>  controller() {</div><div>    this.data = m.prop({});</div><div><br></div><div>    Rx.Observable.fromEvent(el, "keyup")</div><div>     .map(pluck("target")) /* get element */</div><div>     .filter(el => el.matches("input")) /* make sure it is the input */</div><div>     .map(pluck("value")) /* get element's value */</div><div>     .filter(val => val.length > 2) /* at least 3 chars */</div><div>     .debounce(250) /* debounce it */</div><div>     .distinctUntilChanged() /* ignore non character keyups */</div><div>     .flatMapLatest(searchGithub) /* fire request */</div><div>     .subscribe(this.data); /* set data prop with results */</div><div>  },</div><div>...</div><div><br></div><div>(5) Question:</div><div><br></div><div>How does combine the two fragments of Ur/Web code, such that when the user changes the text in the data-entry part of the widget, the list of items in the drop-down menu changes?</div><div><br></div><div>(6) Concern: I assume the the above Ur/Web code does indeed compile down to using HTML5 <select> and <option>? </div><div><br></div><div>That might be a limitation, because it would mean that the user cannot actually type keystrokes into an HTML5 <select>, they can only select an existing item from the list (ie, this would *not* be a combo-box). </div><div><br></div><div>ie, there would be no "data-entry part of the widget" (in the case of a <select> widget).</div><div><br></div><div>Actually, there might be a variety of mechanisms for producing this kind of look and feel in a browser today:</div><div><br></div><div>- <select> widget</div><div>- <input> plus <datalist>   -  but not supported in Safari, and lacks something related to the DOM</div><div><br></div><div>(7) Question:<br></div><div><br></div><div>Can the above Ur/Web code be used as the basis to implement a typeahead or autocomplete widget (ie one where the user not only can select an existing item from the list, but can also arbitrary text *into* the box).</div><div><br></div><div>If not, there might two possible solutions:</div><div><br></div><div>(8) Question: </div><div><br></div><div>(a) Can merely the *formatting* of HTML <select> and <options> be modified on-the-fly so that it *looks* to the user like they're entering a sequence of letters into box? </div><div><br></div><div>Ideally, I'd like to have it be like the follows, after the user typed m o n a:</div><div><br></div><div>mona</div><div>----</div><div>monaRCHY</div><div>monaCO</div><div>mona LISA</div><div>monaRCH BUTTERFLY</div><div><br></div><div>This can of course be done if the top control is user-editable (such as an <input>). But it might not be possible for the user to type into a <select>.</div><div><br></div><div>(b) Or, if the user can't "type into" a <select> then this would mean some other HTML tag(s) would have to be used (eg, <input> and HTML5 <datalist>).</div><div><br></div><div>I'm not sure how these HTML controls are produced by Ur/Web syntax.</div><div><br></div><div>(9) Observation:</div><div><br></div><div>Figuring out just the correct names and locations of the best components to use for front-end development is like a "scavenger hunt" or a "wild goose chase" (two weird but popular American idioms... speaking of idioms... but I digress :-)</div><div><br></div><div><br></div><div>(10) Conclusion: </div><div><br></div><div>The above Ur/Web code fragments do at least seem to provide a general outline (ie, FRP skeleton - or perhaps one should say: FRP wiring) for an autocomplete widget.</div><div><br></div><div>Probably only another few lines are required to implement sophisticated data-bound behavior - and maybe with some clever use of CSS, it could head in the direction of what we see with Select2 and Twitter typeahead.js (I can dream, can't I?)</div><div><br></div><div>###</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>