Previous Entry Share Next Entry
jducoeur wrote in querki_project
Lots more smaller enhancements and fixes for things that have been bugging me...

Completely changed the rendering of Models: this was one of those cases where I started playing with one string in the ball of twine and it all came apart in my hands. But I think the results are a major improvement.

First, and most importantly, I introduced the new Model View Property. This addresses a point that mindways made a few months ago, and which I eventually decided he was right about: you generally *don't* want your Model's page to look the same as the pages for its Instances. The Model usually has empty default data, which makes it render oddly. And frankly, what you are *interested* in about the Model isn't the same as for Instances.

The way you've always controlled the look and feel of a Thing is through the Default View Property, which says how to render this Thing. That's still true for Instances, but is *not* true of Models. Instead, Models look for the new Model View Property. That only says how to render Models, and is not used for Instances; it is mutually exclusive with Default View. If there is no Model View defined (and I expect that you usually won't want to bother), then it does the default rendering instead.

Second, I rewrote the default rendering of pages. That is, I changed the way things look if you don't have the Default or Model View defined. Conceptually it's still the same as it used to be -- it lists all of the defined Properties and their values. But it now lists them in alphabetical order, which makes the list a lot less confusing. Each Property name links to the definition of the Property, so you can more easily remind yourself of what's what. And Text fields now display in their raw, unprocessed form -- you see the literal QL expressions rather than their processed form. (This last might yet get tweaked further. I believe it is correct for Models, but I suspect not for Instances. We'll see what it feels like.)

To support that, I introduced the new _rawVal function. I suspect you'll never want this, but it's part of "Querki plays fair": it is the official way to get at the unprocessed definition of a Value.

Finally, there is the point of the exercise, which is that Models now list their Instances. This is only by default, if you don't define a Model View, but it's bloody useful. Among other things, it means that from an Instance, you can simply click on the link to the Model and see all the other Instances. Quick and easy, and something I've found myself wanting frequently.

All of this is subject to lots of change, but I'm starting to take the details of ease of use more seriously, now that the broad strokes of the system are mostly working. Your observations and suggestions would be happily welcome.

Design a Model now results in a Model: this fixes a long-standing annoyance. Internally, the only real difference between a Model and an Instance is whether the "Is a Model" Property is checked. But they are increasingly different in the way you think about them, and the single most common mistake I make in Querki is forgetting to check that stupid box.

That problem was necessary while you got to everything from "Create any Thing". But now that we're split "Design a Model" out into its own menu pick, that no longer makes any sense. So I've changed things so that "Design a Model" now pre-selects Is a Model, and you no longer need to worry about doing so manually. (In the not-too-distant future, we'll stop showing that checkbox entirely.)

"Parent"s can now create "Children" that link back to them: it's not really surprising that many problems turn out to involve parent-child relationships, where you have one Foo that contains a bunch of Bars as children. That relationship is represented by Bar having a link to Foo, which is nice and easy. But there is a longstanding weakness: my Foo can have a _createButton to create a Bar -- but then, when I am editing the Bar, I have to manually set the link back to the Foo. That gets really tiring really fast.

I've introduced a first-draft fix for this, by tweaking _createInstanceLink and _createButton. The syntax is now:
[[Some Model -> My Parent Link._createButton(""Make another"")]]
The new bit is that you can put My Parent Link in there. This basically says, "In the newly-created child, set the My Parent Link property to point back to me". It's not quite as DWIMmish as I'd like -- there may be a better long-term solution where you define the relationship between the types and it just susses this stuff -- but it's a lot better than the status quo.

I can now change the Role of an Invitee: fixing a dumb oversight. You could set someone's Role when you invited them, and you could change their Role after they joined, but you couldn't change it *before* they joined. This is now more consistent.

You can now _sort the properties you get from _foreachProperty: _foreachProperty produces a list of the properties and values on a given thing; this is currently the main tool available for introspection. Previously, though, the properties were in random order, and _sort would crash. _sort now works properly. (I've added the necessary method implementation to make this work.)

Next: probably a pause while I do some digging into scala.js. It's time to seriously shake up the UI...


Log in

No account? Create an account