Previous Entry Share Next Entry
Release 1.1.6
querki
jducoeur wrote in querki_project
Small release today; just barely qualifies as "minor" instead of "patch" (which I don't even bother posting here) because of the behavior changes to _QLButton. Wrapping together 1.1.5.1 and 1.1.6, which have mostly featured enhancements I made while working on the rewrite of the Period Games Space:


The most user-visible change was some tweaks to the behavior of _QLButton. _QLButton is an advanced but terribly useful function (which one of these days I should probably change the name of), which takes a label and a snippet of QL code, which means "when the user presses the button, run this QL and display the results". It allows you to only display part of the page initially, which both makes the page more compact and faster to display, since the QL expression doesn't get run until the button is pressed.

You can see this in action in the listing of All Games. This originally showed all links to all pages for all period games; it was, unsurprisingly, starting to get *very* long, and much too slow. (It was taking six whole seconds to display on average, which IMO is unacceptable.) So I rewrote it to show a _QLButton, like this:
[[_QLButton(""Show Links ([[_tagRefs -> _count]])"", _tagRefs -> Summary -> _bulleted)]]
This button is displayed for each Game; it shows a button that displays the *number* of _tagRefs (that is, the Links that point to this Game); when you press the button, it displays a bullet list of the Summary of each link.

This is the heaviest use I've made of _QLButton to date, and led me to make two changes:
  • First, I made the buttons smaller, so they don't take up extra visual space. They had been full-sized buttons, which turned out to be *very* bulky on-screen. (They're still a bit overwhelming visually when there are a lot of them, as in the All Games page; I'm pondering what to do about that.)

  • More importantly, the buttons are now modal. When you press it the first time, it shows the results; when you press it a second time, it hides that section again. I found that I reflexively expected that to be the behavior, so let's not fight it.
It's now working pretty nicely, so I encourage folks to make use of this feature.


I also did some heavy optimization of _tagRefs. Suffice it to say, I came to realize that a page like All Games could easily wind up O(n**2), or even O(n**3), because each instance of _tagRefs was iterating over every Thing in the Space. Each iteration doesn't take very long, but when you're showing hundreds of Things, that can add up pretty fast.

So I've finally bitten the bullet and sacrificed a *little* bit of functional-programming purity, introducing an on-demand cache inside of Spaces, which I expect to use in a number of places where it is worth spending some extra memory on speed improvements. (Yes, this cache is built specifically to be thread-safe, so it hopefully won't introduce any problems.) In this particular case, whenever we run _tagRefs, we store the results so that we don't have to run it again until the Space changes.

None of which should be visible to you except that some complex nested pages should now render a bit faster.


Fixed:
  • I discovered that Sets of Text have been crashing in the Editor for a while now. I don't actually recommend using Set of Text (it's not very meaningful; you should really use List of Text instead), but it shouldn't crash. That's now fixed.

  • Backtags now work more reliably. A "backtag" is like a backlink -- if Thing Foo says [[Bar -> Tag Prop._createButton(""Make a Bar"")]], it means that we show a button to create a Bar, setting Bar's "Tag Prop" to Foo. This makes it easy to create parent-child relationships, which turn out to be very, very common in Querki. But the actual tag created was sometimes a bit wrong (in particular, spaces weren't handled correctly). This is now fixed.
Tags:

?

Log in

No account? Create an account