Previous Entry Share Next Entry
Release 0.3.20
device
jducoeur wrote in querki_project
Based on a suggestion from mindways yesterday, I decided to push out another release, to make the Property Reference page a bit easier to understand. This entailed a few new features, all of which I've been wanting for a while.


Added the _equals method: it's kind of remarkable that we've gotten so far without it, but really, both _if and _filter are much more useful if you have _equals available. I didn't bother with the syntactic sugar of the infix "==" (*if* we get enough demand I'll think about it, but I'm not convinced yet), so instead you say "_equals(EXP1, EXP2)". As always, this is essentially a continuation -- both EXP1 and EXP2 get evaluated in the received Context, the results are compared, and it returns a Boolean value of whether they match.

_kind gives access to the Kinds: the key problem here is that we want to use Applies To, which is an integer property. The returned value is part of the internal Kind enumeration, but there was no good way to *use* that enumeration. So I beefed up the _kind() method -- it now accepts an optional parameter, which is the *name* of the Kind you want.

(Basically, the question was how enumerations should work. I don't expect them to be common -- in most cases I would recommend using a Tag Set or Link Set instead -- but we should have a pattern for using them. The common pattern -- Enumeration.Name -- doesn't actually work well in Querki's syntax, but Enumeration(Name) does. This is a fine example of QL as a macro language: we're intercepting Name post-parsing and pre-evaluation, and using the raw parsed string. Eventually, this will probably become possible at the user level, as the way to pass flags to methods.)

Anyway, putting these two together, we are now able to say
... properties... -> _filter(_equals(Applies To, _kind(Property))) -> ...
which is reasonably expressive and Querkish. The Property Reference now uses this expression to separate the Properties based on what you apply them to, which makes the whole thing a little clearer.


Introduced View Source: in the top Actions menu, there is a new "View Source" menu pick. That does more or less what you expect: it displays the component property values of this Thing, in their more-or-less raw form. I added it because I realized that by *far* the best way to learn Querki at the moment is to look at what the existing pages do, and this is a good way to expose that without either having to (a) write a separate How It Works for everything or (b) worse, let people use the Editor without being able to Save.

Note that this feature is pretty quick-and-dirty, and I expect to find that there are seams -- tell me when you find bugs. But it mostly works, and is now available for most pages -- for example, here is the source of that Property Reference page. It illustrates the feature I just described, as well as showing how you can refactor common expressions out into their own Method (in this case, the "System Props" method). It even shows how a single Thing can provide alternate Views (in this case, via the "One Page" Property).

IMPORTANT: at the moment, View Source is a mild security leak. I'll fix that fairly soon, but it's currently controlled by the Can Read security property. That isn't really right -- it potentially leaks property information on the Thing that isn't actually rendered in the Thing's Display Text.

My plan is to add a Can View Source security property, to control this function. The interesting question is mainly what the default should be. I can make arguments for it defaulting to Can Edit or Can Read; I'm leaning towards it defaulting to Can Edit on security grounds, but part of me prefers Can Read, to encourage sharing. Opinions welcomed...
Tags:

  • 1
Sweet!

Minor nit: When viewing the source, I really like the rollover Property descriptions on the Property Names! But they're showing up out in empty space in the middle of the screen; they should probably be moved to a constant distance from the left margin. Not a high priority.

Larger catch-22: The "Chromeless Invite" flag is a bit problematic. I haven't seen the topnav in months, I'm guessing because your wedding invite turned it off, and it stays off even when I'm looking at system examples linked to from LJ.

I opened Querki in Safari, then went to View the Source of a page. It prompted me to either "log in or click on an email invite link" - I did the latter (having no login), then refreshed - now I presumably had rights to view source, but no longer had the ability because the topnav had vanished!

When viewing the source, I really like the rollover Property descriptions on the Property Names! But they're showing up out in empty space in the middle of the screen

Yeah, I noticed that, and have logged a bug against it. Not sure why it's happening -- I'm reusing the tooltip mechanism from the Editor page, and I expected this to work similarly. It's a third-party widget (part of Bootstrap), so I'll need to look into it and figure out what I'm doing wrong.

Larger catch-22: The "Chromeless Invite" flag is a bit problematic. I haven't seen the topnav in months, I'm guessing because your wedding invite turned it off, and it stays off even when I'm looking at system examples linked to from LJ.

Mmm -- very good point. That ought to be scoped to the specific Space, and isn't. I'll add that as a bug -- thanks for pointing it out. (You're probably the only current person who would have noticed this, but it needs to be addressed soon.)

In the meantime, the workaround is to add "?cl=off" to the end of your URL. (Chromeless is simply a cookie, which is turned on and off by the "cl" flag.)

In general, I suspect that the whole "chromeless" thing is going to need a rethink sometime soon. The general requirement is reasonably sound -- some Spaces are definitely going to want it -- but I'm going to need to think carefully about how it works.

And thanks for mentioning that it told you to log in. That's also a bug (and a more immediate one) -- View Source shouldn't be requiring login...

(I'm behind, I know)

I twiddled my URL to alter the chromeless state before even seeing this post. But I don't expect the average user to understand how to monkey around with a URL to get things done. Glad to see scoping as one of the thinkpoints on it.

Yaas. Y'all should definitely point stuff like this out to me when it happens -- while I'm trying to be good about keeping my User hat firmly planted on my head, I just plain know the system too well sometimes. I had reflexively added the "cl=off" to my URLs several times, without even thinking about the way it was going to affect other users -- simply a pure design bug that I'm going to need to fix when I get a little time for it...

  • 1
?

Log in

No account? Create an account