Let **act(p0, ... ,p(n-1))** be an action with n parameters.

Let **PPM(p0, ... ,p(n-1))** be the pending-parameter-model that is negotiated with the interacting user by means of an action dialog in the UI. Through user interaction the **PPM** is filled with parameter values until all constraints are met and the action **act** can thus be invoked.

We can identify the parameter list **PL {p0, ... ,p(n-1)}** as (typed) n-tuple, with types** t0, ... ,t(n-1)**

The programming model provides 5 types of functions in support of the pending-parameter-model. For the sake of simplicity we say that each is a function** PL -> ti**, with **ti** being the type of the i-th parameter. For example given **act(X x, Y y)**, we have **default0Act(X x, Y y) -> X** and **default1Act(X x, Y y) -> Y**

**default**_{i}**autoComplete**_{i}**choices**_{i}**disable**_{i}**hide**_{i}

Now going through the negotiation process,

- let **p[i]** be the value of the i-th parameter of the PPM, and let PL be the parameter list {p[0], .. ,p[n-1]}

- let **v[i]** be the visibility flag of the i-th parameter (whether is rendered at all in the UI)

- let **u[i]** be the usability flag of the i-th parameter (whether can edit vs. being rendered read-only)

- let **invalid[i]** be the invalid message of the i-th parameter (only rendered when set)

1) Fill in **defaults** in two passes:

for i in 0..n-1 p[i]:= default_i() // no arg, init PL // fixed point search for PL, run this outer loop until PL does not change any more for each permutation perm of {0..n-1} for i in perm // <== perm dictates the order in which the indices are processed p[i]:= default_i(PL) if none of the p[i] had changed, then // we found a fixed point goto(2) render invocation veto message "Cannot find an initial fixed point for action parameter defaults."

2) Process **visibility** and **usability** (disable/hide)

for i in 0..n-1 v[i]:= not hide_i(PL) u[i]:= not disable_i(PL)

3) Process individual parameter **validity**

// skip this step until (5) has been reached at least once! if step_5 was reached, then for i in 0..n-1 invalid[i]:= validate_i(PL)

4) Wait for user interaction,

- let reset_i be a user initiated reset request for the i-th parameter

- let update_i be a user initiated update for the i-th parameter, either triggered by direct entering of a value or using **autoComplete** or **choices**

on reset_i: p[i]:= default_i(PL) on update_i: p[i]:= the proposed new value as given by the update event on user initiates the action invocation goto (5) // process parameter-list validity goto (2) // start over

5) Process parameter-list validity

if validate(PL) is not empty, then render invocation veto message goto (4) // wait for user interaction

6) Invoke the action

act(PL)

## 1 Comment

## Andi Huber

Fixed point search in step 1 above is only successful if there is a dependency relation for the default providing methods such that these can never depend on pending-parameters with higher index than the index they are mapping to. It seems for the general case (not knowing the dependency relation) the search algorithm would become more computational intensive, it would need to run the simple algorithm above for each permutation of the PL tuple until it finds a fixed point.