Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
"use strict";
|
|
|
|
|
|
|
|
describe("Related Box", function () {
|
|
|
|
var win, doc, itemsView;
|
|
|
|
|
|
|
|
before(function* () {
|
|
|
|
win = yield loadZoteroPane();
|
|
|
|
doc = win.document;
|
|
|
|
itemsView = win.ZoteroPane.itemsView;
|
|
|
|
});
|
|
|
|
after(function () {
|
|
|
|
win.close();
|
|
|
|
})
|
|
|
|
|
|
|
|
describe("Add button", function () {
|
|
|
|
it("should add a related item", function* () {
|
|
|
|
var item1 = yield createDataObject('item');
|
|
|
|
var item2 = yield createDataObject('item');
|
|
|
|
|
|
|
|
// Select the Related pane
|
|
|
|
var tabbox = doc.getElementById('zotero-view-tabbox');
|
|
|
|
tabbox.selectedIndex = 3;
|
|
|
|
var relatedbox = doc.getElementById('zotero-editpane-related');
|
|
|
|
assert.lengthOf(relatedbox.id('relatedRows').childNodes, 0);
|
|
|
|
|
|
|
|
// Click the Add button to open the Select Items dialog
|
|
|
|
setTimeout(function () {
|
|
|
|
relatedbox.id('addButton').click();
|
|
|
|
});
|
|
|
|
var selectWin = yield waitForWindow('chrome://zotero/content/selectItemsDialog.xul');
|
|
|
|
// wrappedJSObject isn't working on zotero-collections-tree for some reason, so
|
|
|
|
// just wait for the items tree to be created and select it directly
|
|
|
|
do {
|
|
|
|
var view = selectWin.document.getElementById('zotero-items-tree').view.wrappedJSObject;
|
|
|
|
yield Zotero.Promise.delay(50);
|
|
|
|
}
|
|
|
|
while (!view);
|
2017-03-24 09:18:55 +00:00
|
|
|
yield view.waitForLoad();
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
|
|
|
|
// Select the other item
|
|
|
|
for (let i = 0; i < view.rowCount; i++) {
|
|
|
|
if (view.getRow(i).ref.id == item1.id) {
|
|
|
|
view.selection.select(i);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
selectWin.document.documentElement.acceptDialog();
|
|
|
|
|
|
|
|
// Wait for relations list to populate
|
|
|
|
do {
|
|
|
|
yield Zotero.Promise.delay(50);
|
|
|
|
}
|
|
|
|
while (!relatedbox.id('relatedRows').childNodes.length);
|
|
|
|
|
|
|
|
assert.lengthOf(relatedbox.id('relatedRows').childNodes, 1);
|
|
|
|
|
|
|
|
var items = item1.relatedItems;
|
|
|
|
assert.lengthOf(items, 1);
|
|
|
|
assert.equal(items[0], item2.key);
|
|
|
|
|
|
|
|
// Relation should be assigned bidirectionally
|
|
|
|
var items = item2.relatedItems;
|
|
|
|
assert.lengthOf(items, 1);
|
|
|
|
assert.equal(items[0], item1.key);
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
|
|
|
describe("Remove button", function () {
|
|
|
|
it("should remove a related item", function* () {
|
|
|
|
var item1 = yield createDataObject('item');
|
|
|
|
var item2 = yield createDataObject('item');
|
|
|
|
|
|
|
|
item1.addRelatedItem(item2);
|
Deasyncification :back: :cry:
While trying to get translation and citing working with asynchronously
generated data, we realized that drag-and-drop support was going to
be...problematic. Firefox only supports synchronous methods for
providing drag data (unlike, it seems, the DataTransferItem interface
supported by Chrome), which means that we'd need to preload all relevant
data on item selection (bounded by export.quickCopy.dragLimit) and keep
the translate/cite methods synchronous (or maintain two separate
versions).
What we're trying instead is doing what I said in #518 we weren't going
to do: loading most object data on startup and leaving many more
functions synchronous. Essentially, this takes the various load*()
methods described in #518, moves them to startup, and makes them operate
on entire libraries rather than individual objects.
The obvious downside here (other than undoing much of the work of the
last many months) is that it increases startup time, potentially quite a
lot for larger libraries. On my laptop, with a 3,000-item library, this
adds about 3 seconds to startup time. I haven't yet tested with larger
libraries. But I'm hoping that we can optimize this further to reduce
that delay. Among other things, this is loading data for all libraries,
when it should be able to load data only for the library being viewed.
But this is also fundamentally just doing some SELECT queries and
storing the results, so it really shouldn't need to be that slow (though
performance may be bounded a bit here by XPCOM overhead).
If we can make this fast enough, it means that third-party plugins
should be able to remain much closer to their current designs. (Some
things, including saving, will still need to be made asynchronous.)
2016-03-07 21:05:51 +00:00
|
|
|
yield item1.saveTx();
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
item2.addRelatedItem(item1);
|
Deasyncification :back: :cry:
While trying to get translation and citing working with asynchronously
generated data, we realized that drag-and-drop support was going to
be...problematic. Firefox only supports synchronous methods for
providing drag data (unlike, it seems, the DataTransferItem interface
supported by Chrome), which means that we'd need to preload all relevant
data on item selection (bounded by export.quickCopy.dragLimit) and keep
the translate/cite methods synchronous (or maintain two separate
versions).
What we're trying instead is doing what I said in #518 we weren't going
to do: loading most object data on startup and leaving many more
functions synchronous. Essentially, this takes the various load*()
methods described in #518, moves them to startup, and makes them operate
on entire libraries rather than individual objects.
The obvious downside here (other than undoing much of the work of the
last many months) is that it increases startup time, potentially quite a
lot for larger libraries. On my laptop, with a 3,000-item library, this
adds about 3 seconds to startup time. I haven't yet tested with larger
libraries. But I'm hoping that we can optimize this further to reduce
that delay. Among other things, this is loading data for all libraries,
when it should be able to load data only for the library being viewed.
But this is also fundamentally just doing some SELECT queries and
storing the results, so it really shouldn't need to be that slow (though
performance may be bounded a bit here by XPCOM overhead).
If we can make this fast enough, it means that third-party plugins
should be able to remain much closer to their current designs. (Some
things, including saving, will still need to be made asynchronous.)
2016-03-07 21:05:51 +00:00
|
|
|
yield item2.saveTx();
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
|
|
|
|
// Select the Related pane
|
|
|
|
var tabbox = doc.getElementById('zotero-view-tabbox');
|
|
|
|
tabbox.selectedIndex = 3;
|
|
|
|
var relatedbox = doc.getElementById('zotero-editpane-related');
|
|
|
|
|
|
|
|
// Wait for relations list to populate
|
|
|
|
do {
|
|
|
|
yield Zotero.Promise.delay(50);
|
|
|
|
}
|
|
|
|
while (!relatedbox.id('relatedRows').childNodes.length);
|
|
|
|
|
|
|
|
doc.getAnonymousNodes(relatedbox)[0]
|
|
|
|
.getElementsByAttribute('value', '-')[0]
|
|
|
|
.click();
|
|
|
|
|
|
|
|
// Wait for relations list to clear
|
|
|
|
do {
|
|
|
|
yield Zotero.Promise.delay(50);
|
|
|
|
}
|
|
|
|
while (relatedbox.id('relatedRows').childNodes.length);
|
|
|
|
})
|
|
|
|
})
|
|
|
|
})
|