Adding to Magritte

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.

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.

Diego

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

 

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

_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki

On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <[hidden email]> 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

Linking goes on Id. So you only need to put in the correct id, and it will work.

On Dec 16, 2013, at 9:30 PM, Mariano Martinez Peck wrote:

On Mon, Dec 16, 2013 at 7:40 AM, Diego Lont <[hidden email]> 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

On Mon, Dec 16, 2013 at 6:08 PM, Diego Lont <[hidden email]> 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 <[hidden email]> 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