Previous Entry Share Next Entry
Release 0.4.4.2
device
jducoeur wrote in querki_project
Two small bugfix-centric releases yesterday, plus a couple of enhancements to the site. Details, with the most interesting bits up top:


Began to create Recipes: this is probably the most important addition for most folks. I've added a page for Recipes -- little how-to's that describe how to solve a particular problem in Querki. I suspect that in the long run, these are actually going to be more useful than the eventual reference documentation for most people. There are just a couple there now, but they are sorted with the most-recent up top, so I recommend checking this out periodically for tips on how to use the system effectively.

I *strongly* encourage y'all to suggest topics for this. There is no such thing as a dumb question, and I suspect we'll wind up with hundreds of topics here. (And now that I think about it, I need to start tagging these by subject, so people can find what they need.)


Issues by Modification Time page: requested by Alexx, this is simply an alternate sort of the Issues, to show the most recently changed ones up top, so you can see where the activity is.


You can now format DateTimes: no issue for this one, but I found that I wanted it for the Issues by Modification Date page.

As I've mentioned many times before, if you have a Link that you're displaying, you can display whatever text you want for it like this
[[My Link -> ""__displayed like this__""]]
That is, whatever text is inside the double-underscores gets used as the text shown for the link.

A while ago, I generalized this concept internally, so that the text inside the underscores can potentially be used by any Type -- basically, it's a display template, to be used in a Type-specific way. So I just enhanced the DateTime Type to use this. Since DateTime is using joda-time under the hood, you can use any format compatible with joda's DateTimeFormat, as outlined on this page.

So for example, the dates shown on Issues by Modification Date are displayed like this:
[[_modTime -> ""__MMM dd, kk:mm__""]]
For the time being, _modTime is the only way to get a DateTime, but that'll change soon enough. (Tell me if it becomes high priority for you to use DateTime in your Space, and I'll deal with creating some UI for it.)


Fixed _sort(_desc()) (bug .3y284vg): when I went to implement the Issues by Modification Date page, I found that I couldn't sort in descending order any more -- that is, I couldn't put the newest changes at the top. This was a pure bug (if a subtle one) introduced when I did some enhancements to _sort a while ago. This now has a unit test, to prevent it happening again.


Beginnings of Type Migration (bugs .3y284v7 and .3y284oj): Alexx had noticed, early on, that trying to change the Type of a Property would silently fail. (As it turns out, this wasn't quite true: it would take effect in the database, but wouldn't show up in the live site until it was rebooted.) And then it transpired that some of his Properties were defined as Plain Text, but really needed to be Text in order to do what he needed.

(Important tangent: I don't recommend the Plain Text Type for normal Querki use. It is intended for the occasional Property, such as Display Name, that are explicitly not allowed to include any QL. But that's pretty rare: usually, you want to allow yourself the flexibility of having QL in your text values. So I recommend generally using Text and Large Text, and considering Plain Text to be for advanced use only. When I get some documentation for the Types, it will say something to this effect.)

Anyway, I decided that I needed to wrestle with Type transformations. In general, changing the Type of a Property should *not* be allowed, because it is staggeringly dangerous: I haven't really wrestled with the problems of changing serialization formats and such, so most possible changes are simply likely to break your Space (possibly unrecoverably, at least until we implement Undo) and we shouldn't allow that. But Alexx' specific need, of changing one textual Type to another, is both reasonable and safe. (And clearly desireable: in particular, wanting to switch back and forth between Text and Large Text seems likely to be normal.)

So I introduced the framework to deal with this. Changing a Property's Type will *usually* give you an error (and changing the Collection will always do so for now). But you are allowed to change between the three textual Types (Text, Large Text and Plain Text) freely, and that should just work now. The framework will allow us to add other legal transforms in the future, but for now I'd prefer to only deal with cases like this, where the serialization formats are identical.


Fixed Sharing and Security page on mobile: due to a Bootstrap issue, the Sharing and Security page was slightly hosed on small screens. I dealt with that, by removing the hard-fixed menu on the left.


Fixed references to a missing ExactlyOne Text Property (bug .3y284vl): Alexx noticed that he was getting Unexpected Errors in some cases where his Default View was referring to a Text Property that didn't actually exist on this Thing. This was a dumb bug in some transform code, that was using the wrong Type when it hit an empty value.
Tags:

  • 1
I don't know that I would call it a *high* priority, but Date is a pretty fundamental part of the originally conceived purpose for my Sentinels page (prior to the inevitable mission drift). If you want to record your games, recording when they happened seems like it should be in there.

Hmm. Okay, noted. I'll try to get to .3y284o8 as soon as I can. If anyone has any particular suggestions for good jQuery-based date-input controls, I'd be interested in hearing. (The work is mainly integrating one into the system. A control that takes a standard millis-since-epoch input would be a plus...)

  • 1
?

Log in

No account? Create an account