On Fri, Dec 13, 2013 at 2:46 PM, Diego Lont <diego.lont(a)delware.nl> wrote:
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?
Not always ...
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.
OK
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.
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.
but what would you put in each description otherwise? #influencedBy: ,
#influencesTo: ?
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
--
Mariano
http://marianopeck.wordpress.com