[dokuwiki] Re: Patch attached: Optionally add a filetype to wikipage urls, e.g. .html to look like static html

  • From: Sander Tekelenburg <tekelenb@xxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Wed, 25 Feb 2009 05:21:07 +0100

At 01:32 +0100 UTC, on 2009-02-25, Helmut Tischer wrote:

> Sander Tekelenburg schrieb:

[...]

>> So here's a thought: how about using content-negotiation for this? [...]
>
> Thanks for your support, that's exactly how I implemented it!

Good :)

>> author changes the resource to some other format, Dokuwiki should probably
>> return a 404. In that sense this does go against
>
> Dokuwiki will just serve the document type which it wants to serve. I
> don't think this will change from (x)html in foreseeable years.
> So I did not put checks for exceptions in here.

That's not what I meant. What I meant was this: suppose someone publishes
some information in the form of a HTML document (be it a wiki page or
something else). After x time she decides that that same information would be
better conveyed through PDF. So she removes the HTML file and instead
provides a PDF file. The content has not changed. Only the file format in
which it is provided.

But if she started out with providing URLs ending in ".html", she wil now
have to change all links on her sites, get others to change their links on
their sites, get others to change their bookmarks.[*]

If instead the URL would have contained no file name extensions from the
start, the exact same URL would have still worked. No links on the rest of
the site, on *other* sites, or bookmarks in people's private addrss books
would need to be updated. The original URL would still point to the same
content.

A Web Publishing System that generates URLs with file name extensions makes
the life of ordinary users more difficult than necessary, because it
unnecessarily burdens them with some technical aspect that is really only
relevant to the server.

This is exactly about the argument you provided earlier: that you want to
make things easier for people ;)

[*] Yes, in that scenario too you could use content-negotiation to refer
requests for <http://domain.example/page.html> to
<http://domain.example/file.pdf>. But that just demonstrates how utterly
meaningless file name extensions are on the Web -- you see ".html", think you
are 'safe' and click it, only to receive a PDF! ;)

> Note, that for the case that the reader explicitely wants a specific
> output format, DokuWiki already provides the "export" feature. E.g.
> <http://www.dokuwiki.org/_export/raw/syntax> or
> <http://www.dokuwiki.org/_export/xhtml/syntax> or without "nice url"
> e.g. <http://www.dokuwiki.org/doku.php?do=export_raw&id=syntax>
> I think this is also different from your guidelines.

Hm... I'm not sure how these would be bad. Only that last URL is, but that's
what Dokuwiki's "nice URLs" function solves.

> However I am not sure about
>
>> <http://www.w3.org/TR/chips/> and <http://www.w3.org/Provider/Style/URI>.
>>But
>> only in the sense of what sort of requests it accepts -- not in the sense of
>> the URLs it actually generates itself. I'm inclined to consider this
>> acceptable.
>
> I am not sure what you mean here.

I mean that the content-negotiation approach that I suggested does not change
the actual URLs that Dokuwiki generates, and that therefore it doesn't seem
to conflict with the arguments in these two documents.

IMO, although I suggested it, the content-negotiation 'solution' isn't great,
because adding ".html" to a URL does suggest to the uneducated that that
actually has meaning. I agree with Anika that that it doesn't help users --
it encourages "beliefs" instead of "knowledge". But I can see how someone
might find it useful in certain situations. And at least this approach does
not change the URLs Dokuwiki generates.

> I implemented it that way, if the
> feature is enabled, the file extension hint is also put into generated
> links.

*Within* Dokuwiki pages? That's the *wrong* thing to do IMnsHO. What I
suggested was intended only to make it possible to write
"<http://domain.example/page.html>" in *plain text* contexts (like email),
not to change anything about the hyperlinks that Dokuwiki generates.

>>> ... if one mixes up
>>> example.com/namespace/namespaceorfile with example.com/namespaceorfile/
>>
>> I'm not sure which surprise you are referring to here.
>
> Simply, if the trailing slash of an existing namespace is missing,

Ah, right. Thanks.

> DokuWiki does not redirecting to adding the slash or to the start page
> of the namespace, but creates a new page with an identical name as the
> namespace.

Yeah, that's the wiki philosophy. (But as I said, IIRC you can enable the
option to have it return a 404 instead. Or maybe that requires some plugin. I
don't have an install handy right now.)

> Or is it the other way round: If a page of that name is not
> existing, the common practice of Browsers(?) to retrying with added
> slash is wrong?

For non-wikis this probably often is useful behaviour. But it is most
definitely not the browser that does this. The browser just stupidly asks for
some file. It is the server that then goes "I don't have that file. But I'm n
a good mood, so I'll bother to see if I have a directory by that name. Ah,
yes, I do". And then the server tells the browser "I don't have what you
asked for, but I do have something else that is probably what you meant to
ask for. Ask me for it". And then the browser asks for the thing with the
trailing slash.


-- 
Sander Tekelenburg, <http://www.euronet.nl/~tekelenb/>
-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts:

  1. Home
  2. dokuwiki
  3. Archive
  4. 02-2009