Discussion:
[Ur] Forms that call rpc instead of redirect
Aistis Raulinaitis
2018-02-11 21:10:01 UTC
Permalink
The form mechanism is excellent, with the built in type checking, but the
submit action function returns a page: state -> transaction page.

Is there such a thing such as a version of forms that has a submit action
function with a type of: state -> transaction unit.

This is so I can call rpc functions there in the submit action and then the
current page is updated using responses over a channel from the server.
Adam Chlipala
2018-02-11 21:20:37 UTC
Permalink
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then
choose RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but
the submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit
action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and
then the current page is updated using responses over a channel from
the server.
Aistis Raulinaitis
2018-02-11 22:03:42 UTC
Permalink
Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.

The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.

Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority of
your forms to be of this style. Which I am.
Post by Adam Chlipala
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then choose
RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but the
submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit action
function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and then
the current page is updated using responses over a channel from the server.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Aistis Raulinaitis
2018-02-12 00:04:20 UTC
Permalink
The impetus for this style is that I am writing a card game with urweb and
I would rather not redirect back to the game view page for each form the
user must submit.
Post by Aistis Raulinaitis
Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.
The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.
Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority
of your forms to be of this style. Which I am.
Post by Adam Chlipala
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then choose
RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but
the submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit
action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and then
the current page is updated using responses over a channel from the server.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Adam Chlipala
2018-02-12 00:09:17 UTC
Permalink
I'm not sure what to suggest.  No, there is no existing feature like
what you suggest.  I have found it quite pleasant to work with sources
and widgets connected to them.  And it is even better to use
higher-level abstractions like in UPO <http://upo.csail.mit.edu/>
(itself likely not applicable to your card game).
Post by Aistis Raulinaitis
Yes I did get a little demo working with ctextbox, cchecbox, and the
like. However the result is much more verbose and more likely to have
runtime errors over a regular form.
The way that a form will pack all of its contents into a stuct is a
clear advantage over the source based route. It requires defining
possibly many sources and wiring them all into the right slots, having
to call "get" on each one of them in the onclick handler and then wire
all the gotten values into the handler.
Losing the form submit struct typing mechanism and the added verbosity
of all the sources would be very painful if you are expecting the
majority of your forms to be of this style. Which I am.
I think that kind of form has gone out of style, and I personally
almost always use the Ur/Web tags like <ctextbox> to collect data
and then choose RPCs programmatically.
The form mechanism is excellent, with the built in type
checking, but the submit action function returns a page: state
-> transaction page.
Is there such a thing such as a version of forms that has a
submit action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action
and then the current page is updated using responses over a
channel from the server.
Aistis Raulinaitis
2018-02-12 00:13:17 UTC
Permalink
Right. I have considered spending more time looking over UPO! The auth
system looks very interesting and relevant, I'm still working on wrapping
my head around it.

Any pointers to get me started on the right path when it comes to a more
effective usage of source based forms?
I'm not sure what to suggest. No, there is no existing feature like what
you suggest. I have found it quite pleasant to work with sources and
widgets connected to them. And it is even better to use higher-level
abstractions like in UPO <http://upo.csail.mit.edu/> (itself likely not
applicable to your card game).
Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.
The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.
Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority
of your forms to be of this style. Which I am.
Post by Adam Chlipala
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then choose
RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but
the submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit
action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and then
the current page is updated using responses over a channel from the server.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Adam Chlipala
2018-02-12 00:16:09 UTC
Permalink
Maybe just stop worrying about it, so that you might find that problems
don't arise in practice? >:)
Post by Aistis Raulinaitis
Any pointers to get me started on the right path when it comes to a
more effective usage of source based forms?
I'm not sure what to suggest.  No, there is no existing feature
like what you suggest.  I have found it quite pleasant to work
with sources and widgets connected to them.
Post by Aistis Raulinaitis
The way that a form will pack all of its contents into a stuct is
a clear advantage over the source based route. It requires
defining possibly many sources and wiring them all into the right
slots, having to call "get" on each one of them in the onclick
handler and then wire all the gotten values into the handler.
Aistis Raulinaitis
2018-02-12 00:24:08 UTC
Permalink
Well I'm hoping to be able find some kind of happy middle between spurious
reloads and verbosity of form definition.

I'm fine with implementing a few abstractions myself, I'm just not sure
what the correct direction is.

Your widget system based on ML modules and functors is very interesting I'm
just wondering how it would be possible to achieve what I'm attempting to
do with as little friction as possible.
Post by Adam Chlipala
Maybe just stop worrying about it, so that you might find that problems
don't arise in practice? >:)
Any pointers to get me started on the right path when it comes to a more
effective usage of source based forms?
I'm not sure what to suggest. No, there is no existing feature like what
you suggest. I have found it quite pleasant to work with sources and
widgets connected to them.
The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Ziv Scully
2018-02-12 02:45:10 UTC
Permalink
You seem to have the right idea: you can indeed implement your own library
of "rpc forms". Try filling in this signature (that is, .urs file):

con rpcForm : {Type} -> Type

val create : fields ::: {Type} -> $fields -> transaction (rpcForm fields)

val textbox :
others ::: {Type} -> nm :: Name -> [[nm] ~ others] =>
rpcForm ([nm = string] ++ others) -> xbody

val submit :
fields ::: {Type} -> result ::: Type ->
rpcForm fields -> ($fields -> transaction result) -> transaction result

Here's an example usage:

val handle : {Name : string, FavColor : string} -> transaction unit =
(* something with rpc... *)

val formExample : transaction page =
fm <- create {Nm = "", FavColor = ""};
return <xml>
Your name: {textbox [Nm] fm}<br/>
Your favorite color: {textbox [FavColor] fm}<br/>
<button onclick={fn _ => submit fm handle}>Submit</button>
</xml>

And here's a start to the implementation (that is, .ur file):

con rpcForm fields =
$(map (fn t => {Source : source t, Default : t}) fields)

Once you have this working, you probably want to implement analogues of
textbox for other types. To be clear, I just came up with this off the top
of my head, so you will probably have to change some things.

Good luck!
Ziv
Post by Aistis Raulinaitis
Well I'm hoping to be able find some kind of happy middle between spurious
reloads and verbosity of form definition.
I'm fine with implementing a few abstractions myself, I'm just not sure
what the correct direction is.
Your widget system based on ML modules and functors is very interesting
I'm just wondering how it would be possible to achieve what I'm attempting
to do with as little friction as possible.
Post by Adam Chlipala
Maybe just stop worrying about it, so that you might find that problems
don't arise in practice? >:)
Any pointers to get me started on the right path when it comes to a more
effective usage of source based forms?
I'm not sure what to suggest. No, there is no existing feature like
what you suggest. I have found it quite pleasant to work with sources and
widgets connected to them.
The way that a form will pack all of its contents into a stuct is a
clear advantage over the source based route. It requires defining possibly
many sources and wiring them all into the right slots, having to call "get"
on each one of them in the onclick handler and then wire all the gotten
values into the handler.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
Artyom Shalkhakov
2018-02-12 05:31:04 UTC
Permalink
Hello Aistis,
Post by Aistis Raulinaitis
Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.
The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.
FWIW, you can define something like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#L163

and then use it like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#L192

And it's not too bad.
Post by Aistis Raulinaitis
Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority
of your forms to be of this style. Which I am.
Post by Adam Chlipala
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then choose
RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but
the submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit
action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and then
the current page is updated using responses over a channel from the server.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
--
Cheers,
Artyom Shalkhakov
Aistis Raulinaitis
2018-02-13 01:58:29 UTC
Permalink
Thank you Ziv and Yartom!

Ziv, I'll take some time to see if I can get your example working with what
I have. This would be nice to get working.

Yartom, your snapshot function looks very close to what I need. Monad.mapR
is a function I should probably start using more. Thanks!

On Feb 11, 2018 21:31, "Artyom Shalkhakov" <***@gmail.com>
wrote:

Hello Aistis,
Post by Aistis Raulinaitis
Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.
The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.
FWIW, you can define something like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L163

and then use it like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L192

And it's not too bad.
Post by Aistis Raulinaitis
Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority
of your forms to be of this style. Which I am.
Post by Adam Chlipala
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then choose
RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but
the submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit
action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and then
the current page is updated using responses over a channel from the server.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
--
Cheers,
Artyom Shalkhakov
Aistis Raulinaitis
2018-02-13 02:03:39 UTC
Permalink
Artyom. Not Yartom. I appologize. Thats what happens when you don't double
check your names!

On Feb 12, 2018 17:57, ***@gmail.com wrote:

Thank you Ziv and Yartom!

Ziv, I'll take some time to see if I can get your example working with what
I have. This would be nice to get working.

Yartom, your snapshot function looks very close to what I need. Monad.mapR
is a function I should probably start using more. Thanks!

On Feb 11, 2018 21:31, "Artyom Shalkhakov" <***@gmail.com>
wrote:

Hello Aistis,
Post by Aistis Raulinaitis
Yes I did get a little demo working with ctextbox, cchecbox, and the like.
However the result is much more verbose and more likely to have runtime
errors over a regular form.
The way that a form will pack all of its contents into a stuct is a clear
advantage over the source based route. It requires defining possibly many
sources and wiring them all into the right slots, having to call "get" on
each one of them in the onclick handler and then wire all the gotten values
into the handler.
FWIW, you can define something like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L163

and then use it like this:

https://github.com/ashalkhakov/urweb-projects/blob/master/meter/screens.ur#
L192

And it's not too bad.
Post by Aistis Raulinaitis
Losing the form submit struct typing mechanism and the added verbosity of
all the sources would be very painful if you are expecting the majority
of your forms to be of this style. Which I am.
Post by Adam Chlipala
I think that kind of form has gone out of style, and I personally almost
always use the Ur/Web tags like <ctextbox> to collect data and then choose
RPCs programmatically.
Post by Aistis Raulinaitis
The form mechanism is excellent, with the built in type checking, but
the submit action function returns a page: state -> transaction page.
Is there such a thing such as a version of forms that has a submit
action function with a type of: state -> transaction unit.
This is so I can call rpc functions there in the submit action and then
the current page is updated using responses over a channel from the server.
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
--
Cheers,
Artyom Shalkhakov
Loading...