Better file-type handling #70

Closed
colelawrence opened this Issue Mar 4, 2014 · 11 comments

Comments

Projects
None yet
2 participants
Collaborator

colelawrence commented Mar 4, 2014

Some files that can be edited in CM do not have that option, while other files that are not meant to be edited as text are available to edit with CM.

Owner

silverwind commented Mar 4, 2014

Probably best to use mime-types instead of extensions in the long run, should be easy enough to add.

Owner

silverwind commented Apr 3, 2014

CodeMirror.mimeModes holds our current supportes mime types. For reference, these are the types we support right now:

application/ecmascript
application/javascript
application/json
application/ld+json
application/typescript
application/x-httpd-php
application/x-httpd-php-open
application/x-json
application/xml
text/css
text/ecmascript
text/html
text/javascript
text/plain
text/typescript
text/x-coffeescript
text/x-jade
text/x-less
text/x-markdown
text/x-php
text/x-scss
text/xml
Owner

silverwind commented Jul 1, 2014

I'll have a look at this later.

I think it'd be best to use the existing type system based on file extension for this.

Collaborator

colelawrence commented Jul 1, 2014

When downloading a file for viewing/editing does our server provide the correct mimetypes?

Would that help us accomplish this since CodeMirror already works with MimeTypes?

Owner

silverwind commented Jul 1, 2014

Yes the server does provide correct mime-types through the Content-Type header. Anything it doesn't know will be served as application/octet-stream, so I guess it should be easy to do a header check, cancel the XHR if it fails that check, and provide a download instead (probably by redirecting the client to an hidden <a download>).

@silverwind silverwind self-assigned this Jul 1, 2014

Collaborator

colelawrence commented Jul 1, 2014

so I guess it should be easy to do a header check, cancel the XHR if it fails that check, and provide a download instead

Hmm... So doing this and improving the header content type header response will solve this issue?

Owner

silverwind commented Jul 1, 2014

It's a bit trickier than I thought. I have the header check working right now, but .dotjs for example can't be edited right now because there's no official mime type for them, the server sends application/octet-stream and the client refuses editing of course.

I think this approach isn't really the best way to go as it would require maintaining a huge list of extensions or mimetypes, and a better approach would be to actually send two XHRs, one to let the server check if the requested file is a binary (could be done by reading, say, 100 bytes from the file and then checking if it contains anything in the non-printable ASCII range), and after that one is finished, send a real request if its binary.

I'll continue tomorrow on this.

Collaborator

colelawrence commented Jul 1, 2014

This will be handy: https://github.com/gjtorikian/isBinaryFile

I like that. I like that a lot.

Owner

silverwind commented Jul 2, 2014

Not totally happy yet, I need to rewrite the part about click action so the URL won't change before the decision to view or download is made. Also, that iframe hack is pretty dirty 😢.

silverwind added a commit that referenced this issue Jul 2, 2014

Owner

silverwind commented Jul 4, 2014

This should be done now. openFile() does the logic on what to do when you click "Open file" (which is always visible now). If the user still wants to edit a file no matter what, the "Edit" button is now visible on all files and forces the file into the editor, binary or not.

I also went ahead and removed the click action option, and it defaults to the same check openFile does, so will either view or download depending on type and if it's binary.

@silverwind silverwind closed this Jul 4, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment