Discussion about: How do TWs JSON Formats Look Like

Developers
, ,
#1

Very useful! Thank you Mario.

How do TWs JSON Formats Look Like
#2

@PaulH
This is a good article to be included in Newsletter

1 Like
#3

Comprehensive, @pmario :clap:

1 Like
#4

Thanks @pmario that’s very helpful.

I notice that the headings present the “single tiddler export format” as being different than the “multiple tiddler export format”. I wonder if that’s helpful; they are in fact the same file format, but with different means of generating them and hence different numbers of tiddlers within them.

I think the way that the $:/Import tiddler is explained might be confusing. There’s a lot of detail there before one gets to the plugins tiddler format section. I think it might be clearer to explain plugins first, and then to explain how $:/Import extends the plugin format (it might also be helpful to cover the special fields that the import process uses for tracking the checkbox selection.

I don’t think it’s correct to characterise this as anything to do with “security reasons”. It is more of an encoding issue: we need to make sure that there is no closing </script> tag within the data we are storing in the script tag.

#5

Thx for the info. I did update the wiki in the OP.

Changed order to have Plugin and then Import info.
Changed info about the </script> tag

#6

Thanks Mario for what I presume was in part a response to my topic Conversion tools between the various tiddler and JSON formats this is a very helpful resource.

A matter arising;

  1. To assist conversions it would be helpful if we share some code to add or remove “wrappers” such as your documented

[{ }]

vs

[
{ }
]

and

{
    "tiddlers": { ....
   }
}

And/or point to the widgets that are involved. Noting that we need to be able to convert both simple and pretty forms, to an from.

#7

yes.

I did think about that too. But I think we need to make the templates, that actually create those exported formats more accessible for users.

That’s especially true for the “pretty printed” version. The core code is able to create pretty printed JSON output as we can see in the “parse-tree” and “widget-tree” edit-tiddler-previews.

But those possibilities are more or less hardcoded. It would be possible to create those previews with core templates. Especially once the parametrised transclusions are a thing.

I’d rather put my energy into that option, even if it is more work and not immediately available. … But it would be an investment into the future.

1 Like
#8

I have being experimenting with additional preview formats and in one case made the ability to copy what you see to the clipboard. One use case was to copy static html out of the preview.

  • Perhaps extending the preview tools or introduce a alternative formats view /copy tool?
#9

hmmm, May be possible. … But I have the concern that the preview gets a bit over-engineered and also hard to find

#10

Actually the preview mechanism has a list of items with the tag $:/tags/EditPreview which are otherwise simple templates display the tiddler through that template.

  • I don’t think overengineering is the problem, more over using the preview feature.
  • That is why I suggested;
  • A simple dropdown to click copy contents as “format name”, ctrl-click to create new tiddler containing the alternative format.
  • Where format name are the relevant alternate formats for the current tiddler.
  • keep in mind, in a number of cases it will just be a rendered version of a preview “template”.