Previous Entry Share Next Entry
Release 0.3.16
device
jducoeur wrote in querki_project
Today's Querki release is pretty small from a user-visible viewpoint, although it was actually a lot more code changed than average:
  • The standard view of all Things now shows a link to the Thing's Model, in small print in parentheses under its Name. This is a feature I kept finding myself wanting, so I suspect others will find it useful.

  • Bugfix: Now that you can easily get to the System Space and look at the Things in it, changed things so that you can't edit anything inherited from another Space. (This will eventually become sort of possible, as discussed last week.)

  • Bugfix: When you reify a Tag -- that is, you go to a page for an undefined Tag, and say "Edit", which actually creates a Thing for that Tag -- the initial Display Text is now taken from the Space's Show Unknown Name Property, which is what you actually expect it to be. (So saying Edit then Done results in a page that looks exactly like before, except that now it is a real Thing.) Previously, it was always using the default text, even if you had overridden it in this Space.

  • Bugfix: Previously, when you edited a one-line Text field containing a single quote / apostrophe, it would get cut off at the apostrophe. This is why invitees to my wedding saw the Subject of the most recent info email as "More information about Katherine and Mark" -- the "'s Wedding" at the end got lost.
The bulk of the code changes were actually internal refactoring; the rest of this is only relevant to the programmers who might be curious about the internals.

Internally, Querki's most important datatype was PropValue -- the value of a particular Property on a particular Thing. This described a Collection of ElemValues, but it did *not* anywhere contain the Type of that value. The original theory was that that was unnecessary, since the value would be contextualized by the Property it came from, which knows about the Type. In practice, however, that theory proved to be just plain wrong. In particular, once you get into the QL pipeline, you have lots of intermediate values that *don't* come directly from a Property. So I had to invent TypedValue as a wrapper around PropValue-plus-Type, and the code started to get very convoluted, with lots of indirections to use the right type.

So I finally gave that up as the bad idea that it always was. I merged PropValue and TypedValue, renaming the combination as the more-neutral QValue, and placing the Type in there. I also added the Type to each ElemValue, which costs some memory space but makes a lot of code *much* simpler and safer -- basically, the objects in the system now know what they are, and do some internal type-checking.

As is usual for a good refactoring, the overall result was about a hundred fewer lines of code overall, and many remaining lines were simplified. Took me longer than I had hoped (better part of last week), but it should make things much more robust, so it should be a good investment of time.
Tags:

?

Log in

No account? Create an account