Are lists/documentations of implementation bugs within scope? about davwiki HOT 15 CLOSED

Yes, that's within the scope as long as you can clearly show (by linking to the relevant specs) that the behavior is broken. Ideally you can add a link to a project bug tracker for each issue, so one can verify if the issue still exists.
I'm currently experimenting with tables, but the current Markdown renderer doesn't seem to support tables. I need to switch, but the one that supports tables requires some changes in the Markdown sources and templates.

Having an article about URL encoding is definitely a good thing.

from davwiki.

I think a system for tagging pages would be useful, so a list of pages that describe bugs can be autogenerated.

On 27 July 2015 11:32:38 CEST, Marten Gajda [email protected] wrote:

Yes, that's within the scope as long as you can clearly show (by
linking to the relevant specs) that the behavior is broken. Ideally you
can add a link to a project bug tracker for each issue, so one can
verify if the issue still exists.
I'm currently experimenting with tables, but the current Markdown
renderer doesn't seem to support tables. I need to switch, but the one
that supports tables requires some changes in the Markdown sources and
templates.

Having an article about URL encoding is definitely a good thing.

---

Reply to this email directly or view it on GitHub:
#3 (comment)

Sent from my phone. Please excuse my brevity.

from davwiki.

I've thought about that too. Would be useful for other things as well, like building automatic indexes of properties, namespaces ...
My idea was to use magic comments for this (basically like the title comment):
<!-- --- tag: property -->
<!-- --- namespace: DAV: -->
or
<!-- --- tag: known-issue -->

from davwiki.

Is gollum extensible for this, or would you have to write a preprocessor? In the latter case I'd consider switching software.

On 27 July 2015 13:49:46 CEST, Marten Gajda [email protected] wrote:

I've thought about that too. Would be useful for other things as well,
like building automatic indexes of properties, namespaces ...
My idea was to use magic comments for this (basically like the title
comment):
<!-- --- tag: property -->
<!-- --- namespace: DAV: -->
or
<!-- --- tag: known-issue -->

---

Reply to this email directly or view it on GitHub:
#3 (comment)

Sent from my phone. Please excuse my brevity.

from davwiki.

I'm not familiar with the Gollum internals nor Ruby, unfortunately. My idea was to write a simple preprocessor, either in Bash or Python. That shouldn't be difficult.
Do you have any specific suggestions?

from davwiki.

No, most I've come across are either built for blogs or too generic to be useful out-of-the-box.

from davwiki.

I'll check out ikiwiki, I've seen somebody use that. I suspect it's slightly too bloated though. Scratch that, complete bloat.

Other than that, I think Pelican or liquidluck are pretty good. I use the latter to run my blog, it has a tagging system that applies both to "pages" and "articles".

from davwiki.

The core requirements are:

• lightweight
• git based, I don't want a database, but I still want revisions, branches and commit messages ...
• full text search
• Markdown support

from davwiki.

Yeah, I think gollum is still your best bet.

However, it seems that gollum supports putting pages into folders, I believe davwiki should use that.

from davwiki.

It does make use of folders. Though, at present only the templates are in a sub-folder. I'm still in the process of creating the base structure and templates.

from davwiki.

I've created some proof of concept code to pre-process tags and templates for davwiki: https://gist.github.com/dmfs/0f0e5bfd6955f0eb3b2e
The code uses jinja2 to process and render templates into the pages.

The basic idea is to add tags to page files like so

<!-- --- title: DAV::getetag -->
<!-- --- rfc: RFC 4918 -->
<!-- --- namespace: DAV:: -->
<!-- --- element: getetag -->
<!-- --- type: property -->
<!-- --- purpose: Contains the [[ETag]] header value (from [Section 14.19 of RFC 2616](http://tools.ietf.org/html/rfc2616#section-14.19)) as it would be returned by a [[GET]] without accept headers. -->
<!-- --- value: entity-tag -->

An index page could include a template like so:

<include-template template="rfc-list.template"></include-template>

The template file rfc-list.template looks like this:

{% for rfc in tags.rfc._values|sort %}

### {{ rfc }}

| Property | Purpose | Value |
| -------- | ------- | ----- |
{% for element, pages in tags.element._values.items()|sort %}{% for page in pages %}{% if rfc in page.rfc %}| [[{% if page.title %}{{page.title|first}}|{% endif %}{{page.link}}]] | {{page.purpose|first}} | {{page.value|first}} |
{% endif %}{% endfor %}{% endfor %}{% endfor %}

The processed index page contains this instead of the empty tag:

<include-template template="test.template">

### RFC 4918

| Property | Purpose | Value |
| -------- | ------- | ----- |
| [[DAV::getetag|DAV::getetag]] | Contains the [[ETag]] header value (from [Section 14.19 of RFC 2616](http://tools.ietf.org/html/rfc2616#section-14.19)) as it would be returned by a [[GET]] without accept headers. | entity-tag | 
</include-template>

The entire content of the <include-template> tag is replaced with the rendered template when the script runs.

It could be run by a post-receive hook on the production site to update all pages automatically.

I'll try to build a list of useful tags to check if this can satisfy all use cases.

from davwiki.

I've just deployed the pre-processor (with a few more changes) and the tagged pages. Works well so far. Most (not all) indexes and listings are now created by the pre-processor using jinja2 templates.
The pre-processor turned out to be even simpler then I expected.

from davwiki.

Could we move properties, methods, etc. in respective folders? I think this would be easier to navigate from the command line.

from davwiki.

I need to check if gollum still resolves links properly when you omit the folder name. If that's still the case I wouldn't mind doing so, though it may also require a few template updates.

from davwiki.

Closing this since the question has been answered already.

from davwiki.