Previous Entry Share Next Entry
Release 0.4.4
jducoeur wrote in querki_project
Chugging right along, a bunch more tweaks and bugfixes before the weekend.

Create Instance button on Models (bug .3y284t9): Based on a suggestion from Alexx. (Who is, BTW, nicely illustrating the principle of "the squeaky wheel gets the grease". I have lots of grand ideas, but I care *passionately* about what real end users need. Alexx has been building a real Space, and observing what he needs to do so, and where the pain points are. Those don't *quite* trump everything else, but they tend to wind up high on the priority list -- especially when, as in this case, it is something that I had kind of been thinking about myself but not getting around to. Anyway...)

This one's a tiny enhancement, but quite useful for improving workflows. When you are looking at a Model, there is now a new "Create" button (that looks like a plus sign), next to the existing "Edit" button. Small thing, but it saves thought and clicks.

Tag Sets now respect the Link Model (bug .3y284ok): Alexx noticed that, contrary to my claims, when he created a Tag Set with a Link Model, he was still getting prompted with *all* matching Things when he typed in a Tag, not just the ones in the Link Model. This mystified me, until I looked at the code and realized I had never finished implementing Link Models. Duh.

Tag Sets now work much like Link Sets -- if you specify a Link Model, the Tag suggestions will confine themselves to Things of that Model. (Or existing Tags that you have previously used on this Property.) If you're building a Space of any serious size, I recommend setting up Models to match the semantics of your Tags in advance -- that makes it very easy to do something real with those Tags later, and helps keep straight what's what.

Fixed special HTML characters in Display Name (bug .3y284ob): a *lot* of people noticed that apostrophes in Display Names were showing up incorrectly (as spelled-out HTML entities); Talvin went through and confirmed that the problem existed for ', ", &, < and >, which confirmed my suspicion -- that all of the "dangerous" HTML characters were getting double-escaped.

This one was annoying and persnickety to fix. The problem, of course, was that I was being over-paranoid -- and worse, that my paranoia was getting mixed up with that of Play!, the underlying framework that Querki is built in. Play! assumes that everything is dangerous and evil unless you tell it otherwise, so I had to carefully go through and mark as safe the places where Querki was already internally HTML-neutering. (Which the displayName method does by default.)

Anyway, it is at least mostly licked -- I found a dozen or so places that needed to be fixed for this. If you spot any more cases where apostrophes or the like are showing up as HTML entities in the UI, please point them out to me.

Recognize that Names don't *really* include dashes: several folks have pointed out that the error message for badly-formed Names says that it includes "letters, digits, spaces and dashes", but when they try to use dashes, they go away. Fair enough. I think of dashes as being *legal* for Names, but the truth is that the system considers dashes and spaces to be equivalent, and substitutes them for each other quite freely. So in practice, Names really can have spaces for most purposes. (Which sometimes will be swapped for dashes as needed.) The error message has been updated accordingly.

Remove annoying Editor popups: one of those Terribly Clever Ideas I had early on was to have a tooltip prompt in the Editor, which would tell you the state of the Property you were hovering over -- whether it was inherited or overridden, and from what Model. It sounded nice in theory, but has proven to be *stunningly* annoying in practice -- it keeps popping up when you least want it, and doesn't give you the glanceability you want for this in the first place.

So that tooltip is just plain Gone now. It'll be replaced by something else in the upcoming Editor rewrite -- I'm thinking possibly a subtle background tone that indicates whether a Property is inherited, but that's open to discussion and suggestions.

Large Text doesn't render right in the uber-default View (bug .3y284t5): Alexx had created some Things with a Large Text Property and not very much else. He hadn't bothered to create a Default View for them, so it was showing in what I think of as the "uber-default" -- simply listing the Properties and their values, which is often good enough. Problem is, the contents of his Large Text was getting squished together, missing the paragraph breaks.

This was a dumb and simple bug, and mostly shows that I haven't actually used the uber-default View myself very much. It should work a bit more correctly now, but I probably need to give that view a little more TLC, and think about its defaults. (Mostly, think about the default rendering of things like Tag Sets, which leave something to be desired.)

Return of the Blank Display Name (bug .3y284r2) I thought I had licked this one yesterday -- that it was now impossible to create a Thing with a blank Display Name -- but Alexx pointed out that there was a trivially easy recipe still. The system was preventing you from creating an *empty* Display Name -- but you could still create one with just spaces in it, and it would still suck.

Fair enough. The new Minimum Text Length meta-Property now trims all leading and trailing spaces before determining the minimum length, which solves that recipe. Hopefully that will put this particular problem to bed. (Although I have faith that y'all will prove me wrong.)

Space Owner is now a Person (bug .3y284oa): this one actually came from me, because it has been annoying me in the Issue Tracker. The concept of "members" has become increasingly important lately, and I use it for, eg, the Reported By field in the Issue Tracker. Problem is, it is based on the concept of invitations and joining and such -- which means that it did *not* include the Space's Owner. In fact, there was no real *concept* of the Owner, the way there is for the Members.

This proved an ickier fix than I like, but it should now work as expected. When a Space loads, it checks that the Owner has a matching Person (which is the in-Space representation of somebody). This suddenly means that, for example, I can put myself in the Reported By field, which was the point of the exercise, but it should prove to be a generally good idea going forward.

Thanks to everyone who is finding things that need fixing (especially Alexx and Talvin, who have been giving the system a real workout). Now, a well-earned weekend...


Log in

No account? Create an account