IDE-like interface about relate HOT 5 OPEN

I think even with the sandbox this would still be pretty cumbersome. In addition, most of the things that you can do with Jinja would break in the setting, so it would still only solve half the problem. My plan for this is instead to allow pointing a course within a locally-running relate instance at a directory rather than a git repository. That way, changes can be immediately previewed right after the files are edited. This does not enforce validation, so there's some room for errors, but I think overall this is the most promising solution. What do you think?

from relate.

I think your idea is great, at least for me.
In fact, my original intention to raise this issue is to make it easier, although it is actually not easy :-), for my colleagues who wish to use my relate instance to develop their courses. Your idea is great, but that requires users to set up local developing env on their machines, which is not so realistic for my colleagues.

from relate.

Here is an alternative idea: we build an IDE -like interface with a file browser on the left and an editor on the right. (We have already got code mirror and jstree, so the parts are there.) This can be popped open in a separate browser window, and a user can then edit the site "live" in some sort of preview mode.

This would entirely remove the requirement for the user to have local development environment of any sort, and in addition it would allow relatively immediate feedback on edits.

There are a few things that are unclear to me about how to do this, but I feel like all this is resolvable:

• First, relate would need to start working as a more full-featured git endpoint, not just pulling changes from elsewhere, but also being able to serve a git tree so that changes made within relate can get out. It's actually easier than it sounds, because Dulwich can be made to do the hard work. As a matter of fact, they already have a Web server that would just need to be glued into Django, with some manner of authentication.
• Each save operation would likely generate an intermediate commit. I imagine that per user we would have to save their current "edit base commit", and all the edits on top of that would then become part of the next commit that they likely would have to issue explicitly. Each save on the other hand would likely only generate a temporary commit that gets replaced by the next saved state.
• One thing to figure out would be what to do if two users make conflicting changes. My inclination would be to let people fetch both git revisions and then sort out the mess themselves on the command line.
• Another question is how this would interact with validation. One slight issue is that validation can take a few seconds, which takes away from the immediacy of the edit-save-preview cycle. On the other hand, some parts of relate may be considerably unhappy if they run on unvalidated data. Maybe validation can be made fast enough to not hamper this too much.

from relate.

Wow! What a great idea. I like the idea of commit upon save using Dulwich. I have not explored deeply into Dulwich package, although I've implicit expected that utility. Your idea is much further and more considerate than mine. If that can be applied, I think it's quite possible that course developers can use pull and drag to edit their course content, which will also reduce validation work, and lower the barrier for Relate user.

from relate.

https://gitlab.tiker.net/inducer/relate/merge_requests/62

from relate.