mavo icon indicating copy to clipboard operation
mavo copied to clipboard

mv-mode="read" on Mavo root prevents the app from ever entering edit mode

Open sundaywork opened this issue 6 years ago • 5 comments

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>"

sundaywork avatar May 27 '18 04:05 sundaywork

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.

LeaVerou avatar May 27 '18 04:05 LeaVerou

ok

sundaywork avatar May 27 '18 09:05 sundaywork

Why did you close this?

LeaVerou avatar May 29 '18 08:05 LeaVerou

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.

sundaywork avatar May 29 '18 11:05 sundaywork

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.

LeaVerou avatar May 29 '18 15:05 LeaVerou