You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
E2 allowed a link tag to specify an ex:converter, which named a javascript function that would transform fetched data (into exhibit format) before loading it into the database. In particular, google spreadsheets data was imported into exhibit using such a converter. In E3, the converter argument has been removed; now there is a google spreadsheets importer registered to a google spreadsheets link type.
With this new approach, anyone who wants to import json data of an unusual schema needs to create and register their own importer. This requires far deeper understanding of exhibit than just writing a js function and passing it as a converter argument.
I'd like to bring back the converter option. In particular, I propose 3 optional arguments in a link tag: getter, parser, and converter. The getter is either json or jsonp, representing the two ways exhibit can fetch a text blob from a source. A parser takes a text blob and returns a js object. And a converter takes a json object and produces a different one (presumably exhibit compatible). An importer is a combination of getter, parser, and converter associated with a particular data type, so e.g. application/json has importer=json, parser=json.parse, and converter null. But any one of the three elements can be overridden by an explicit argument, and if all three are explicitly given then no type needs to be specified.
In absence of objection, I'll plan to implement this in the simile-widgets branch.
The text was updated successfully, but these errors were encountered:
I'd like to import some Semantic Mediawiki (SMW) content via SMW's API.php [1] ->JSON and convert it to an Exhibit database (items). Not being an expert I would like to know where to start for such solution: write an importer/parser/converter code ? is this argument/function implemented in E3 ? is there an example which can be reused (i.e. importing from other sources to JSON Exhibit) ?
Background:
I used to work (years ago) with Exhibit SRF [2] which no more works in MediaWiki. So the alternative seems to load JSON/items by calling the MediaWiki API from an exhibit HTML file.
SMW provide cool ways to maintain your source information in forms, additional text, etc.
I made an Excel-to-JSON(Exhibit) macro which exports worksheets as file.tsv (in UTF-8). This works but:
** it can't handle multiple values per fields
** A (Media)Wiki contains lot more infromation and link between all knowledge compared to Excel-sheets.
E2 allowed a link tag to specify an ex:converter, which named a javascript function that would transform fetched data (into exhibit format) before loading it into the database. In particular, google spreadsheets data was imported into exhibit using such a converter. In E3, the converter argument has been removed; now there is a google spreadsheets importer registered to a google spreadsheets link type.
With this new approach, anyone who wants to import json data of an unusual schema needs to create and register their own importer. This requires far deeper understanding of exhibit than just writing a js function and passing it as a converter argument.
I'd like to bring back the converter option. In particular, I propose 3 optional arguments in a link tag: getter, parser, and converter. The getter is either json or jsonp, representing the two ways exhibit can fetch a text blob from a source. A parser takes a text blob and returns a js object. And a converter takes a json object and produces a different one (presumably exhibit compatible). An importer is a combination of getter, parser, and converter associated with a particular data type, so e.g. application/json has importer=json, parser=json.parse, and converter null. But any one of the three elements can be overridden by an explicit argument, and if all three are explicitly given then no type needs to be specified.
In absence of objection, I'll plan to implement this in the simile-widgets branch.
The text was updated successfully, but these errors were encountered: