Preferences engine in XIDED
Category xided
I took a bit of a detour on what I'd planned on adding to XIDED tonight, because I was annoyed that it doesn't maintain open databases across sessions like Domino Designer does. For this and other reasons, I've been meaning to add a preferences engine but just hadn't gotten around to it, and I figured that was long overdue. I'm quite proud of how it turned out... in fact, I haven't SnTT'ed in months, and I think the way this is now structured would make a decent SnTT. But I'm sleepy, so I'll just give you a brief overview for now. If weeks pass and I haven't shared the full details, please harass me to do so.
Because Domino tends to cache profiles, I chose not to use true profile documents; it just uses plain old Notes documents in a "User Profiles" view. But it behaves similarly to profiles in at least one respect: whenever a user's preferences are queried or updated, their document is automatically created if one doesn't already exist. All read and write operations are handled by a single agent that checks QueryString parameters to determine what to do: one such parameter is called "action", which can be "select","update","insert", or "delete". Which looks like SQL but of course really isn't. Instead, it leverages Domino's marvelous flexibility to dynamically add whatever field is impacted by the specified action.
In this case, opening a database in XIDED adds a value to an "openDatabases" field on the preferences document (a field which only exists once it's referenced), and closing the same database deletes the corresponding value. Finally, every time XIDED loads, it issues a select to pull the field value... here's what, in my (perhaps not so humble) opinion, is wicked cool: when a value is added to a field, it's stored in JSON format, so when the result is returned, it's eval'ed into an object. The userPreferences function accepts a callback parameter that, if specified, is automatically passed that object. So in this case, it just loops through a "databases" object, and for each one it calls XIDED.openDatabase(database.replicaId, database.title). Fun stuff.
Over the next couple days I'll apply this same approach to allow XIDED to remember other preferences, such as visual theme and autosave frequency. Another option I'll be adding - perhaps not in 1.0, but probably - is whether XIDED should remember which elements you have open...
I took a bit of a detour on what I'd planned on adding to XIDED tonight, because I was annoyed that it doesn't maintain open databases across sessions like Domino Designer does. For this and other reasons, I've been meaning to add a preferences engine but just hadn't gotten around to it, and I figured that was long overdue. I'm quite proud of how it turned out... in fact, I haven't SnTT'ed in months, and I think the way this is now structured would make a decent SnTT. But I'm sleepy, so I'll just give you a brief overview for now. If weeks pass and I haven't shared the full details, please harass me to do so.
Because Domino tends to cache profiles, I chose not to use true profile documents; it just uses plain old Notes documents in a "User Profiles" view. But it behaves similarly to profiles in at least one respect: whenever a user's preferences are queried or updated, their document is automatically created if one doesn't already exist. All read and write operations are handled by a single agent that checks QueryString parameters to determine what to do: one such parameter is called "action", which can be "select","update","insert", or "delete". Which looks like SQL but of course really isn't. Instead, it leverages Domino's marvelous flexibility to dynamically add whatever field is impacted by the specified action.
In this case, opening a database in XIDED adds a value to an "openDatabases" field on the preferences document (a field which only exists once it's referenced), and closing the same database deletes the corresponding value. Finally, every time XIDED loads, it issues a select to pull the field value... here's what, in my (perhaps not so humble) opinion, is wicked cool: when a value is added to a field, it's stored in JSON format, so when the result is returned, it's eval'ed into an object. The userPreferences function accepts a callback parameter that, if specified, is automatically passed that object. So in this case, it just loops through a "databases" object, and for each one it calls XIDED.openDatabase(database.replicaId, database.title). Fun stuff.
Over the next couple days I'll apply this same approach to allow XIDED to remember other preferences, such as visual theme and autosave frequency. Another option I'll be adding - perhaps not in 1.0, but probably - is whether XIDED should remember which elements you have open...
