Previous Entry Share Next Entry
Names now work like wikitext
jducoeur wrote in querki_project
Oh, a minor side-note to the Tags discussion from last week.

You remember how I mentioned the realization that you needed to be able to use a Tag that wasn't defined? Which meant that a Tag is simply a Name, without the requirement that that Name be an actual Thing?

Well, as I was editing the Poker space, I realized that I was getting annoyed by the order of events -- specifically, I wanted to be able to refer to a page as "[[My Page]]" *before* defining it. This is, after all, how I usually work in a wiki: I write high-level pages that refer to the lower-level ones, then go back later and fill in the missing pages. But that didn't work in Querki: it was giving me "Unknown Name" errors where I did that. They'd resolve themselves after I wrote the other page, but it was annoying in the meantime.

And, it occurred to me, it was now completely unnecessary -- if the Tag system can refer to undefined pages, there's no reason you can't just do that with any other link.

So I've made things work consistently, and pretty much the way you expect from a typical wiki. When you write a reference like that, if the system can't find it (and therefore, can't find an _apply method to use for it), it just generates a link to that name. If you click the link, you get a generated page that lets you create the Thing.

It needs some work yet -- the workflow doesn't yet have a way to specify a particular Model when you create the Thing this way, and I still want to add a style tag so that undefined links are highlighted somehow. But folks should find the workflow mostly intuitive at this point, and we're getting closer to one of the basic goals: Querki should be a proper superset of Wiki. You can do everything you can in a typical wiki, and a hell of a lot more...

  • 1
I've just finished reading the 'How It Works' for the Poker Variants. I'm worried I've missed something. At one point you reference [[Name]] and explain that it references the property of the thing itself. What happens if I invent a poker game called Name ? Will [[Name]] break? How will it resolve between referencing a property and referencing a Thing?

Not possible, frankly, and that's a deliberate decision: within a Space, the namespace is flat -- everything shares the same pool of Names. There can only be one Thing named [[Name]]. (And yes, that means that system-level Properties are effectively reserved words. This is why I've moved to the convention of _propName for global methods and properties that aren't absolutely central.) You *could* have a Space-level Thing named Name overriding that, but I wouldn't recommend that -- the potential for confusion is kind of horrible.

This will *very* occasionally be inconvenient, but at the small scale Querki is designed for I expect that to be unusual, and usually work-aroundable. (This is part of why I changed things to allow slash-delimited paths -- so if you *expect* to have a dense namespace, you can break it up. And the medium-term plan is that you could, eg, use System::Name vs. Poker::Name to distinguish them, but I consider that a *very* advanced feature.)

It has big advantages, especially in supporting the absolutely groundrock principle that Everything Is A Thing. Editing a Property, a Type, or even a Collection is, in principle, just like editing an ordinary Thing. This allows all sorts of DWIMmitude that many languages have problems with. (For example, adding complex meta-Properties to nuance the behaviour of a Property is simply adding a Property.) And for the average user, I believe it will be an advantage that a given name always means the same thing within this Space, just in terms of comprehension -- that's really the main reason I decided to go this way.

But yes, you're reading it correctly. I've been conscious from the very start that this flat namespace is probably the most contentious decision I've made, but I *think* it's correct for this system...

I'm inclined to agree that the DWIM approach wins out 90+% of the time. Very few people will knowingly run into a collision like that.

And I would bet good money that the path of least resistance for most everyone, knowledgable or not, will be to simply choose a new name for one of the Things to avoid the collision.

I've used namespace approaches in wikis that support multiple namespaces, and they have their uses, but never really as a way to disambiguate between pages, but as a way to manage the backend of things, like permissions, workflows, search scopes, etc. You know, those places where a wiki starts trying to be more than a wiki.

Yaas. The slash-delimited sub-Spaces are mostly there "for future use". At the moment I know that they are too buggy to use safely, but I want to make sure we have them as room to grow...

  • 1

Log in

No account? Create an account