Consider rolling a simple custom editor app.

brianmcmichael commented 8 years ago

CloudCmd contains an editor that relies on key-bindings for functionality. The lack of a "Save" button has therefore caused some concern among initial users.

We may want to consider creating a simple editor app that relies on the "Ace" editor. https://github.com/ajaxorg/ace

Using this would allow us to add a "Save" feature, and also the ability to modify font-sizes, themes, and keybindings on the fly.

There is a large list of color themes available and keybindings for "Vim" and "emacs" in addition to the default editor keybindings.

Ideally, we'd be able to create the app to accept param arguments that would take the user directly to the editable file. Then we could pass the user to the editor from external apps like jobconstructor and fileexplorer.

See the proposed screenshot.

editorscreen

brianmcmichael commented 8 years ago

Things like key-bindings, size, and theme preferences could be saved in a cookie.

ericfranz commented 8 years ago

This is very cool.

Jeremy recommended a "Save As" feature. We could also think of other features in the future. But in the short term having this app would

Option: instead of having a separate Rails app, we could have this be part of the dashboard.

Eventually, it might be nice to deploy this as a gem that can be part of the dashboard or included in other apps - unless we could somehow have other apps load the editor using requests to the dashboard. For example

we have full screen editor mode
we have embeded editor mode - where the editor and its options are embeded on a page along side other options (think, for example, a master detail view where the detail view shows the file contents in an editor)
we have the editor in a bootstrap modal (where saving closes the modal etc.)

We should also make use of the md5 hash and verify the contents of the file after it is downloaded and loaded into the editor - cloud commander offers this hash so we would do something similar - load the hash then load the file then do a hash and compare before letting the user start editing.

brianmcmichael commented 8 years ago

I also thought of displaying the file path in a text input box, then if the user changes the path there and clicks "save" it would go to a new location.

I could build the part below the OSC navbar in pure html/css/js

I don't think we need to worry about md5 file integrity. First answer explains it at this SO question We're uploading and downloading with http, which provides integrity checking through the browser at the tcp layer. Second, ace editor accepts a string input, which is going to have a different md5 than the file, and provides a string output, which we are going to have to either turn into a file and upload or POST the data and write to a file on the server-side.

Mostly the user "might" want an md5 checksum available somewhere (like in the file explorer, under "more info" or something like that) so that they can hand verify on their end, but the protocols we're using should already handle this for us. Usually you only see this on things like linux distro iso's so that people can confirm that they have the correct version and not one that's been tampered with.

brianmcmichael commented 8 years ago

This issue closed by the creation of https://github.com/AweSim-OSC/osc-fileeditor

OSC / ood-fileexplorer

Consider rolling a simple custom editor app. #70