[Ur] Simple example using source / signal to filter a recordset using a <ctextbox> and SQL `WHERE ... LIKE` - Getting compile error `Have: xml` vs `Need: transaction`

Sun Aug 16 01:12:00 EDT 2015

Note: A GitHub repo has been created containing the code for this question
- and the README on the GitHub provides a much *better* formatted version
of this question. You can access it here:

  https://github.com/StefanScott/urweb-queryX1-dyn

So, the README at the GitHub repo is exactly the *same* as the message
below - but the GitHub README is much *easier* to read, since it has bold,
italics, code font, and more links. So you might prefer to read this
message on the GitHub repo!

Thanks for any help getting this code to compile.

Objective:

I'm trying to create a minimal example of a page with a <ctextbox> which
will allow the user to instantly filter the records displayed in an <xml>
fragment below it, using:

- Ur/Web's dynamic page generation / FRP (source, signal, <dyn>);

- the function queryX1 from top.urs / top.ur;

  https://github.com/urweb/urweb/blob/master/lib/ur/top.urs#L205-L208

  https://github.com/urweb/urweb/blob/master/lib/ur/top.ur#L284-L289

- Ur/Web's SQL LIKE operator.

  http://www.impredicative.com/pipermail/ur/2015-August/002189.html

This would provide simple "live" filtering of recordsets, and possibly also
lay the groundwork for later developing a data-bound type-ahead /
auto-complete widget.

The page contains only the following two elements:

(1) a <ctextbox source={theFilterSource}/>

(2) a function call `{showRows theFilterSource}` returning an <xml>
fragment containing a <dyn signal={...}/> tag, which should either:

- show all records from table `thing` (if `theFilterSource = ""`);

- otherwise, show only filtered records from table `thing` - ie:

`SELECT thing.Nam FROM thing WHERE thing.Nam LIKE {[aFilterString]}`

Previous, related work:

The code connecting the source and the signal is closely modeled on:

(1) the Ur/Web Increment and Batch demos;

  http://www.impredicative.com/ur/demo/increment.html

  http://www.impredicative.com/ur/demo/batch.html

(2) the Ur/Web <cselect> test;

  https://github.com/urweb/urweb/blob/master/tests/cselect.ur

(3) a very minimal (and correctly working) Ur/Web FRP example
urweb-ctextbox-echo:

  https://github.com/StefanScott/urweb-ctextbox-echo

which just instantly echoes the contents of a <ctextbox>, directly below
the <ctextbox> itself.

Results:

The compile error says `Have: xml` vs `Need: transaction` for lines 27-33
in file queryX1dyn.ur:

https://github.com/StefanScott/urweb-queryX1-dyn/blob/master/queryX1dyn.ur#L27-L33

    <xml><dyn signal=
      { aFilterSignal <- signal aFilterSource
        ;
        return
        ( showRows' aFilterSignal )
      }
    /></xml>
  end

Remarks:

(1) Looking at queryX1 in top.urs / top.ur, I believe that the result type
of `fun showRows aFilterSource` is `transaction xml`.

Questions:

(1) Is the result type of `( showRows' aFilterSignal )` (apparently
`transaction xml`) compatible with all three of the following parent /
containing "contexts" listed below?

(a) what is expected by the <dyn signal={...}> tag containing this function
call; and/or

(b) what is expected by the "parent" <xml> tag containing the <dyn> tag;
and/or

(c) what is expected by the <xml><body> tag in the main function where this
value is used.

(2) Does Ur/Web impose some (general, universal) restriction on the result
type of the code used in a <dyn signal={...}> tag?

It seems very possible to me that answering the above questions might help
to understand (and resolve) the compile error - reproduced in full further
below, and also at the following anchor link on the GitHub README:

  https://github.com/StefanScott/urweb-queryX1-dyn#compile_error

Similarities and differences between queryX1dyn.ur and previous work:

Similarities:

(1) The `showRows` function (and its auxiliary `showRows'` function) in
queryX1dyn.ur are very closely modeled on the `show` function (and its
auxiliary `show'` function) in the Ur/Web Batch demo.

https://github.com/StefanScott/urweb-queryX1-dyn/blob/master/queryX1dyn.ur#L5-L34

  https://github.com/urweb/urweb/blob/master/demo/batch.ur#L21-L39

For more details, see "An interesting idiom" at this anchor link:

https://github.com/StefanScott/urweb-queryX1-dyn#observation_1

Differences:

(1) The `show` function in the Ur/Web Batch demo apparently has result type:

  xml

while the `show` function in queryX1dyn.ur apparently has result type:

  transaction xml

This might be a problem (and it might actually be the cause of the compile
error reproduced below), but I'm unsure whether (or how) to change this.

(2) The Batch demo involves a <button> with an `onclick` event and the
Increment demo also involves a <button> with an `onclick` event.

The present example queryX1dyn is different in two ways:

(a) Instead of having a <button> on the page, it has a <ctextbox
source={theFilterSource}/>, which receives the user's input, thus
automatically changing `theFilterSource`.

(b) The `onclick` event in the Increment and Batch demos also *writes* some
data on the server (batch-inserting records, or incrementing a sequence,
respectively).

But the present project queryX1dyn does not *write* any data on the server:
it merely *reads* some data from the server.

(Of course, even though the demos do a "write" while the present project
merely does a "read", both the "read" and the "write" are still
transactional, since they both involve accessing the database on the
server.)

Therefore, it makes sense that:

- the `onclick` event of the <button> in the Batch demo, and

- the `onclick` event of the <button> in the Increment demo

would both be somewhat "longer", involving an initial `rpc` call (to write
the data on the server), lacking in the present project.

Summarizing, there are two differences between the present example
queryX1dyn and the Batch and Increment demos:

- the <ctextbox> does not have an `on_` event (since, as the previous
minimal example `urweb-ctextbox-echo` demonstrates, in the case of a
<ctextbox> the source updates the signal automatically, with no need for,
eg, an `onkeyup` event); and

  https://github.com/StefanScott/urweb-ctextbox-echo

- the <ctextbox> in the present example does not perform an `rpc` call
(since I believe this is unnecessary, because data is only read from the
server-side, not written to the server-side).

Compile error message `Have: xml` vs `Need: transaction`:

The complete compile error message is reproduced here:

$ urweb -dbms postgres -db "host=localhost port=5432 user=scott
password='pw' dbname=queryx1_dyn" queryX1dyn

queryX1dyn.ur:27:13: (to 33:8) Error in final record unification

Can't unify record constructors

   Have:

[Signal =
  signal (xml ([Dyn = (), Body = (), MakeForm = ()]) ([]) ([]))]

   Need:

<UNIF:U284::{Type}> ++
 [Signal =
   signal
    (transaction
      (xml (([Body = ()]) ++ <UNIF:U86::{Unit}>) <UNIF:O::{Type}>
        ([])))]

  Field:  #Signal

Value 1:

signal (xml ([Dyn = (), Body = (), MakeForm = ()]) ([]) ([]))

Value 2:

signal
 (transaction
   (xml (([Body = ()]) ++ <UNIF:U86::{Unit}>) <UNIF:O::{Type}> ([])))

Incompatible constructors

Have:  xml ([Dyn = (), Body = (), MakeForm = ()]) ([])

Need:  transaction

$

Possible cause(s) of error:

(1) Expected types in various contexts? (more likely)

We can see that there is a record unification error involving incompatible
constructors `Have: xml` vs `Need: transaction`.

This apparently involves the signal attribute of the <dyn> tag - which
means it might also involve:

- what is expected by the <dyn signal={...}> tag containing this function
call; and/or

- what is expected by the "parent" <xml> tag containing the <dyn> tag;
and/or

- what is expected by the <xml><body> tag in the main function where this
value is used; and/or

- some possible (general, universal) Ur/Web restriction on the result type
of the code used in a <dyn signal={...}> tag.

(2) Need to perform an `rpc` call? (less likely)

Because the present project is closely modeled on the Ur/Web Increment and
Batch demos, I am fairly sure that the connection between the source and
the signal has been established correctly.

However, I am not completely sure about this, since there are a couple of
differences between the present project and those demos:

(a) The demos involve a <button> with an `onclick` event, while the present
project involves a <ctextbox> with no event.

However, I believe that in the case of a <ctextbox> having a `source`
attribute, no `on_` event is necessary - as apparently demonstrated by the
very minimal (and correctly working) Ur/Web FRP example urweb-ctextbox-echo.

  https://github.com/StefanScott/urweb-ctextbox-echo

(b) The `onclick` event in the demos also performs an `rpc` call, while the
present project does not.

However, I believe that no `rpc` call is necessary in the present project,
because this project only *reads* data from the server, while the demos
*write* data on the server.

Again, I am not completely certain that no `rpc` call is needed in the
present project - because although this project does not perform a
(transactional) "write" on the server, it does perform a (transactional)
"read" on the server.

(3) Likely cause of error:

It seems more likely that the error has a simpler cause - not involving
some mis-connection in the "wiring" between the source and the signal, but
instead involving:

- (most likely, since the compile error complains about lines 27-33 of
queryX1dyn.ur) a conflict between the type of the value `return ( showRows'
aFilterSignal )` versus what the <dyn> tag in function `showRows` expects
(or what some "parent" <xml> fragment within that same function expects); or

https://github.com/StefanScott/urweb-queryX1-dyn/blob/master/queryX1dyn.ur#L27-L33

- (less likely, because the compile error doesn't mention these lines?)
possibly some incompatibility between `{showRows theFilterSource}` and what
the <xml> in the `main` function expects.

Thanks for any help getting this to work!

###
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150816/aaae9692/attachment-0001.html>