* 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?
When saving new tiddlers on node.js, allow the user to override the path of the
generated .tid file. This is done by creating a tiddler
$:/config/FileSystemPaths which contains one or more filter expressions, one
per line. These filters are applied in turn to the tiddler to be saved, and
the first output produced is taken as a logical path relative to the wiki's
tiddlers directory. Any occurences of "/" in the logical path are replaced with
the platform's path separator, the extension ".tid" is appended, illegal
characters are replaced by "_" and the path is disambiguated (if necessary) in
order to arrive at the final tiddler file path. If none of the filters matches,
or the configuration tiddler does not exist, fall back to the previous file
naming scheme (i.e. replacing "/" by "_").
This implies we will now, for tiddlers matching the user-specified filters,
create directory trees below the tiddlers directory. In order to avoid
cluttering it with empty directory trees when renaming or removing tiddlers, any
directories that become empty by deleting a tiddler file are removed
(recursively).
Benefits of this configuration option include the ability to organize git
repositories of TiddlyWikis running on node.js, ability to replace characters
that cause trouble with particular operating systems or workflows (e.g. '$' on
unix) and the ability to replicate tiddler "paths" in the filesystem (by
including a filter like "[!has[draft.of]]") without forcing such a (potentially
problematic) change on all users.
* Add icon for view template segment
* Muted background colour for view template segment
* Include links to parent tiddlers in the view template segment
* Fix logic for hiding/showing documents/headings (“open”/“close” were
transposed)
Without modified dates, new imports do not appear in recent file list. The equivalent of modified dates in ENEX is the 'updated' tag, with a date format similar to that of TW with the exception that the date format consists of a date stamp, a letter T, and a time stamp followed by Z for UTC presumably. There is no millisecond indicator. Not all ENEX notes have an update tag. The solution here is to apply creation date by default and then apply the update date if it is available. Dates are converted by stripping out Z and T and appending '000'.
@sukima the main issue with the previous code was that it incorrectly
used comma to delimit tags. We actually use spaces, and double square
brackets to delimit tags containing spaces. Better is to leave the tags
field as an array; the core will serialise it correctly as required.
I also made some minor consistency tweaks.
Relates to Issue #2268
I tried to map over the list of tags but NodeLists are not arrays and so
need to be converted. This looks ugly and probably should be abstracted
to a function. Come to think of it should we have a `$tw.utils.map()`
function?
Relates to Issue #2268
Based in the [example XML][1] attachments are listed in the <resources>
node. Since in TiddlyWiki these would be media tiddlers I add then one
by one as separate tiddlers.
There are some things that still need to happen. There should be a mime
type check so we don't attempt to import media tha TiddlyWiki doesn't
support. Also the example suggests the data is base64 encoded so I
blindly use that for the text attribute. Should there be a
`data:mediatyp;base64,…` prefix?
[1]: https://gist.github.com/evernotegists/6116886
Integrating this module allows us to do HTML/XML parsing under Node.js
(there is no built-in support for Node.js; we can already do HTML/XML
parsing in the browser). The implementation chosen is pure JavaScript,
and will work in all configurations of TiddlyWiki.
The immediate motivation is the work I’m doing to integrate with Amazon
Web Services.
We should be able to use JSZip to export multiple tiddlers in a single
operation from the browser.
Instead of showing a sequence of all documents in the preview column,
we just show a single document, with a dropdown to choose which one is
shown.
The change makes it easier to deal with large numbers of documents.
The metadata for each field is in a tiddler tagged
`$:/tags/DocumentMetaData` with the field `caption` being the displayed
caption for the field and `field` being the name of the field.
`field-type` is the type of the field, and can be “string” or “list”.
Previously, newly created image files would end up being saved as a
base64-encoded .tid file. Now they are saved as an ordinary binary file
with an accompanying .meta file for the metadata.
By making the docs available as a plugin we make it easier for people
to fork their own copy of the docs without losing the ability to get
updates in the future (which can be done just be updating the docs
plugin)
Many reasons:
* to allow subtrees to be grafted more easily
* to keep the tags for an entry clean by removing structural tags and
leaving the semantic tags
* to avoid the duplication of expressing the same relationship through
both the tags and list fields
1. Switch from using the text field of lists for storing the associated
filter to using the field `toc-list-filter` (to make it harder to
accidentally parse the text of an ordinary tiddler as a filter)
2. Fix several bugs
The exclude filter `+[tag[intro]]` will produce a document that only
includes the paragraphs with the tag “intro”. These are derived from
the paragraphs in the original document with the CSS class “intro”.
* Add warning in document tiddler toolbar if tiddler already exists
* Live preview document in new window
* Fix slicer.js bug that was preventing the list field of headings from
being filled in correctly
* Rationalise some class names
Now includes a special document view column on the left. Headings can
be expanded/collapsed, and tiddler titles can be inspected and renamed
via the toolbar. Clicking on an entry opens the associated tiddler. The
default tiddler view template includes a special section for tiddlers
that are part of a document
Now we process the rendered HTML of tiddlers, which allows us to
process HTML generated by MS Word. In fact, the HTML that MS Word
generates is so awful, I’ve instead been using Mammoth to do the
conversion: https://github.com/mwilliamson/mammoth.js
Also some necessary improvements to the fake dom implementation.
1. Introduce template tiddlers for the document, each tiddler, and the
tiddler toolbar
2. Move the text slicer toolbar button to the left of the edit button
3. Add a selectable toolbar, currently just containing the tiddler title
We’d rather present this information as a panel within the tiddler
editor so that we can (for example), allow clicks on a snippet to
insert it automatically into the editor at the current cursor position.
For the moment, we’ll just remove the cheatsheet. Post-5.1.8 we’ll add
it back to the editor
* Moved “add new plugin” into a modal wizard
* Adopt big friendly buttons
* Add plugin icons and readmes to “add new plugin” modal
* Use tabs for splitting plugins/themes/languages
* Consistent styling between the “add new plugin” modal and the
“installed plugins” control panel tab
* Behind the scenes, moved from addressing the library as
`recipes/defaults/tiddlers/<etc>` to `recipes/library/tiddlers<etc>`
There was a rendering mess in the CodeMirror readme file. This was cause
by attempting to bold the `$:/tags/Stylesheet` text. Also the context of
the sentence implies this should be backticked not bold (it refers to a
tag not a tiddler).
This is just an idea really.
The help plugin is only included in the tw5.com wiki; the idea is to
also include it in the empty.html wiki, either as a plugin or as part
of the core.
If it stays as a plugin, the idea would be to have different help
plugins for different languages.
