On Mon, Dec 16, 2013 at 6:08 PM, Diego Lont <diego.lont@delware.nl> wrote:
Linking goes on Id. So you only need to put in the correct id, and it will work.Yes, i know, but same problem. How do I know the ID of a component that will be rendered later?Do we assume all components will use #labelId for setting internally the ID to whatever tag they use?So with childAt: I can get all components (even those not yet rendered) and ask for #labelId expecting that will be the real used ID?Because passing the id as an argument to renderContentOn: html ajaxScript: and friends would imply some changes....Hi Mariano,I would simply create a local dictionary where I link all description to a "ajaxId". I render a div around each element with the ajaxId, and each time I need an id for a description I do a lookup in this dictionary. If absent --> create new id.
Cheers,Diego
_______________________________________________Thoughts?Thanks!On Dec 16, 2013, at 9:30 PM, Mariano Martinez Peck wrote:_______________________________________________
On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <diego.lont@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--
Mariano
http://marianopeck.wordpress.com
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki--
Mariano
http://marianopeck.wordpress.com
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki