[Phpwiki-talk] bugfix, db schema, thoughts on navigation

[Arno H. <aho...@in...>]

Hi,

just uploaded another fix for obscure "[[link] [link]" problem.

Btw, the whole issue about "[" is pretty much a usability nightmare.
I.e. "[[ some text \n more text]" renders as "[["  (\n = linebreak)
"[[ some text more text]" renders as "["
"] text [[" renders as "[",
"[[text] [[more here" renders as "["+"[[".
All this is pretty inconsistant. Also, it's impossible to have "]"
within "[[]" or "[]" for that matter. (I know the regexps, so need to
tell me why phpwiki behaves so weird :o)

But getting to the point:
I guess we should set us some achievable goals for the 1.2 release so
that we don't wander around aimlessly. Also, we should consider not to 
overdo it, as too much functionality is not a good thing.

The way I see things, the main goal for 1.2 is the new DB schema and
the slew of functionality this entails.
Templates are nice, but don't have high priority. Especially I think
that using something similar to free-energy is overkill. We don't need 
more than a simple replacement of placeholders, do we?

So here's again the current state of the db schema:

CREATE TABLE wiki (
	pagename VARCHAR(100) NOT NULL,
	version INT NOT NULL DEFAULT 1,
	flags INT NOT NULL DEFAULT 0,
	author VARCHAR(100),
	lastmodified INT NOT NULL,
	created INT NOT NULL,		# optional
	content MEDIUMTEXT NOT NULL,
	refs TEXT,			# refs are serialized
	PRIMARY KEY (pagename)
	);

CREATE TABLE archive (
	pagename VARCHAR(100) NOT NULL,
	content MEDIUMTEXT NOT NULL,
	refs TEXT,
	author VARCHAR(100),		# I guess those two columns
	lastmodified INT NOT NULL	# are nice to have
	PRIMARY KEY (pagename)
	);

CREATE TABLE wikilinks (
	frompage VARCHAR(100) NOT NULL,
	topage VARCHAR(100) NOT NULL,
	PRIMARY KEY (frompage, topage)
	);

CREATE TABLE hottopics (		# optional table
	pagename VARCHAR(100) NOT NULL,
	lastmodified INT NOT NULL
	PRIMARY KEY (pagename, lastmodified)
	);

CREATE TABLE hitcount (			# optional table
	pagename VARCHAR(100) NOT NULL,	# hits are in separate table in
	hits INT NOT NULL DEFAULT 0,	# order to avoid locking our
	PRIMARY KEY (pagename)		# main wiki table
	);



What about categories and paths?
There's a simplistic approach to both of them - similar to the way
c2-wiki currently realizes categories through backlinks.
While I'm still pretty fond of paths I'm not sure about
categories anymore. The more I think about them, the more I dislike
them. If people feel they really need them, they can create them
easily by what is already provided through wiki. Adding a formal
category mechanism creates more trouble than benefits. Just have a
look at c2.com: the most compelling "category" pages are not those lists 
of backlinks, but pages like e.g. ExtremeProgrammingRoadmap.
(Actually, the same might hold true for paths, I'm not sure yet)

I envision wiki more like a cloud, where several paths lead into it
and the deeper you go, the more misty it becomes, and soon you wander
off your path following hyperlinks. Sure, it's unstructured, it's
chaotic. But to that end: use your browsers back button. Or
alternatively, the wiki could give you a cookie and create a map of
pages visited on the fly. Better yet, try to come up with a
search not based on words, but on links (and the pagerank) that
shows you related or important pages within reach.
Navigation like this is far more useful than trying to press a highly 
dynamic site into rigid categories.

I guess I stop my rant here. I've rewritten the above paragraphs five
or six times - so you owe me to read them at least twice and spend
some time thinking about them ;o)


/Arno

p.s. I'm gone for the weekend - so don't be suprised if I don't
answer emails until Wednesday.