1
0
mirror of https://github.com/Jermolene/TiddlyWiki5 synced 2024-11-17 15:24:50 +00:00
TiddlyWiki5/core
Devin Weaver bf74d13df5 Handle binary files better when saving on Node.JS (#2420)
* Save binary tiddlers with meta file

The filesystemadaptor plugin was a little simplistic in its
understanding of a binary file. It was using the typeInfo dictionary to
choose what tiddler types were binary (and hence needed a meta file when
saving).

I looked as if it was trying to be smart by looking for the hasMetaFile
*OR* had the encoding of base64. Unfortunately the typeInfo only defined
image/jpeg and so any other base64 encoded tiddler was assumed to be of
type text/vnd.tiddlywiki.

The net effect was only JPG images got a meta file and everything else
were saved as .tid files with base64 encoding. It all still worked but
made working with binary data in a Git repo a bit daunting.

There is enough information in the $tw.config.contentTypeInfo to
determine if a tiddler type is encoded with base64 or not. A better list
is available from boot/boot.js who registers all the types thorough the
registerFileType and marks then with base64 were appropriate.

This commit uses the typeInfo dictionary first for any filesystem
specific overrides, then the contentTypeInfo, and finally defaults to
the typeInfo["text/vnd.tiddlywiki"]. It also eliminates the now
unnecessary override for image/jpeg.

I think this might have been the original intent from commit 10b192e7.
From my limited testing all files described in boot/boot.js (lines
1832-1856) with an encoding of base64 now save as the original binary
and a meta file. Meaning that when you start the node server and then
drag-n-drop a binary file (i.e. image/png) it will PUT to the server
and then save it on the filesystem as-is allowing the file to be managed
as a binary file and not a text file. (Binary diffs are better and
GitHub supports them as well).

* Prevent duplicate file extensions

A side effects of using the $tw.config.contentFileInfo in the previous
commit is that it will always append a file extension to the tiddler
title when saving. In most cases this is the correct course of action.
However, sometimes that title is already a proper filename with an
extension (for example importing 'foobar.png' would save a file named
'foobar.png.png') which seemed silly.

This commit simply checks to make sure the title does not already end
with the file extension before appending it to the filename. A little
convenience really.

Since IE apparently doesn't have the String endsWith method I took the
liberty to add a helper method to $tw.utils trying to follow the other
polyfill patterns. I figured this was more generic and readable then
attempting to use a one-off solution inline. I got the polyfill code
from MDN.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/endsWith#Polyfill

Is strEndsWith the best method name?
2016-07-11 11:18:19 +01:00
..
images Minor fix to preview-closed icon 2016-05-09 14:41:13 -06:00
language Add localisable string for missing plugin info (#2465) 2016-05-26 09:06:17 -06:00
modules Handle binary files better when saving on Node.JS (#2420) 2016-07-11 11:18:19 +01:00
palettes Tweak contrast themes 2015-05-28 09:47:42 +01:00
templates Added mobile-web-app-capable meta tag for Android Chrome (#2456) 2016-07-11 11:16:58 +01:00
ui Show tags with contrast colour in edit template (#2484) 2016-07-01 10:40:37 +01:00
wiki Fix table of contents issue with tiddler titles containing single quotes 2016-05-02 08:20:04 +01:00
acknowledgements.tid Reorganise acknowledgements 2014-08-01 08:42:52 +01:00
copyright.tid It's 2016! 2016-01-03 18:04:21 +00:00
icon.tid Experimental SVG Compression 2015-03-31 14:39:36 +01:00
plugin.info Consistent plugin descriptions 2015-02-17 10:28:54 +00:00
readme.tid Add/update plugin readmes 2014-08-07 15:49:52 +01:00

title: $:/core/readme

This plugin contains TiddlyWiki's core components, comprising:

* JavaScript code modules
* Icons
* Templates needed to create TiddlyWiki's user interface
* British English (''en-GB'') translations of the localisable strings used by the core