The big(ish) one: Typos in QL Expressions now raise errors. This requires some explanation, both to illustrate how things previously worked and how they now work.
The thing is, Querki was originally conceived as a wiki that you could run queries on. (The name is short for "Queryable Wiki".) The QL language was designed to be a more-powerful version of what you put in brackets in a typical wiki, so if you said [[My Page]], that would give you a link to that Page. And like a wiki, if you said that and "My Page" didn't exist yet, it would still produce a clickable link, so you could create it. Querki aped that functionality pretty exactly: if "My Page" didn't exist, it would be treated as a Tag -- you could click on it, and the Edit button on its page would actually create it.
The problem there is that, since *any* name could be treated as a valid Tag, there was no way in QL to detect typos. For example, in the error that led to me thinking about this, he typed
__isEmpty, with two underscores instead of one, in an expression. A simple typo, but not an easy one to notice on the screen, and the results in the expression were bizarre and confusing -- there was no good way to realize what was wrong.
Add to that the fact that the originally-intended use case, of being able to easily write the name on the page first and then define it later, is now fairly unusual in Querki. The only place it was ever common was on the main page of the Space, to list the main sub-pages. But now that new Spaces list all of their Pages by default, you rarely need to do this any more.
So: I'm officially tweaking the semantics of QL. If a name appears in a QL expression, and it doesn't exist as *either* the name of an actual Thing or a Tag that is in use, we will now treat it as an error, and display it as such. This means that this sort of common typo now shows up as a nice clear error.
Just in case anybody *really* wants to use a not-yet-defined name in a QL expression, there is a workaround, the backtick syntax. You can say
[[`My Page`]], in backticks, and it will *always* be treated as a Tag. This actually isn't new -- it's been around for a year or so, as the way to use a display name in QL that includes illegal characters -- but from here on I'm going to call this the Tag Literal syntax.
Related to that: QL errors are now better-contained. Heretofore, the entire page has basically been treated as one big QL expression; if you had an error in a QL expression *on* the page, all that would display would be that error, and the rest of the page wouldn't show at all. This made it harder to understand where the error was, since you lost the context. And frankly, it was ugly and annoying.
So things have now been tweaked to make more sense -- all of the QText will be rendered normally, and the QL error will be displayed in-place. I think this will make errors a little bit easier to understand and less ugly, and it means that you *can* write the referencing link first, and define it later; it'll just show as an error on the page for now.
Missing function parameters are now treated as an empty value. Alexx' observation was that he expected to be able to say
and have that work as expected -- it would display "false" only if_if(something,,""false"")
somethingwas false, and wouldn't show anything if it was true. In fact, it was giving an Unexpected Error, and the page was failing to load, which is Querki for "something's broken here". (If you ever see Unexpected Error, please tell me: by definition, that's a bug.)
I really had never planned for this syntax, but it seems reasonable to want, and it provides a convenient way to say "this is empty". So this syntax is now officially sanctioned, and fully tested in the case of
_if(). Please tell me if you come across places where it doesn't work as expected.
_textLength can now take a parameter. The error here was that Alexx was trying to do something like
and was getting mysterious results like 32. I confess, I spent quite a while scratching my head over this before realizing that_textLength(""Hello"")
_textLengthdoesn't *take* parameters -- the only legal way to use it is something like
The desired approach was clearly reasonable, though, so I've made it so that the function can now take a parameter, and will use it if provided; it will use the received value if there is no parameter. I've also added a story, to be dealt with later, to raise an error if you provide a parameter to a function that doesn't accept one, which should make situations like this less mysterious.""Hello"" -> _textLength
While loading a Space, show the Space's name. A detail suggested by Aaron, to provide slightly better user feedback.
Up/down arrows now work more consistently. In a few places (notably, the Name field when creating a Property), if you pressed the up or down arrow keys, they would do nothing; normally, in a single-line field, they should go to the beginning or end of the line. This was a regression due to the recent change to prevent illegal Property names, and should now work correctly.
Finally, there were fixes to a couple of minor documentation bugs.