In your example: state should be re-rendered if country is changed but not the other way around. 

Actually, I don't really care if the country is re-render. I mean...it's not thaaaaaat bad. At least we are not refreshing the whole form. It's just a few fields. 
I think the easiest path is that all elements of the group is re-rendered. Future usecase could allow what you suggest here (like country not updating if I change state), but that could be a second step of improvement if complicates stuff...
 
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.

 
Sounds good. 
 
Second pass:
Render the descriptions and add for all influences a script to update the influenced values.**

Ok..but just to see if I understand... this is all about re-render right? Then, at a separate layer we have the #addInfluence:for: to modify the value of the stuff before re-rendering. Right? 
What I mean is...I can re-render the influenced values but maybe they do not do a  #addInfluence:for: (yet they are re-rendered). 
 
** 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.


Indeed. There is not way to know where the render comes from? if it come because of the ajax or a normal one? hehehe  Anyway, yes, we could probably find a way to solve the loop, even if it is a bit dirty ;) 

 
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.


Thanks for the good energy! That would be appreciated. 

Hi Mariano,

I gave it a go and try to implement it, but I forgot that it is hard to replace a part of a table. I can replace the entire table, or table cell contents, but not table rows.  In my manual test it worked to add multiple: 'onChange:' scripts, but when I build it into the TableRenderer, this failed due to this problem. That is an issue with JQuery.

I do not have the time at the moment to make an entirely new renderer, but I added the infrastructure to the QC-Magritte-Ajax. Maybe you can add your renderer to QC-Magritte-Ajax? It would be perfect if you add an example too in QC-Magritte-Demo.
All you have to do is add an array of scripts that need to be re-rendered, instead of a single re-render script to the call. And call: "renderContentOn: html ajaxScripts: aList" instead of "renderContentOn: html ajaxScript: aScript"

Finally note that this could generate a lot of scripts, and that this could be a problem for performance. It is possible to generate parametrized scripts and use those to limit the number of scripts, but I have no experience in doing so (and so far no need, as I solved this by re-rendering the group).

Let me know if it works out!

Cheers,
Diego