Allow page metadata

[Necoro]

A lot of things are currently not possible in hatta for different reasons. One great step would be to allow a metadata header for the pages.

 Gitit allows it in the following form (the keys are taken from their README and are just for illustration):

---
format: latex+lhs
categories: haskell math
toc: no
title: Haskell and
  Category Theory
...

When the general support is done it can be expanded in different ways (the categories and toc are the main points in my eyes). It would even be possible to have here a way to allow plugins of some sort (only as an idea -- it is not the intention behind this proposal)

[sheep]

I'd love to store the file metadata, especially about the file format -- then I could detect it by file content or content-type header on upload instead of guessing it by the file extension, like some operating systems from the eighties do.

Unfortunately, I found no way of doing that and still having normal files in the repository that can be accessed with standard tools. Mangling the file content by adding some headers is out of the question here.

[Necoro]

This was only about normal pages -- i.e. the one with wiki format as my proposal is just a new format option.

You are right: It would be great to have it for all types, but this can't be done without hacks. (For example for one of my own projects, I use "foo.png.descr" for the metadata. But this will probably interfere with the normal mechanisms)

But can we re-open this ticket and focus on the wiki page part?

[sheep]

Sorry, I guess I'm feeling disappointed that I can't do it with all files.

So what you are suggesting is a sort of "pragma" markup added to the default wiki syntax.

Could you elaborate on what features you have in mind that would require it? I have some ideas, but I'd like to hear yours.

[Necoro]

Well ... ideas are:

• categories: The current "yeah - use backlinks"-approach is certainly a neat idea -- but not really practical in my eyes.
• toc: One could also add some explicit markup for it though.
• locked
• title: Filename isn't always the way to go :P Especially with subfolders

But in the end, the killer feature for me would be the categories. One could perhaps think about some way of adding explicit category-markup... but metadata might come in handy later on :)

[sheep]

I plan to add some explicit tags -- using the macro markup of Creole, which is a little useless in the current wiki parser. The categories are much more powerful, but they suffer from at least two problems: people are more familiar with tags, and there is this use/mention problem where you want to link to a category without actually putting the page in that category. But this doesn't actually require the pragma markup, it can be done with the macros, for example <<tag:favorite>>, or even with specialized markup (maybe lifted from tweeter?) -- I think they deserve it.

As for table of contents, this is a little more complicated.

First of all, I know that many users demand a table of contents only because they want an easy way of linking to a header. I want to provide that by using "purple links", just like Trac or Sphinx do -- I just need to write the little piece of JavaScript that will put those links in place, and it's one of those small things that I never have the time for.

Second, Hatta outputs parsed HTML as soon as it reads the markup from file. That's it doesn't feel that sluggish even though it does no caching of parsed HTML on its own. There is simply no way I could display a table of content at the top of the page -- because I don't know the page's content yet! I also plan to use JavaScript to solve that, and again this is a small and simple script that I just need to write one day. And it will definitely be inserted with a <<toc>> macro.

The title pragma has similar problem to the table of contents -- the title is printed out long before the wiki page even gets parsed. This is a design decision, and I was aware of the limitations it brought.

Lastly, if the locked status is indicated in the content of the page that is locked, then how do you unlock it? And of course here again we have the problem that Hatta needs to decide whether to show you the edit controls or not before it parses the page.

So, to summarize: I definitely plan to add most of the features you are talking about, but I don't think a metadata block is the best way to provide the interface for them. I know there are ways around the problems I raised here, but I think they complicate the design of the program unnecessarily (and one of the goals of Hatta, maybe not yet attained, is to provide wiki engine makers with a nice example of code).

[Necoro]

Well - the macro markup is definitly sufficient. Didn't know there was such a thing.

Regarding the locking: Well - with an editor. As you need for the "Locked" page already.

Regarding the categories: Oh well - for me 'tag' is just the web2.0-idiom for 'category'. I do not differentiate between them :).

Regarding the parsing/rendering problem: This was the advantage of the metadata stuff: You only need to look at the very first line of the page: If it does not start with ---, it isn't metadata and you can stop. If it is, you only need to read until "..." - and then you are done. So no need to parse the whole thing.

-- And well: In the end, also the "title" problem can be solved via JavaScript.

[sheep]

Well, the title is written before Hatta even starts to parse the file, and for most file types Hatta doesn't even do any parsing. I would hate to introduce a special case just for the wiki pages.

Unfortunately solving the title problem with JavaScript doesn't work as well as I would like -- the main reason why you would want to change the title of your page, and possibly also other elements in the HTML header, is search engine optimization. And search engines are well known for notoriously ignoring any and all scripts :)

As for categories vs. tags, categories have one advantage: you can categorize categories. This lets you build complicated structures, despite the fact that wikis are naturally flat.