How to model a text input field in RDP?

[Manuel Simoni]

I'm trying to model an interactive text input field.

The best approach I can come up with is this:

- The text field receives the current text in its input signal from an upstream behavior reading a storage resource.

- The text field's output signal initially is just a copy/passthrough of the input signal.

- When the user types a new character, the output signal changes to the new, tentative text contents. (Let's ignore cursor and keyboard for now.)

- The behavior downstream of the text field sees the new text contents and writes it to the store.

- The text field's input signal (read from the store) now changes to the new text, so the display gets updated, and we're done.

I don't really like this approach. I doesn't feel declarative to me. Also, what happens if an error occurs and the new text can't be written to the store?

I'd be glad for some insights into this, also how the (still mysterious to me) Kahn Process Networks could address something like that.

Best regards,

Manuel

[David Barbour]

A text field will be associated with a stateful resource in the environment. 

You described this resource as "the store" and a behavior as "writing to the store". The latter concept is very imperative in nature, which is something we'd prefer to avoid. Hence, for RDP, we want a more declarative notion for stateful resources. I spent a lot of time exploring declarative state models circa 2011, and I described state as stable (depends only on current demands and prior state) or animated (state may update over time even if demands are constant).

Very Roughly: 

      type StableStateRsc d s = {d} → s → s

      type AnimatedStateRsc dt d s = {d} → s → (dt → s)

Here `{d}` represents a (commutative, idempotent) set of demand values of type `d` to influence state, while `s` is the current state, and `dt` represents some form of delta-time from computation of the current state.  A state resource would typically be associated with a pure observer behavior that does not affect the current state but returns it. Naturally, we could use more specialized state resource models for performance reasons. Continuous time models are rather difficult and inefficient to work with, after all.

For a text field, stable state resources are sufficient. So we need to consider the influence demand type `d`. One option is `Write string`, of course, but we could support multi-user text fields by instead working in terms of rewrite diffs/patches. It turns out that having demands model a set of term-rewrite rules while state is a term is a pretty good fit for reactive, declarative state resources in general [1].

Anyhow, we'd fill the text field based on observing the state resource. Then we continuously compare the edited text to the stored text in the resource. When they are different, we provide an appropriate demand on the resource to update its text. Potentially, that demand may result in error (e.g. due to concurrent edits or form validation) in which case we must add feedback to the UI. At least, that's one way of approaching text fields.

KPNs would take a much more conventional approach. The text field could just be one input channel to the process network. Whenever we update the text field, we add the appropriate message to the KPN then compute the KPN's next state including any outputs. (If KPNs are mysterious to you, it's useful to think of them as Flow-based Programming [2] restricting merging of wires and hence race conditions.)

Warm Regards,

Dave

[1] https://awelonblue.wordpress.com/2011/12/02/animated-reactive-term-rewriting/

[2] https://en.wikipedia.org/wiki/Flow-based_programming

[Manuel Simoni]

Anyhow, we'd fill the text field based on observing the state resource. Then we continuously compare the edited text to the stored text in the resource. When they are different, we provide an appropriate demand on the resource to update its text. Potentially, that demand may result in error (e.g. due to concurrent edits or form validation) in which case we must add feedback to the UI. At least, that's one way of approaching text fields.

The way I understand it, that's exactly the approach I outlined, correct?

As usual, my thinking really started after posting to the internet. Here's another approach, which should tie in quite well with a command-based undo model.

Instead of directly outputting the new value of the resource, the text field behavior outputs a kind of write request or command object on its output signal. This request should have a UUID.

If the downstream behavior accepts the request, it updates the resource. It could also add the command to the undo list.

How does the text field learn about whether its requests were accepted? Its input signal is a product signal (text-from-resource, request-channel). The text-from-resource are the contents of the storage resource. The request channel is usually inactive, except when a write request has been accepted by the downstream. Then it contains a confirmation, that also lists the write request's UUID, so the text field can correlate it with the outstanding write request, and go back to accepting keyboard input.

Is this still RDP, or am I stretching things to far? I definitely need to think more about how the pieces fit together.