Previous Entry Share Next Entry
Release 0.6.7
jducoeur wrote in querki_project
This week is largely devoted to bugfixes, but first, let's finish up last week's conversation.

Since mindways' project actually needs to *do* something with numbers, instead of just recording them, I finally got around to adding the functions _lessThan() and _greaterThan(), as variations of _equals(). Moreover, I enhanced them to make the first parameter optional. Where you previously had to say something like:
[[My Thing -> _if(_equals(My Prop, ""hello""))]]
you can now instead say:
[[My Thing -> My Prop -> _if(_equals(""hello""))]]
That is, if you only provide one parameter to _equals, _lessThan or _greaterThan, they will use the received context as the left-hand side of the comparison. This should make some pipelines easier to write clearly, especially when you combine this with, eg, _filter. It even allows you to get something a little closer to infix syntax, if that suits you:
[[My List -> _filter(Count -> _greaterThan(3))]]
(I do plan on adding ordinary infix binary operators like < and == in due course. If it starts becoming a serious issue for you, please mention it and I'll consider bumping it up the priority list.)

I'm planning to be consistent about this general paradigm, where the left-hand side of a binary function can either be a parameter or the received context; if you find somewhere that you expect this to work and it doesn't, please point it out.

I also finally added integer literals to QL. Nothing surprising or fancy here -- it just allows you to say things like:
[[My Thing -> _if(_greaterThan(Count, 5))]]
and it will do the right thing. (It has been interesting to note that we got fully 18 months into this project before I began to feel like integer literals were necessary.)

Bugfix -- New Tags now "take effect" immediately: folks using Tag Sets might have noticed, especially in Edit All Instances, that when you added a new Tag (that hadn't been used before), and then tabbed to another field, you wouldn't be offered the new Tag. You had to reload the page before the new Tag showed up in the prompts.

This was a client-side caching problem. MarcoPolo, the open-source package that handles all that lovely prompting, does a lot of clever caching in the browser: if it has already sent a request for a particular string, it doesn't do so again. Problem was, this was getting in the way of recognizing that we'd added a new value. So I've enhanced that to invalidate the cache when you ignore the prompts and add a new value.

Bugfix -- fixed "Things that use [property name]": when you look at a Property (via the Actions -> Show All Properties page), it is supposed to display all of the Things that have this Property defined on them. This is generally useful, and crucial if you want to delete a Property -- you must remove all uses before the system will allow you to delete the Property, to prevent Space corruption. (Yes, this will become automated eventually; one step at a time.) However, this list of references got broken somewhere along the line, possibly due to my tweaking of the semantics of $_context a few weeks ago. It is now fixed, so you can see exactly which Things use this Property.

Bugfix -- you can now edit Instance-local Properties despite the Instance Properties: this one is a hair complex, but important. Instance Properties is one of the most important properties a Model can have: it says exactly which Properties the Model *expects* to be different on each Instance. That way, when you are editing an Instance, you don't have to deal with the Properties that are really just on the Model, and shouldn't be changed per-Instance, nor the minor Properties like _deriveName that you will usually ignore. It's quite useful, and will be baked deeply into the Model Editor when I get the time to rewrite that.

But it introduced a major edge-case problem: what if the Instance has its *own* Properties? Querki intentionally allows that -- the loose data model lets you do powerful stuff this way. But if the Model had Instance Properties set, you wouldn't be able to see those Instance-local Properties in the Editor, which was a Problem. Worse, it was easy to land in this situation through simple Model evolution. Say you have a Model with Property P, and some of the Instances have their own values of P set. Now, you remove P from the Model. That does *not* remove P from the Instances (intentionally, although we probably need to add a flag to let you do that as well if you want). Now you have a bunch of Instances that still have P set -- but you couldn't edit P on them!

This is now changed. If an Instance has its own Properties, they will *always* be shown at the end of the Editor (both the old-style Editor and the newer "live" Editor), after the Model-defined Instance Properties, so you can edit them.

Bugfix -- you can now delete Instance Properties despite the Instance Properties: related to the previous, but actually completely different code (and somewhat more challenging to fix) -- even once you could edit the Instance-local Properties, you couldn't delete them successfully. Much worse (but subtler, so it took me a while to notice), you couldn't even clear the local copy of a Property and go back to inheriting from the Model! It would look like you had succeeded, but when you went back into the Editor you would find that you were still overriding the old value.

Suffice it to say, this was a subtle problem in the way that the browser, server front end and server back end were talking to each other -- these simply was no mechanism in one particular pathway to say "delete this Property", so it was getting lost. That is now fixed, and you should be able to delete Instance-local Properties, and revert inherited ones, in the presence of the Instance Properties list. This should fix some tearing-out-hair-grade problems that everyone (including me) has been having when they tried to make significant changes to their Spaces.


Log in

No account? Create an account