mavo
mavo copied to clipboard
mv-mode="read" on Mavo root prevents the app from ever entering edit mode
When in the source code mv-mode is set to "read", the attempt to make it enter edit mode will fail, even the element has seen the attribute being changed.
<script>
function test(){
Mavo.all[0].edit();
Mavo.all[1].edit();
Mavo.all[0].element.setAttribute("mv-mode","edit");
console.log(Mavo.all[0].element);
Mavo.all[0].edit();
}
</script>
<div mv-app="app1" mv-storage="local" mv-mode="read" mv-autosave="0" >
<h1 property="title" >My Services</h1>
<p property="description" >some text.</p>
</div>
<div mv-storage="local" mv-app="app2" id="decisions" >
<h1 property="title" >My Services</h1>
<p property="description" >some text.</p>
</div>
call test() to try to set the apps into edit mode, app1 will fail while app2 is editable. The log shows the mv-mode in element has been set to edit
"<div mv-app='app1' mv-storage='local' mv-mode='edit' mv-autosave='0' typeof='Item' mv-permissions='read save edit add delete' style=''><div class='mv-bar mv-ui'><!--mv-status--><button type='button' class='mv-edit'>Edit</button><!--mv-save--><!--mv-login--><!--mv-logout--></div>
<h1 property='title' aria-label='Title' mv-attribute='none'>secret</h1>
<p property='description' aria-label='Description' mv-attribute='none'>some text.</p>
</div>"
The reason this is happening:
mv-mode
is handled the same for descendant properties and for the Mavo root. This behavior makes more sense when you think about it for descendant properties: You often want to have uneditable (read-only) properties that are saved but not edited. So you slap mv-mode="read"
on to them and the surrounding edit mode does not affect them. However, when mv-mode="read"
is used on the root, then it becomes impossible to enter edit mode, ever.
One could argue that this problem would never arise without JS (since the Edit button in the toolbar disappears in that case), but it's yet another case proving that mv-mode
is a terrible idea and we need to find a different syntax for what it's doing.
ok
Why did you close this?
I thought you said this is by design to lockdown the values in case it does not allow edit. By removing the tag the problem goes away. This is reasonable already if it is documented.
I was explaining why this happens in case someone other than me decides to work on it. I wasn't saying the behavior is justified. That's why I added the bug label.