Previous Entry Share Next Entry
jducoeur wrote in querki_project
There have actually been several bugfix releases since the last release announcement; suffice it to say, we're still shaking out some of the last bugs in Model Values.

The beginnings of HTML whitelisting: mindways has been finding Querki's {{ ... }} syntax for injecting divs and spans to be a bit problematic for certain cases -- in particular, he sometimes wanted to be able to insert a div without surrounding paragraphs, which isn't especially doable.

So for the power users, I've begun to very tentatively add HTML whitelisting. I'm going to add HTML tags and attributes, just one or two at a time and highly vetted, so that folks have them available when needed. Ultimately, I suspect we'll wind up with a relatively full list (probably not terribly different from LJ's), but I'm going to let these fight for their lives as features. Feel free to suggest one or more tags that you would find useful inside Querki.

For now, I've added div and span, the most useful tags for style management. The only attributes allowed on them are class and id, and the values of those attributes are strictly limited to simple alphanumerics, dash, underscore and space. (This is almost certainly excessively paranoid, but I'm going to generally be cautious here.)

As part of this change, I've removed the Markdown feature that created a "quicklink" if you said something like <> -- basically turning that URL directly into an in-place link. I've always considered this one a misfeature -- angle brackets are just too important to HTML to overload them like that, and the only times I ever saw it used in Querki were all unintended accidents.

Enhanced _isEmpty / _isNonEmpty: this was a pure DWIM enhancement. We discovered by accident that one natural usage for these Functions is something like:
[[_if(_isNonEmpty(My Thing -> My List), ...)]]
Problem is, that totally wasn't how these functions work -- they were only designed to receive a passed-in context, like this:
[[_if(My Thing -> My List -> _isNonEmpty, ...)]]
On a little thought, I declared this a design bug: both syntaxes are completely logical and intuitive, but which one makes more sense is going to vary from situation to situation. So they're now both legal -- if there is a parameterized phrase, it will evaluate that; otherwise, it will decide based on what is passed into it.

This approach, of using *either* a parameterized phrase or the passed-in value, is likely to become a common pattern in Querki functions, and I've enhanced the infrastructure to make it easy for me to do. Please point out other places where you believe it would be appropriate. I'd like us to standardize on it, where appropriate.

Model Values now work in the traditional Editor: for a while, if you had defined a Model Value (that is, a Property that embedded a Model inside another Thing), you could only edit it in the new-style "live" Editor. (That is, the bulk editor.) There should now work correctly in the old-fashioned Editor.


Log in

No account? Create an account