Previous Entry Share Next Entry
Release 1.3.2
jducoeur wrote in querki_project
The last release this week (and likely the last before the holidays) continues the trend of the previous one, dealing with a lot of little annoyances...


The biggest change continues with the renamings from yesterday, and finally deals with the big and nasty one: renamed the key Name Properties in Querki. A bit of history is in order here, to explain this change.

Once Upon a Time, when I was starting this project out, one of the first Properties ever created was, of course, Name. This was what a Thing was called from an internal POV, and follows some restrictive rules: since it is used for URLs and QL and stuff like that, Name was only allowed to contain basic characters: letters, numbers, spaces and dashes. From a techie's POV, that made perfectly good sense.

Problem is, it was inconvenient. You often want to use all sorts of other characters in names, I found. After not too much time, I decided that I needed another Property for this, which was called Display Name. This wasn't the official name of the Thing, mind -- that was still Name -- but it's the name that would show up in displays.

After a little more time, it quickly became clear that having to specify two name fields was vastly more trouble than it was worth (really, I had known that was going to happen). So the system got a new concept: the Name would be derived from the Display Name, if at all possible. That iterated several times, but we eventually got to the point where you usually just specify the Display Name, and the Name is automatically built from that.

At which point, the current terminology makes no sense. "Display Name" isn't a term that's terribly obvious, but it's the only name you care about most of the time, and "Name" is something you only use occasionally.

So I've finally bitten the bullet and switched things around. What used to be called "Name" is now "Link Name", and what used to be "Display Name" is now "Name". This better-reflects actual usage, and the way that, in practice, the "real" name is what used to be Display Name.

This change is *very* likely to cause bugs. (I had to fix a pile of unit tests.) My apologies for that, but it's better to make a change like this sooner rather than later, to minimize the impact. Please yell if you come across any bugs. (One known side-effect is that this change breaks any old XML exports. Fortunately, I have no reason to believe that affects anyone other than me.)

Along with that change (and the bugfix for single-value Tags below), the old Name Type is now internal-only. Name Type (now named Link Name Type) exists for technical reasons, but is effectively just a primitive version of Tag. I don't believe there's ever a good reason to use it instead of Tag, so it's no longer available for user Properties.

Types now display their documentation properly. While there has been a Type Reference page in the Documentation for a long time, the Types have never displayed as well-formed pages: they simply showed their own Properties, which was kind of sad. Types now have a Default View (like everything else), so they display properly. Also, if you look at a Type in your Space (say, by following the link from a Property's page), it will now display all of the Properties that use that Type in this Space.

Finally, I made a change I've been contemplating for a long time: when you remove a Property from a Thing, if the Property is no longer used, it is automatically deleted. This is dramatic, but I *think* it's always correct. (If you come up with a realistic exception, please tell me.) It's convenient, and in particular it makes one common workflow much easier. It turns out that the most common reason to remove a Property from a Model is because you screwed up its definition -- you gave it the wrong Type or Collection. (This happens to me pretty often.) Since you're not allowed to have multiple Properties with the same Name, this meant that, to fix your mistake you had to remove the Property from the Model; go to All Properties; select the broken Property; delete it; then go back to your Model and add it the way you wanted. Now, removing the Property simply makes it go away completely.

This only happens if *nothing* is using the Property any more. Note that, if you already created Instances that are using this Property, you have to remove it from them as well. (We're deliberately conservative about this, lest you lose data unintentionally.) And it doesn't apply to "shadow Properties" that are inherited from Apps. But in the most common case, it simply does the right thing.

Bug Fixes

Single-valued Tags now work properly. There was a regression, probably quite some time ago, which was resulting in single-valued Tags (ExactlyOne or Optional) displaying correctly but not actually saving their values. This snuck through for a long time because I rarely use single-valued Tags and don't recommend them. (IMO, Tag Sets are usually the way to go.) This is now fixed.

Fixed the documentation pages for many functions. Suffice it to say, functions that don't have Signatures were displaying errors on their documentation. This should all be correct again.

_instances now gives proper errors. I discovered that, if you passed a non-Thing to _instances (which can happen if, for example, you misspell the Model's name), it resulted in an Internal Error message. This now gives a somewhat more useful error message.


Log in

No account? Create an account