Previous Entry Share Next Entry
Release 0.6.1 -- CSV Export
jducoeur wrote in querki_project
This week's new feature is a bit specialized, but folks who want to use Excel for analysis will like it: you can now export all of the Instances of a specified Model to a CSV file. (Which can then be read into Excel or other spreadsheet programs.)

In order not to clutter the UI too much, I've added a new page for these sorts of unusual-but-useful power features. Under the Actions menu, you will now find an Advanced menu option, which takes you to the Advanced Commands page. This is spartan for now, but it will serve as the initial home for a lot of these features. (Eventually, we'll want to do a deep rethink of the whole menu system, but I don't want to tackle that yet.)

For the moment, CSV Export operates in a very specific mode, and we've made some decisions about the defaults. In particular:
  • If your Model includes any embedded Model Properties, those will be recursively flattened into the resulting CSV file. That is, there will be one column for each Property in each of the nested Models.

  • Any List or Set Properties will currently only export the *first* element. This is highly controversial, but I don't think there are any clearly good answers here: Querki data just plain isn't flat, and CSV/Excel demand nice square data, with a consistent number of columns.

  • If you export a List of Model Values, it will export the *default* value for that Model Type. (That is, it will export the value from the underlying Model.) Again, this is necessary to be square and consistent.

  • If you have an Enumerated Category (see below), Properties that link to that Category won't be displayed as simple lists; instead, each Category in that enumeration will get its own column, and there will be an "x" placed in the column for each Thing that uses it.

  • If the Model lists its Instance Properties, those will be used to guide the export; otherwise, all Properties will be exported, in alphabetical order. (But the fields of nested Model Properties, and the values of an Enumerated Category, will be grouped together.)

  • The exported CSV file has a header line, with the name of the Property for each column.
In the long run, I expect that we'll need a mechanism to customize these behaviours, but I don't know when that will be. Feel free to ask for enhancements or customization points.

Other enhancements in this release include:

Enumerated Categories: for a while now, we've had the horribly-named Property "No Create Through Link Model". This addressed a problem that I was hitting in the Editor: if I have a Link to a Model, the Editor always offers me the ability to create a new Instance of that Model. Sometimes that's exactly what I want, but often it isn't -- frequently, I've already defined all of the Instances I want, and don't want to accidentally create more.

In conversations with mindways, I twigged that these cases were all basically categorizations -- I've defined what in programming is usually thought of as an enumeration, and want to consistently use values from it. That's a broader concept, and deserves to be recognized as such.

So the name of this property has been changed to "Enumerated Category" for now -- I suspect this will change (and am open to suggestions), but it's at least better than what we had before. In the medium term, we'll clearly want a UI that is customized to this problem, to make it easy to create and populate these categorizations.

Model "Type" is now buried in the UI: in my previous survey, nobody really gave any motivating reason why one would ever need multiple Types based on a single Model. That being the case, I've essentially squished that entire idea out of the UI, to simplify things. Instead of creating or selecting a Model Type, you now simply say that you want to create a Property based on a Model. Under the surface, it checks whether there is already a Type for that Model, uses it if so, and creates a new one if not.

So Model Types still exist -- you'll see it if, for example, you examine the Property. But by and large, you rarely need to think about it: you're just creating a Property from a Model.

Not Inherited Property now shows up in the UI: due to a bug, the meta-Property "Not Inherited" wasn't available to users. This is highly advanced, but when you want it, you want it. This is found under "Advanced Properties" in the Editor, if you are editing a Property -- if you add it to a Property, and set it to true, it declares that values of this Property are not inherited from Model to Instances. The Instances will still *have* the Property, but will always have their own value of it.

Next: some tweaks, tuning and bug-fixing, and then on to the beginnings of Querki Explorer...


Log in

No account? Create an account