BorisMoore
commented
9 years ago To be honest, that seems a strange approach. You are dynamically updating the onchange property of the input, and having two handlers for the onChange event - the DOM level 0 handler that you are setting (UpdateTenantUserAccess) and the data-link="{:ManageForms trigger=true:} handler.
You are attaching two separate listeners to the onChange event, so you will need to control sequencing between those two event handlers. Which of them is 'in charge'. In what order will they fire?
I would try to avoid DOM level 0 handlers and only have one onChange hander. You can use convert and convertback handlers: data-link="{cvt:ManageForms trigger=true:cvtBack}" - so the UpdateTenantUserAccess code could probably go into a cvtBack converter.
Alternatively, rather than using cvtBack, you can simply drive your UpdateTenantUserAccess using $.observe() or $.observeAll() event listener to listen to relevant data changes, including ManageForms property, and calling your Update... code. It is generally cleaner to have UI update data, and data then drive UI and application state etc...
markibanez
Hi @BorisMoore,
I had a weird issue using a datalinked checkbox. Here's my HTML
<label class="user-access"><input type="checkbox" data-link="{:ManageForms trigger=true:} disabled{:IsOwner} onchange{:'UpdateTenantUserAccess(' + TenantID + ',' + UserID + ')'}" /> Manage Forms</label>So what happened was the UpdateTenantUserAccess function was picking up the old value of the property ManageForms bound to the checkbox. I had to enclose my code in a setTimeout to allow the datalink to "catch up" and get the proper value.
While enclosing code in a setTimeout isn't a hassle, I just feels hacky and inelegant. Am I doing something wrong here? Is there a way to fix this without using setTimeout?