PythonEditor icon indicating copy to clipboard operation
PythonEditor copied to clipboard

Moving between versions should preserve contents of buffer

Open jaustin opened this issue 8 years ago • 3 comments

Since 0.1.0 we've been able to move between different versions of the editor. Hooray!

However, currently the contents of the script buffer (IE the users' code) gets lost between this version migration. In the case that the user entered with a script in the URL we will preserve that script but not any subsequent changes.

I believe the following rule is good:

Whenever moving between editor versions, put the buffer contents into the URL bar so that the script migrates between versions

Implementation-wise there are a few privacy gotchas - If we put their script in the URL bar then it can/could end up in server logs. If we put it in a cookie we have to mention that we will use cookies in privacy policy.

jaustin avatar Feb 15 '17 17:02 jaustin

@jaustin asked me 'are you agreed with our assertion that the script buffer contents should always migrate?'

Yes.

  1. PXT does this already between pxt and pxt/beta, which is really useful when testing if something is fixed in beta or not (and beta is just another 'version', right?). I use this all the time. If I tell our users to try it in Beta, they don't want to fumble with cut and paste, save and load, etc.

  2. It would be good to have common (UX) experiences like this across all editors, so as people move between different languages they have a minimum set of expectations that will work the same way.

The only use case I worry about is two browser windows open to the same language editor, 'possibly with different versions' - if you are building a multi-noded system (like tone matrix) it's great to have the bridge bit in one tab, and the IO bit in another tab, independently editing them. If there is a new feature that you want on one of the bits, you might want multiple tabs open with different active versions. I'm sure that will work too?

whaleygeek avatar Feb 15 '17 17:02 whaleygeek

@ntoll have you thought much about how to implement? Seems like browser-local storage is perfect for the script - how does that approach sound?

jaustin avatar Feb 27 '17 10:02 jaustin

Two things:

  1. Since this is being served by a CDN, where are your server logs? If there are none (or you switch them off) then this problem goes away and we can use the extraordinarily simple solution of preserving the script as an argument in the URL. This is by far the best solution because it is simple and addresses @whaleygeek's concerns about multiple tabs.

  2. Assuming the worst, and you are unable to switch of server logs, local storage is probably the way to go and should take me about a day to build (the easy bit) and test.

To be clear, turning off server logs for the CDN (and might I add, I've used pretty much the same CDN setup you have with other projects and never seen any server logs - so I assume they are switched off), and using the URL is the best way forward by a long shot.

I would very strongly recommend the zero server log route for two reasons: we're probably not logging anyway (and if we are you can just turn them off for the Python related subdomain), we're adding complexity to an application and this is a bad thing to do. Let's keep it simple. Let's keep it understandable (note how we want beginner programmers to see how the thing all works). Let's solve this problem by biting the configuration of logs bullet rather than create potentially harmful technical debt.

ntoll avatar Feb 27 '17 12:02 ntoll