Previous Entry Share Next Entry
Release 0.8.2
jducoeur wrote in querki_project
Definitely getting back into the groove of releases every day or two. Today's is mainly about one new function, but there is a bunch of supporting machinery around it. Note that most of the following is pretty advanced.

Added the _thingValues method: _thingValues rounds out the first draft of User Values. It receives an Identity (a user, essentially), and produces all of the User Values that that person has given in this Space. It is mainly intended to give you a sense of how this person rates things, so you can adjust your expectations accordingly.

The problem, of course, is: how do you get an Identity in this first place? The rest of the features are mainly to support the ability to list the Members of this Space, and get their User Values.

General motivation: we need to list all the Members' Identities as clickable links; when you click a link, you go to the new _displayIdentity page, which lists the User Values for that Identity. The first half of that is:
[[Person._instances -> _personIdentity -> _bulleted]]
The second half is:
[[$identity -> _asType(Link Type) -> _resolveIdentity -> ""
### ____

#### User Values

Let's go through that, step by step.

Person._instances simply lists all of the instances of the Person Model in this Space -- that basically means the Members.

Added _personIdentity: this new function receives a Person, and produces an Identity. (What's the difference? Identity is a face that you present to Querki; Person is how an Identity relates to a Space. Identity is a low-level built-in datatype; Person is a more ordinary Thing.)

Identity renders as [Name](_displayIdentity?identity=ID) -- a link to the new _displayIdentity page. But note that it passes the identity as a query parameter.

Added _withParam: in practice, this turned out to be hardcoded. But in the spirit of "Querki shouldn't cheat", there is now a first-class way to add query parameters cleanly in QL. If you say something like:
[[My Thing -> _withParam(""foo"", ""bar"")]]
This produces a link to My Thing, with "?foo=bar" appended.

_withParam is sensitive to whether there are already query parameters, and adjusts accordingly, so you can use it repeatedly on a single Link. It works for both ordinary Links and URLs. (And will work with the new External Link Type, which I began to write but doesn't have a UI yet -- this is a proper Link that lets you specify the URL and the display text separately.)

URL Query Params now available in QL: from a power-programming perspective, this is actually the most important enhancement -- you can now pass parameters to pages, and receive them in QL expressions. They show up as bound names in QL -- basically, the parameter name prefixed with "$".

In _displayIdentity, shown above, we say $identity to get at the query parameter that was passed in. It's an understatement to say that this will be huge: it allows Querki pages to be easily parameterized, which should make it much easier to build complex Spaces.

Added _asType(): continuing in _displayIdentity, we find _asType(Link Type). _asType is basically the general Querki "cast" operator -- it attempts to cast the received value to the specified Type. It does *not* work for everything yet, and some casts will always be illegal. But by and large, if the received value and the new Type are serialization-compatible, it should work.

_withParam essentially serializes the value, and _asType deserializes it, in matching ways. So *most* of the time, if you specify the parameter using _withParam(), _asType() will turn it back into the value you started with. (Eventually we may even automate this to some degree, by letting you "parameterize" your page and making the parameter-passing happen behind the scenes. But this is a good start.)

Added _resolveIdentity: okay, at this point we have the Identity OID. But Identity isn't a Thing, so we can't just dereference it as usual. So we have to explicitly call the new function _resolveIdentity, which turns an OID into an Identity. (I don't love this, but haven't yet come up with an efficient way around it.)

Put all together, those pieces let us:
  • Get the Identities of all the Members

  • Send those Identities to a page as parameters

  • Interpret those parameters to get the Identities back

  • Display all of the User Values for those Identities
I wouldn't say that it has achieved full DWIM yet, but at least it's getting nicely powerful. I suspect that the combination of _withParam, _asType and query parameter bindings in QL are going to make it much easier to build all sorts of neat things fairly easily.

Improved various renderings: finally, several Types got some improvement in how they render. In particular:
  • Identity now renders as a link to _displayIdentity for that Identity.

  • Rating now renders as stars, as you would expect. (Previously, it rendered as a number if you weren't editing it.) NOTE: for the moment, the hover label shown on this Rating is *not* correct. I know it's wrong, but it isn't easy to fix, so I'm going to have to ponder it.

  • Review now renders as the Rating, followed by the comment text.

  • A User Value in the general case displays the username, thing, property, and the actual value. It isn't pretty, but it's getting to be functional.

And with that, we're mostly done with Ratings and Reviews. Next up: we begin to write Querki's Notification system, so you can hear about comments...


Log in

No account? Create an account