On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont(a)delware.nl> wrote:
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!
Hi Diego,
Thanks for taking the time for giving it a try, this is very much
appreciated! I am trying to make it work, but I have a basic question.
Say I have my rendered, where I implement #basicRenderControl: to hook
there and make the scripts.... Say I have 2 related/influenced
descriptions. Problem is that at the time of the #basicRenderControl: the
related/influenced descriptions may have not yet been rendered yet since
they could be later (and hence I don't know anything, like the ID). But I
need to generate the scripts at this point, so that I can put it in the
onChange:
mmmm do you understand what I mean? I am not sure I am being clear.
Thanks,
Cheers,
Diego
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki