Instead of having files foo.html "in front of" foo/, I prefer to have
foo/index.html.
I independently implemented a similar, but smaller patch.
(It's smaller because I only care about rendering; not CGI, for example.)
The key to this patch is that "A/B/C" is treated as equivalent
to "A/B/C/index".
Here it is: --Per Bothner
--- IkiWiki/Render.pm~ 2007-01-11 15:01:51.000000000 -0800
+++ IkiWiki/Render.pm 2007-02-02 22:24:12.000000000 -0800
@@ -60,9 +60,9 @@
foreach my $dir (reverse split("/", $page)) {
if (! $skip) {
$path.="../";
- unshift @ret, { url => $path.htmlpage($dir), page => pagetitle($dir) };
+ unshift @ret, { url => abs2rel(htmlpage(bestlink($page, $dir)), dirname($page)), page => pagetitle($dir) };
}
- else {
+ elsif ($dir ne "index") {
$skip=0;
}
}
--- IkiWiki.pm~ 2007-01-12 12:47:09.000000000 -0800
+++ IkiWiki.pm 2007-02-02 18:02:16.000000000 -0800
@@ -315,6 +315,12 @@
elsif (exists $pagecase{lc $l}) {
return $pagecase{lc $l};
}
+ else {
+ my $lindex = $l . "/index";
+ if (exists $links{$lindex}) {
+ return $lindex;
+ }
+ }
} while $cwd=~s!/?[^/]+$!!;
if (length $config{userdir} && exists $links{"$config{userdir}/".lc($link)}) {
Note I handle setting the url; slightly differently.
Also note that an initial "index" is ignored. I.e. a
page "A/B/index.html" is treated as "A/B".
Actually, your patch is shorter because it's more elegant and better :)
I'm withdrawing my old patch, because yours is much more in line with
ikiwiki's design and architecture.
I would like to make one suggestion to your patch, which is:
diff -urX ignorepats clean-ikidev/IkiWiki/Render.pm ikidev/IkiWiki/Render.pm
--- clean-ikidev/IkiWiki/Render.pm 2007-02-25 12:26:54.745833000 -0800
+++ ikidev/IkiWiki/Render.pm 2007-02-25 12:56:40.711261000 -0800
@@ -106,11 +106,15 @@
if ($actions) {
$template->param(have_actions => 1);
}
+ my $title = $page;
+ if ($page =~ m!/index$!){
+ $title =~ s!/index$!!;
+ }
$template->param(
title => $page eq 'index'
? $config{wikiname}
- : pagetitle(basename($page)),
+ : pagetitle(basename($title)),
wikiname => $config{wikiname},
parentlinks => [parentlinks($page)],
content => $content,
This way foo/index gets "foo" as its title, not "index". --Ethan
How about doing the index stuff only on the output side? (Or does the latter patch do it? I haven't tried them.) That is, render every foo.type for the rendered types (mdwn etc.) as foo/index.html, generating links to foo/ instead of foo.html, but not earlier than the point where the .html as presently appended to the page name. Then you just flip a build time option on an existing wiki without any changes to that, and the pages appear elsewhere. The index.type files might be left out of this scheme, though (and the top-level one, of course, has to). --[[tuomov]]
Well, get around to wasting time on it after all, and here's the patch. The -use_dirs option will cause everything to be rendered inside directories. There may still be some problems with it, that need looking into (it doesn't e.g. check for conflicts between foo/index.mdwn and foo.mdwn), but seems to work well enough for me... The patch also improves, I think, the parentlinks code a little, as it uses generic routines to actually find the target location now. The only places where the use_dirs option is used is htmlpage, in fact, although other specific kludges needed to be removed from other points in the code.
FWIW, use_dirs.diff applies cleanly, and works well for me. Given that it makes this behaviour optional, how about merging it? I have some follow-up patches which I'm sitting on for now. ;-) -- Ben
How do you apply a patch created by svn diff? I've been curious about this for a long time. The use_dirs patch looks OK but I'd like to play with it. --Ethan
Just do svn co svn://ikiwiki.kitenet.net/ikiwiki/trunk ikiwiki then cd ikiwiki && patch -p0 <use_dirs.diff. :-) Same would work with a tarball as well.
Sorry, I'm dumb. I'm so used to doing -p1 that doing -p0 never occurred to me; I thought the patch format generated by svn diff was just "wrong". --Ethan
First pass over Tumov's patch -- which doesn't cleanly apply anymore, so
I'll attach an updated and modified version below. --[[Joey]]
-
As we discussed in email, this will break handling of foo/index.mdwn
pages. Needs to be changed to generate foo/index/index.html for such
pages (though not for the toplevel index).
Can someone elaborate on this? What's broken about it? Will pages
foo/index/index.html include foo/index in their parentlinks? --Ethan
Presently the patch does not move foo/index.type as foo/index/index.html, but renders
it as foo/index.html, not because I particularly want that (except for the top-level one, of
course), but because it could be done :). This, however, conflicts with a foo.mdwn
rendered as foo/index.html. The easiest and cleanest way to fix this, is to simply
not handle index in such a special manner -- except for the top-level one. --[[tuomov]]
Oh, I see, this patch doesn't address wanting to use foo/index.mdwn as
an input page. Hmm. --Ethan
No, it doesn't. I originally also was after that, but after discussing the
complexities of supporting that with Joey, came up with this simpler scheme
without many of those issues. It is the output that I primarily care about, anyway,
and I do, in fact, find the present input file organisation quite nice. The output
locations just aren't very good for conversion of an existing site to ikiwiki, and do
make for rather ugly URLs with the .html extensions. (I do often type some URLs
out of memory, when they're gone from the browser's completion history, and the
.html makes that more laboursome.)
I support your decision, but now this wiki page serves two different patches :).
Can we split them somehow?
What are the complexities involved?
I think I overcomplicated it a little with my patch, and Per Bothner's gets
much closer to the heart of it. --Ethan
-
This does make the resulting wikis much less browsable directly on the
filesystem, since dir to dir/index.html conversion is only handled by web
servers and so you end up browsing to a directory index all the time.
Wouldn't it be better to make the links themselves include the index.html?
(Although that would mean that [[bugs/broken_parentlinks]] would not be
fixed en passant by this patch..)
Yes, the sites are not that browsable on the FS (I blame the browsers
for being stupid!), but linking to the directory produces so much
cleaner URLs for the Web, that I specifically want it. This is,
after all, an optional arrangement.
It's optional for now ... I suppose that I could make adding the
index.html yet another option. I'm not that fond of optioons
however. --[[Joey]]
It is worth noting, that with this patch, you can render the local
copy in the present manner, while rendering the Web copy under
directories. So no extra options are really needed for local browsing,
unless you also want to serve the same copy over the Web, which I
doubt. --[[tuomov]]
-
Some of the generated links are missing the trailing / , which is
innefficient since it leads to a http redirect when clicking on that
link. Seems to be limited to ".." links, and possibly only to
parentlinks. (Already fixed it for "." links.)
> The solution seems to be to add to `urlto` the following snippet,
> which might also help with the next point. (Sorry, no updated patch
> yet. Should be on my way out in the cold anyway...)
if ( !length $to ) {
return baseurl($from);
}
>> Indeed, this brings the number of abs2rels closer to par, as well
>> as fixing the .. links. --[[Joey]]
-
It calles abs2rel about 16% more often with the patch, which makes it
a bit slower, since abs2rel is not very efficient. (This omits abs2rel
calls that might be memoized away already.) This seems to be due to one
extra abs2rel for the toplevel wiki page due to the nicely cleaned up code
in parentlinks -- so I'm not really complaining.. Especially since the
patch adds a new nice memoizable urlto.
-
The rss page name generation code seems unnecesarily roundabout, I'm sure
that can be cleaned up somehow, perhaps by making htmlpage more
generic.
Something like targetpage(basename, extension)?
Yes exactly. It might also be possible to remove htmlpage from the
plugin interface entirely (in favour of urlto), which would be a
good time to make such a changes. Not required to accept this patch
though.
[...] in fact, all uses of htmlpage in the plugins are used to
construct an absolute address: the absolute url in most cases, so an absurl
call could be added to be used instead of htmlpage
--[[tuomov]]
Or it could use urlto("index", $page) instead. --[[Joey]]
That is, however, a relative URL, and maybe an absolute one
is wanted. Perhaps urlto($targetpage) should return the
absolute version --[[tuomov]]
-
and something else in the
aggregate plugin (above), that I also think isn't what's wanted:
aren't foo.html pages also "rendered", so that they get moved as foo/index.html?
--[[tuomov]]
Yes, the aggregate plugin will save the files as foo.html in the
sourcedir, and that will result in foo/index.html in the web site, same
as any other page. --[[Joey]]
-
img.pm makes some assumptions about name of the page that will be
linking to the image, which are probably broken.
-
The changes to htmlpage's behavior probably call for the plugin
interface version number to be changed.
Latest version of my patch... with most of the stuff that's been discussed, including targetpage.
Also available here. (BTW, this posting, applying, and
updating of plain-old-diffs containing all the previous changes is starting to be painful. Reminds
me why I use darcs..) --[[tuomov]]
|
