Now that we've got more folks playing seriously with the system (especially thanks to Alexx, who has been enormously helpful in the past couple of days), we're identifying lots of problems. So today was mostly about bug-fixes, or adding features that are so stupidly apparent they might as well be bugs.Fixed empty Display Names (and introduced Validation meta-Properties) (bug .3y284r2)
: This one has always been true -- I'm astonished I hadn't hit it yet. It turns out that giving a Thing a blank Display Name -- that is, adding the Display Name Property but not putting anything in it -- produces *horrible* mal-effects. Since the Display Name is what we use to show this Thing in lists everywhere, you can't *see* the Thing any more. So there isn't even anything you can click on to fix the problem!
I actually started out fixing this with a bit of a hack (adding a NonEmptyPlainTextType for DisplayName
), but decided that I'm no longer willing to give myself the leeway of quick-and-dirty when I can avoid it. So I instead made a more substantial enhancement
, which basically gives us the ability to write Type Validators that can use meta-Properties. And then I used that to add a new Minimum Text Length Property.
So this is now available for general (if advanced) use. If you have a Textual Property (Text, Large Text or Plain Text), you can add the Minimum Text Length meta-Property to that. That length will be enforced by save, so it gives an error if you try to save a Thing with a too-short Text field. Display Name now has a Minimum Text Length of 1.
This is the camel's nose in the tent of *seriously* powerful property validators. It is now reasonably straightforward to add meta-Properties for anything from clamping a Number Property to positive numbers, to limiting a List to a maximum of 10 elements. I'm not going to go hog-wild and add everything I can think of (I can think of a *lot* of uses for this), but when you come across validations you specifically want in your use cases, feel free to request them.Added True and False (bug .3y284sb)
: yes, really -- I've spent nine months working in a programming language that didn't have literals for "true" and "false". In practice, I find that I need them surprisingly rarely -- indeed, the times when I want them are mainly when I am testing a persnickety bit of QL, and want to stub out a questionable clause. I've just been hacking around that when I needed it (you can actually define True and False yourself), but Alexx was assuming they existed in his tests, and in retrospect that's an entirely reasonable assumption.
So we now have True and False defined at the system level. These are technically Things that evaluate to the appropriate values, but you can basically treat them as system constants. I wrote unit tests to confirm that _if and _equals work as expected; I don't expect any surprises here.
(Technically, you can override these names in a Space. I don't recommend doing so, but Querki does give you enough rope to hang yourself if you are so motivated. We might eventually add the ability to create a non-overrideable Thing, so that we can reserve words, but for now we're leaving that to convention. Please do not reverse the values in the Alpha Sandbox, but feel free to go wild and crazy in your own Spaces.)Made _sort work better (bug .3y284sa)
: This one I found, while writing the Issues by Submitter page. (More on that in a second.) It turns out that, quite to my surprise, _sort failed horribly when applied to Text Properties in many fairly ordinary circumstances. This was surprising because I thought I'd written the comparers for those types -- but it turns out, they're the wrong Types. By the time _sort actually *gets* to a Text value, it has already been turned into wikitext, which is technically the internal ParsedTextType -- which didn't have a comparer, and so we were getting an internal exception. This is now fixed
-- you should be able to sort on Text and Large Text Properties, and it should do the right thing. Please tell me if you find seams.
Along the way, I found that an intentional design decision I made recently turns out to be a pain in the ass. _sort deliberately failed if a value it was trying to sort on turned out to be empty. That makes sense in the lovely, pure programmer world, but in the intentionally messy world of Querki that's just a headache -- it is entirely common to want to sort a bunch of things on an expression that isn't necessarily defined on all of them.
So I've made _sort cleverer
-- so long as it understands the Type being sorted (which I think it should usually), it will sort empty values as if they were the default value of that Type. So for example, if the value is textual, it will wind up sorting as empty string. I suspect we'll want to enhance this down the road (for example, to let you say explicitly whether empty values sort to the beginning or end), but it should be good enough for now.Added the Issues by Submitter page
: this was what I was doing all the sorting for. This page lists all of the existing Issues, sorted by who submitted them. It is intended to make it easier for y'all to keep track of the status of your submissions.
(Yes, this really ought to be neater, with a section for each submitter. I can't quite build that yet, which annoys me -- I'll need to make some enhancements to make that possible.)
Note, BTW, that this page isn't a Thing of its own -- it's an Alternate View of the main Space Thing. I encourage the hardcore folks to take a look at how this works, but the high concept is that you can easily just display any Large Text Property as a page unto itself, which makes a quick and easy way to build Alternate Views. (Yes, I'm open to introducing a first-class notion of tabs for these, but it'll be a while yet.)Display OIDs
: this is a comparatively tiny change, and I didn't even bother to open an issue for it. Most people won't care, but it's useful to have.
Every Thing in Querki has three potential identifiers:
-- The Display Name, which is what usually shows up on-screen.
-- The Name, which is what gets used in URLs and the like.
-- The OID, which is the One True Unique ID of this Thing.
Note that, of these, the OID is the only identifier that is *stable*. Display Name is assumed to change frequently. I've been assuming that Name would be semi-stable -- but I'm planning to make Name usually just derive from Display Name, which means that it is also going to be relatively unstable.
The implication is that, if you want to be *sure* that a link points to the right Thing, you need to use the OID. So I've added the OID to the small-print subtitle line on the standard Thing display, underneath the Display Name header. That links to what amounts to the permalink for this Thing, using its OID instead of its Name.
It is *not* yet possible to use such references in ordinary QL, but we'll find that we need that. So I've opened an Issue for that
And no -- ordinary users aren't going to want to be bothered with this crap. In the medium-long term -- the second half of 2014 -- we'll be adding Querki Explorer, which is essentially an IDE for QL. That will deal with things like auto-prompting for names as you type them, and will silently substitute the OID under the hood in most cases. So eventually, the user will type and see a Display Name, but it will actually get *stored* as a stable OID.
*Whew* -- busy day. But this is the fun part, getting the system really humming for folks...