Previous Entry Share Next Entry
Release 0.6.0 -- Model Types
querki
jducoeur wrote in querki_project
Today is another huge release, which is why there hasn't been one for almost three weeks. There's only one significant feature, but it's a doozy: we've finally added Model Types. This is definitely an advanced feature, and I suspect that only the programmers in the audience will ever care about it -- but when you want it, you want it. (Hence, I'm kicking up the major-ish version number.)


Motivation: the thing is, I am not a database guy at heart. And while I know that complex data structures are (typically) technically isomorphic to a relational DB, I always find it awkward to make the mental jump. I suspect I'm not the only one, given the prevalance of DB-to-object ORM frameworks out there. When you're coding, you want to think in terms of data structures, not tables. And Querki is designed to make things easy, so...

Conceptually, the change is a small enhancement: when you create a Property, when it asks you what Type you want the Property to be, you can now say "New Type, based on a Model". It then prompts you with all of the legal Models that you can use, and *poof* -- you now have a Property whose structure is that Model. (Note that you *must* have Instance Properties defined on the Model in order to use it as a Type; this says which of its Properties will be used in the Type.)

These structures can be nested -- you can have a Property based on a Model, which itself contains another Model Property, and so on -- even recursively. (I've built a simple binary tree in the unit tests, just to check that it works as expected.) In airy theory, you can now build arbitrarily complex data structures in Querki, and just *use* them, pretty much as you'd expect. You can even declare a Property to be a List of Model Values. (Which was the motivation in the first place: we needed a way to manage complex Lists.) No ORM to worry about, no thinking in terms of tables -- in proper Querki fashion, It Just Works.

Well, partly. (Now we get to the caveats.) This project exposed all *sorts* of assumptions throughout the architecture -- there was a deeply-baked assumption that the "path" to a given value was a Thing/Property tuple. That is now totally blown out of the water: a value is now Thing-Property-Property-Property-etc. Worse yet, one of those Properties might be a *list* of values, so it might be Thing-Property[n]-Property-Property-etc. I've done enough unit testing to be decently comfortable that the internals are now sound, but the UI (which is nowhere near as well-covered with tests) definitely still needs work. In particular, while Model Types seem to be completely working in the new "live" Editor (which will become the standard Instance Editor), they definitely don't work completely correctly yet in the older Editor (which will evolve into the Model Editor). And I'm about 90% sure that Lists of Lists will crash and burn horribly, so Don't Do That Yet.

Syntactically, field access works pretty much as you'd expect. If I have a data structure like
Top-level Model
    Model Property
        Nested Model Property
            Text Property
and "My Instance" is an instance of Top-level Model, then the code to access the Text Property in My Instance is
[[My Instance -> Model Property -> Nested Model Property -> Text Property]]
You can pass Model Values around, and dereference them in functions, pretty much as you'd expect.

Note, however, that dotted access to fields does *not* yet work -- you can't yet say:
[[My Instance -> Model Property.Nested Model Property.Text Property]]
I plan to make this work eventually (since it is required by DWIM), but there are some complexities in QL syntax that I have to resolve first.


There are also some Minor Fixes and Enhancements:

_class and _data now cope with multi-node input: previously, these extremely advanced functions (which allow you to hack the resulting HTML) had a limitation that they only worked on a single input element, and behaved badly if you tried to use them with, eg, multiple lines. These now work more reasonably. (The problem was that Scala's built-in Xhtml parser requires that its input be a single well-formed node. So I basically got my hands deep inside the parser, to parse things out node-by-node.)

Renamed "Properties to Edit in Instances" to simply "Instance Properties": I have begun to realize that this Property is much more important than originally expected. Besides controlling the order in which Properties are displayed during editing, this now also controls, eg, the Properties from a Model that are relevant when using it as a Type, as mentioned above. In the near future, this Property will become somewhat baked into the UI: the Model Editor will have separate sections for the Instance Properties vs. the Model Properties, so making something an Instance Property will simply be drag-and-drop.


Finally, there are some largely Internal Improvements, which aren't especially user-visible. For those playing along at home, though, they are:

Rewrite of Function Invocation: as discussed in my personal LJ over the past few weeks, function invocation (which had previously been a growing mish-mash of parameters and a chaos of usage) has now been encapsulated in a clean Invocation class, and usage of it has been wrapped up in an elegant InvocationValue Monad. This mostly means that the code will behave more consistently (indeed, a number of functions now work cleanly in edge cases where they previously failed), and adding new functions becomes easier for me. This was a fairly big project, but a good investment in the future.

Lots of new Unit Tests: we still have an extremely deep test debt. But the number of tests has probably doubled in the past three weeks, and in general we're making progress on this front. Besides tons of unit tests for the functions that have been rewritten for Invocation, we have begun to unit-test saving and loading from the database. Also, I've begun to take advantage of that enormous refactoring last month, which lets me stub out entire subsystems for purposes of testing. This is all a Very Good Thing -- the more automated tests we have, the less likely mistakes are to make it into a release.


So overall, a big release. I think that serious programmers will come to love Model Types -- they are a major step towards allowing you to just think of Querki as an OO / Functional programming language, sitting in the cloud, that you can Do Stuff With. Be gentle with them to begin with, though, and tell me what problems you run into...
Tags:

?

Log in

No account? Create an account