|
1 | | -# snark |
2 | | -Scientific Notation And Representation in Kotlin |
| 1 | +# SNARK |
| 2 | + |
| 3 | +In Lewis Carroll "The hunting of the Snark", the Snark itself is something everybody want to get, but nobody know what it is. It is the same in case of this project, but it also has narrower scope. SNARK could be read as "Scientific Notation And Research works in Kotlin" because it could be used for automatic creation of research papers. But it has other purposes as well. |
| 4 | + |
| 5 | +To sum it up, **SNARK is an automated data transformation tool with the main focus on document and web page generation**. It is based on [DataForge framework](https://github.com/SciProgCentre/dataforge-core). |
| 6 | + |
| 7 | +SNARK **is not a typesetting system** itself, but it could utilize typesetting systems such as Markdown, Latex or Typst to do data transformations. |
| 8 | + |
| 9 | +## Concepts |
| 10 | + |
| 11 | +The SNARK process it the transformation of a data tree. Initial data could include texts, images, static binary or textual data or even active external data subscriptions. The result is usually a tree of documents or a directly served web-site. |
| 12 | + |
| 13 | +**Data** is any kind of content, generated lazily with additional metadata (DataForge Meta). |
| 14 | + |
| 15 | +## Using DataForge context |
| 16 | + |
| 17 | +DataForge module management is based on **Contexts** and **Plugins**. Context is used both as dependency injection system, lifecycle object and API discoverability root for all executions. To use some subsystem, one needs to: |
| 18 | + |
| 19 | +* Create a Context with a Plugin like this: |
| 20 | + |
| 21 | +```kotlin |
| 22 | +Context("Optional context name"){ |
| 23 | + plugin(SnarkHtml) |
| 24 | + // Here SnarkHtml is a Plugin factory declared as a companion object to a Plugin itself |
| 25 | +} |
| 26 | +``` |
| 27 | + |
| 28 | +* Get the loaded plugin instance via `val snarkHtml = context.request(SnarkHtml)` |
| 29 | + |
| 30 | +* Use plugin like |
| 31 | + |
| 32 | +```kotlin |
| 33 | +val siteData = snarkHtml.readSiteData(context) { |
| 34 | + directory(snark.io, Name.EMPTY, dataDirectory) |
| 35 | +} |
| 36 | + |
| 37 | +``` |
| 38 | + |
| 39 | +## SNARK-html |
| 40 | + |
| 41 | +SNARK-HTML module defines tools to work with HTML output format. The API root for it is `SnarkHtml` plugin. Its primary function (`parse` action) is to parse raw binary DataTree with objects specific for HTML rendering, assets and metadata. It uses `SnarkReader` and more specifically `SnarkHtmlReader` to parse binary data into formats like `Meta` and `PageFragment`. If `parse` could not recognize the format of the input, it leaves it as (lazy) binary. |
| 42 | + |
| 43 | +### Preprocessing and postprocessing |
| 44 | + |
| 45 | +Snark uses DataForge data tree transformation ideology so there could be any number of data transformation steps both before parsing and after parsing, but there is a key difference: before parsing we work with binaries that could be transformed directly (yet lazily because this is how DataForge works), after parsing we have not a hard data, but a rendering function that could only be transformed by wrapping it in another function (which could be complicated). The raw data transformation before parsing is called preprocessing. It could include both raw binary transformation and metadata transformation. The postprocessing is usually done inside the rendering function produced by parser or created directly from code. |
| 46 | + |
| 47 | +The interface for `PageFragment` looks like this: |
| 48 | + |
| 49 | +```kotlin |
| 50 | +public fun interface PageFragment { |
| 51 | + context(PageContextWithData, FlowContent) public fun renderFragment() |
| 52 | +} |
| 53 | +``` |
| 54 | + |
| 55 | +It takes a reference to parsed data tree and rendering context of the page as well as HTML mounting root and provides action to render HTML. The reason for such complication is that some things are not known before the actual page rendering happens. For example, absolute links in HTML could be resolved only when the page is rendered on specific REST request that contain information about host and port. Another example is providing automatic counters for chapters, formulas and images in document rendering. The order is not known until all fragments are placed in correct order. |
| 56 | + |
| 57 | +Postprocessors are functions that transform fragments of HTML wrapped in them according to data tree and page rendering context. |
| 58 | + |
| 59 | +Other details on HTML rendering could be found in [snark-html](./snark-html) module |
| 60 | + |
| 61 | + |
| 62 | + |
| 63 | +### [examples](examples) |
| 64 | +> |
| 65 | +> **Maturity**: EXPERIMENTAL |
| 66 | +
|
| 67 | +### [snark-core](snark-core) |
| 68 | +> |
| 69 | +> **Maturity**: EXPERIMENTAL |
| 70 | +
|
| 71 | +### [snark-gradle-plugin](snark-gradle-plugin) |
| 72 | +> |
| 73 | +> **Maturity**: EXPERIMENTAL |
| 74 | +
|
| 75 | +### [snark-html](snark-html) |
| 76 | +> |
| 77 | +> **Maturity**: EXPERIMENTAL |
| 78 | +> |
| 79 | +> **Features:** |
| 80 | +> - [data](snark-html/#) : Data-based processing. Instead of traditional layout-based |
| 81 | +> - [layouts](snark-html/#) : Use custom layouts to represent a data tree |
| 82 | +> - [parsers](snark-html/#) : Add custom file formats and parsers using DataForge dependency injection |
| 83 | +> - [preprocessor](snark-html/#) : Preprocessing text files using templates |
| 84 | +> - [metadata](snark-html/#) : Trademark DataForge metadata layering and transformations |
| 85 | +> - [dynamic](snark-html/#) : Generating dynamic site using KTor server |
| 86 | +> - [static](snark-html/#) : Generating static site |
| 87 | +
|
| 88 | + |
| 89 | +### [snark-ktor](snark-ktor) |
| 90 | +> |
| 91 | +> **Maturity**: EXPERIMENTAL |
| 92 | +
|
| 93 | +### [snark-pandoc](snark-pandoc) |
| 94 | +> |
| 95 | +> **Maturity**: EXPERIMENTAL |
| 96 | +
|
| 97 | +### [examples/document](examples/document) |
| 98 | +> |
| 99 | +> **Maturity**: EXPERIMENTAL |
| 100 | +
|
0 commit comments