2) I don't want to have to display some fields together in order to have them been re-rendered when one of them has been modified. 

That implies adding multiple updates, so multiple scripts to the same input.

Yes. Each element of the group has multiple scripts (one for each other of the group), right?

So instead of adding a "script: aScript" parameter, we probably should have a variant that adds a "scripts: aCollection" parameter. I am not sure how the implementation should look like exactly. You can try simply adding all scripts.

What if:

- We store the container (as you did with the AjaxTable..)

- to the container we ask the "dependencyGroups" (I pick this name for this mail).

- We create a script for each element of each dependencyGroup. 

- To each element of each dependencyGroup we set all the scripts of that group.

I do not think we should keep the implementation symmetric. As this implementation will create rendering loops for sure.

In your example: state should be re-rendered if country is changed but not the other way around. But when I think further on it: we can already determine what fields should be re-rendered. A description is based on several other descriptions. (influences and dynamic options). As long as this is a tree the implementation should be easy enough. You process the description twice:

First pass:

Each description that is influenced by one or more other values gets an id.*

Each description that influences one or more other values gets a list of description that it influences.*

* Here we can use that a description is the same if type and accessor are the same. I used this as well in the influences.

Second pass:

Render the descriptions and add for all influences a script to update the influenced values.**

** Of course this will fail if we have a loop. I.e.: First name, Sir name, Full name --> all three are connected and then we have to think something how to avoid a re-render loop.

I will try to find time to make a basic implementation on Monday, but I do not promise anything. It is nice that other people try to use my stuff, so we can improve on it.

 

3) I am not obligued to use #group: I can use something different, like #dependentsGroups or something like that

Point taken. I misused group here. I probably should have introduced another term. Do you have a good suggestion? I do not think we should couple this to group.

#dependenciesGroup: ? 

#notificationGroup:

#updaterGroup:

same of above but using the word "set" instead of group (to avoid any confusion with Magritte groups). Like "dependenciesSet" 

I think I like updaterSet the most … but maybe we can do without a property, as it is always refers to calculated fields.