Previous Entry Share Next Entry
jducoeur wrote in querki_project
Odds and ends today: I decided to blow through a bunch of minor bugs and enhancements that I'd recently added to the Issues Space.

Fixed sorting of DateTimes: this regression was a classic example of why I wish I had the time to unit-test more thoroughly. Turns out that when I rewrote _sort() a couple of months ago, I made it more precise and correct, which involved using a method which, on DateTime, I'd tossed off and never properly tested.

(Nota bene: under the hood, Querki's DateTime Type is built on the nscala-time library, which in turn is based on joda-time. Which is great, but it turns out to have two methods, named millis() and getMillis(), which not only aren't the same thing, they are totally not the same thing. The first, which I was using, returns the millisecond within the second of this timestamp -- a number from 0-999. The second, which I had *intended* to use, returns the number of milliseconds since the epoch -- a very large number.)

Properties now use the Advanced Editor again: remember how I changed things a few days ago, so that all Instances use the Thing Editor? Well, an unintended consequence arose -- Properties are, technically, all Instances. And the Thing Editor isn't *quite* useless on Properties, but it's pretty close.

In the medium term, we'll be adding a consistent Property Editor -- a nice powerful wizard adapted from the Create New Property pane of the Advanced Editor. But for now, I've just changed it back so that Properties use the Advanced Editor like they used to. That's ugly, but it works.

Made the Thing Editor's Done button more reliable: The Thing Editor recently developed a "Done" button, which proves to be very useful -- while it doesn't save anything per se (everything gets saved as you change it), it says that you are done and takes you to this Thing. However, that button proved flaky in the presence of the Name Property: if you edited the Link Name of this Thing, then the link behind that Done button would no longer be right, and it would just fail.

So I've changed the Done button to always use the OID version of the URL for this Thing. That's less pretty, but since it never changes, it's nice and reliable.

To support this, I've added the new _oidLink() function. Given a Thing, this produces the "hard" Link to that Thing -- the OID-based version that is guaranteed to not change. I don't expect it to often be relevant, but keep it in mind if you expect your Link Names to change frequently.

Made Lists sortable on Mobile: this is a longstanding problem, which has been bothering me more and more. Querki Lists are ordered, and you can rearrange the order to suit yourself -- that's basically the point. That rearrangement is drag-and-drop, of course -- that's what everyone expects. Only one problem: the jQuery UI library on which this is built (using the Sortable component) completely fails to understand touchscreens. When you try to drag an element, it instead scrolls the page.

In the long run, I suspect I'm going to rewrite this library from scratch myself, to make it natively understand touch -- mobile is important to Querki, and we want to do it well. But for the time being, I found a delightful shim named TouchPunch (so named because it "duck punches" jQuery UI), which maps touch events into terms that jQuery UI understands. It's not perfect -- it's kind of slow on my phone -- but it's a heck of a lot better than nothing, and gets us working. Anyone using jQuery UI should give it a look.

Made Is a Choice non-inherited, by adding Model Only: the Is a Choice Property should be applied to any Model that you want to be a "Choice": that is, its Instances serve as a list of options that the user can choose among.

That works well, but has one curious problem: the Is a Choice Property itself then shows up on the Instances, because that's how Querki's inheritance model works. But in this case we really don't want that -- this Property is really just talking about the Model, and just gets in the way on the Instances. In particular, Is a Choice was showing up in the Thing Editor, where it is totally meaningless.

To deal with this, I've added the new Model Only Property. You can apply that to any Property, and it says, "This Property is only talking about the Model, and shouldn't be considered to even exist on the Instances." I'm not sure how often this is ever going to be useful outside system code, but as always, Querki tries to play fair and give you access to the same tools that I have.

Added the Choice Order Property: Choices are great, but their UI has a long-standing weakness -- they display in alphabetical order. That's usually correct for generic Links, but Choices often have an implied order that has nothing to do with alphabetical. (Eg, "Excellent", "Great", "Fair", "Bad".)

So the new Choice Order Property lets you deal with this. This is a List of Links that you put on the Choice's Model, and should specify all of the Choices you want to use, in order. If it is present, we will use that list when we ask the user which option they want.

Mind, all of this is likely to get hidden behind a Choice Wizard in the not-too-distant future, to make it easier to define and maintain a Choice. But first things first.

_createButton now behaves like a proper Link: For historical reasons, the button displayed by the _createButton() function has always been a fancy AJAX control. That was okay in most ways, but had one major weakness -- you couldn't right-click on it and say, "Open in new tab". And I find that I frequently want to do that.

So since the historical reasons are no longer important, I've changed this to be an ordinary link. It still *looks* like a button, mind, but it behaves like a link in your browser, so you can open it in a new tab just as you would do for any other link.

Made the Done Button only show up when editing a Thing: another unforeseen consequence -- *all* Thing Editors have been showing the new "Done" button. That includes the Editors for Model Values, which look and behave a lot like Things but aren't. So you would get Done buttons that didn't actually do anything meaningful. This is now fixed: the Done button only shows if you are editing an actual Thing that you can go to.

Made Optional YesNo Properties work in the Advanced Editor: this is a downright *ancient* bug, dating all the way back to the original Wedding Space 18 months ago. If you specify that a Property is Optional YesNo, it shows a fancy three-value control, with options of "Yes", "Maybe" and "No". That has always worked great when you use it with the _edit() function, but has never worked if you tried to edit it in the Advanced Editor.

The problem underlying this is that we're using Bootstrap's pseudo-radio button groups. Those look and behave pretty well, but they have one problem: they aren't *actually* radio buttons, and don't work like radio buttons when you use them in a form.

I've hacked around this -- the fix requires a dash of Javascript, but heaven knows the system requires lots of Javascript already, so that's not exactly crossing the Rubicon. So Optional YesNo Properties should now work correctly in the Advanced Editor, as expected.


Log in

No account? Create an account