| 7 | 7 |
| `/fileder/facet: type/subtype -> wrapped/type` | `/path/to/fileder` | `facet` | `type/subtype -> wrapped/type` |
|
| 8 | 8 |
| `/fileder/: some/type` | `/fileder` | (default facet) | `some/type` |
|
| 9 | 9 |
| `/fileder/alternate:` | `/fileder` | `alternate` | `text/html` (default type) |
|
|
10 |
| `/path` | `/path` | (default facet) | `text/html` (default type) |
|
| 10 | 11 |
| `/` | `/` | (default facet) | `text/html` (default type) |
|
| 11 | 12 |
|
| 12 | 13 |
The fileder-index metadata was moved to a `?index` 'pseudofacet' (e.g. `/fileder/?index`).
|
|
14 |
|
|
15 |
**EDIT 2019-10-09:**
|
|
16 |
> I will take this chance to show and hopefully explain the point of this all again:
|
|
17 |
> With the system running it is now possible to demonstrate the type-coercion that powers the system.
|
|
18 |
>
|
|
19 |
> In the system, every piece of data (the *facet*s) is stored together with it's *type*.
|
|
20 |
> When requesting data, it can of course be loaded with that *type*, yielding the data unmodified,
|
|
21 |
> but it is also possible to demand a different *type* that may be more useful to the receiving application.
|
|
22 |
>
|
|
23 |
> as an example we can take for example this article about one of the internal libraries for writing HTML documents:
|
|
24 |
> [`/meta/mmm.dom/`](/meta/mmm.dom/).
|
|
25 |
>
|
|
26 |
> The path `/meta/mmm.dom/` corresponds, according to the table above, to the default facet of the `/meta/mmm.dom` fileder,
|
|
27 |
> and since no type was specified, it is assumed that the browser wants a `text/html` document.
|
|
28 |
> The follwing path gives the same result, but makes this explicit:
|
|
29 |
> [`/meta/mmm.dom/:text/html`](/meta/mmm.dom/:text/html)
|
|
30 |
>
|
|
31 |
> now, instead of asking for the rendered HTML document, we can also ask for the source, which is of the type
|
|
32 |
> `text/moonscript -> mmm/dom` (a Moonscript-script file that evaluates to a website-fragment):
|
|
33 |
> [`meta/mmm.dom/:text/moonscript -> mmm/dom`](/meta/mmm.dom/:text/moonscript%20-%3E%20mmm/dom)
|
|
34 |
>
|
|
35 |
> or, we could ask for the generated html fragment, but without the full HTML layout around it -
|
|
36 |
> that would be the type `text/html+frag`, as mentioned in the last post:
|
|
37 |
> [`meta/mmm.dom/:text/html+frag`](/meta/mmm.dom/:text/html+frag)
|
|
38 |
>
|
|
39 |
> lastly, we could also ask the system to generate a link to this content, in the `text/html` format (`URL -> text/html`):
|
|
40 |
> [`meta/mmm.dom/:URL -> text/html`](/meta/mmm.dom/:URL%20-%3E%20text/html)
|
|
41 |
> this might seem somewhat redundant, since we need a link to access this link,
|
|
42 |
> but it can be useful when a component cannot work with binary data directly, e.g. when mentioning or embedding an image
|
|
43 |
> or a video file.
|
| 13 | 44 |
|
| 14 | 45 |
I also added support to the server for serving static assets (e.g. the CSS stylesheet) from the `static` directory.
|
| 15 | 46 |
These files are accessible through the `/.static/` route (e.g. `/.static/main.css`), where they shouldn't interfere
|