recalculation model for GUIs

Question

I often come across this problem.
Say to have a form with some controls:

A
B
C = A + B
D 
E = C * 2 ONLY IF D==TRUE
F
G = A - F

The user fills A, then B.
The system calculates C.
The user fills D (boolean)
The system calcluates E
The user fills F
The system calculates G

But now:
The user clears A
The system clears C, E and G
The user clears B
The system does nothing
The user inserts A
The system recalculates only F
And so on and on.

There clearly is a tree of dependences, and that's not difficult to understand. But pragmatically i found quite difficult implement it without any 'framework' to model it.
Be them inputs in a HTML form or controls in a javafx application, the problem of creating a comprehensive 'recalculation' algorithm still remains.
(Javafx offers a 'binding' architecture that despite being a bit verbose, yet is very powerfull and addresses (part of) this specific issue.) But i'm more interested in a methodology that can be used across the different platforms. I use to use a bunch of tecniques to solve the issues that come across but not yet a methodology, that is a way to go from the definition to the implementation with the minimum amount of trials.
The tecniques are the good old: invalidations, lazy init, wrapping each control in a 'node' of a recalc-graph.
But i feel that there should be a more canonical approach to this recurrent problem, and a paper where this approach is explained and so on. Can anyone suggest me where can i find such information?

EDIT 1: terms of the problem

• One of the key goals of such a solution is to have a way to organize the code in a predictable way, so that, knowing the method, it should be easy to evaluate its correctness.
• Initial state: many system fail to return to their initial state, that's the smell of a poor design that such methodology should prevent
• It should be designed for real cases such as (hitting back to the example): when the user changes A, the system should clear B in the case in which they were coupled. It's easy to think of such cases: a user selects a contry and the system provides a list of regions for the user to choose one. If the user changes the city, the region previously chosen has to be cleared even if it's not strictly a dependent field since it's not calculated by the system.

As an example of a very partial solution:

1. Each control should have a backing 'update' method that should trigger only update of 'directly connected' controls. This hypothesis should guarantee that when C is based on A, A is always up-to-date.

   function update_A() { update_C; }

   function update_B() { update_C; }

   function update_C() { C.setValue(A + B); update_E(); }

   etc. etc.

2. since there mustn't be circular references, these update function should form a 'tree'.

Other contributes to come.

Answer 1

Assuming the amount of recalculation is trivial, then some kind of Model-View-Controller structure would be appropriate:

1. The user changes B
2. The View notifies the Controller (via event, etc.) that B changed (or that something changed) and the Controller passes B (or everything editable) to the Model.
3. The Model updates internal values and exposes the values for G, etc.
4. The Controller copies the result values from the Model to the View.

That way, the dependency only exists in the Model. The View is very dumb, and the Controller knows which fields are read/write and which are read-only, but knows nothing of interdependencies.

Edit:

I want to make a point of clarifying the term "Model". There are typically more than one layer of Model in a program, even though we always just talk about "The Model". In the case of a client application talking to a remote server, there is typically a Server Model and a Client Model. If the client is a web browser then the Client Model might be written in JavaScript and the Server Model could be in any server-side language like C#, PHP, etc.

There's a natural question which arises: "Does this recalculation logic belong in the Client Model, the Server Model, or both?" Since you can't trust the client, you're really forced to always implement the recalculation in the Server Model, and optionally implement it in the Client Model if you want to prevent unnecessary round-trips to the server. Unfortunately this can end up violating the once-and-only-once principle, unless you're lucky enough to be working in a language/framework that allows you to re-use certain modules and logic in both the server and client side (Node.js?)

Answer 2

The tecniques are the good old: invalidations, lazy init, wrapping each control in a 'node' of a recalc-graph. But i feel that there should be a more canonical approach to this recurrent problem, and a paper where this approach is explained and so on. Can anyone suggest me where can i find such information?

I believe the canonical approach would be the state pattern.

Have a look at http://gameprogrammingpatterns.com/state.html, for instance.

Obviously it's not associated with game programming specifically, I just happen to like this particular explanation.

Especially suiting is the hierarchical state machine, where there is more interdependency between states.

Another resource, focused on hierarchical state machine specifically: http://www.eventhelix.com/realtimemantra/hierarchicalstatemachine.htm#.VCm9nPmSzOg

Each state knows what happens when it's switched on, what should happen when it's switched off. It can trigger other states, possibly causing a cascade of updates. This can allow for flexible and maintainable APis.

Take a look at this project, for example - written in my favorite programming language (C#): https://github.com/nblumhardt/stateless (I'm in no way associated with the project or its authors).

I don't mean the code, but the samples. They are clear and instructive, and so they can already serve as a good indication on how to implement the thing:

var phoneCall = new StateMachine<State, Trigger>(State.OffHook);

phoneCall.Configure(State.OffHook)
    .Permit(Trigger.CallDialed, State.Ringing);

phoneCall.Configure(State.Ringing)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.CallConnected, State.Connected);

phoneCall.Configure(State.Connected)
    .OnEntry(() => StartCallTimer())
    .OnExit(() => StopCallTimer())
    .Permit(Trigger.LeftMessage, State.OffHook)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PlacedOnHold, State.OnHold);

// ...

phoneCall.Fire(Trigger.CallDialled);
Assert.AreEqual(State.Ringing, phoneCall.State);

// ...

phoneCall.Configure(State.OnHold)
    .SubstateOf(State.Connected)
    .Permit(Trigger.TakenOffHold, State.Connected)
    .Permit(Trigger.HungUp, State.OffHook)
    .Permit(Trigger.PhoneHurledAgainstWall, State.PhoneDestroyed);

Neat, huh?

Answer 3

Well, why not start with a very simple approach? You have "level 0" fields where the user can enter values, "level 1" fields which only depend on "level 0" field, "level 2" fields depending on "level 1" or "level 0" fields, and so on. Behind each "level n" field with n>0 there is a function which takes care of incomplete input values (like C = f(A,B) with f(A,B) = A+B if A and B are numeric, and "no value" if not.

Now, whenever a "level 0" field is changed by a user, recalculate everything, and do this in the order of increasing levels 1, 2 3, ... and so on.

This is probably not the most efficient solution, but in a lot of real-world cases it is just efficient enough. It is the approach you should start with, and only if it turns out to be not fast enough, you should try to implement something more sophisticated. Otherwise you risk to run into the "premature optimization" trap.