Commit graph

9 commits

Author SHA1 Message Date
Dan Stillman
0cc9926309 Fix test from d8025be67 2016-05-17 02:44:00 -04:00
Dan Stillman
d8025be676 Ignore sanitization changes when comparing notes in conflict
Until we have a consistent way of sanitizing HTML on client and server, account
for differences manually. More differences between HTMLPurifier and TinyMCE
should be added as necessary.
2016-05-17 02:33:53 -04:00
Dan Stillman
daf4a8fe4d Deasyncification 🔙 😢
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 17:03:58 -05:00
Dan Stillman
e873617890 Fix trashing of descendant items when deleting a collection
Also allows 'collections' property to be passed to
createDataObject()/createUnsavedDataObject() in tests.
2016-01-18 13:50:46 -05:00
Dan Stillman
0803bb84e3 Don't set collections: "" in PATCH JSON when changing item to child 2015-10-29 03:57:08 -04:00
Dan Stillman
cd4d084dd9 Support for automatically merging collections and searches 2015-07-20 02:12:14 -04:00
Dan Stillman
a3f4fe181f More data layer changes
- Moved ::_get() and _set() from Collection/Search into DataObject, and
  disabled in Item
- Don't disable new items after save. We now put new objects into the
  DataObjects cache from save() so that changes made post-save are
  picked up by other code using .get().
- Added 'skipCache' save() option to avoid reloading data on new objects
  and adding them to the cache. (This will be used in syncing, where
  objects might be in another library where they're not needed right
  away.) Objects created with this option are instead disabled to
  prevent reuse.
- Modified some tests to try to make sure we're reloading everything properly
  after a save.
- Documented save() options
2015-05-21 23:39:00 -04:00
Dan Stillman
e8a04dffd0 Relations support for Z.DataObjectUtilities.diff() and applyChanges() 2015-05-20 23:16:18 -04:00
Dan Stillman
abaa4da5ab Much better data object change detection
Replace Z.DataObjects::diff() with Z.DataObjectUtilities.diff(). Instead
of just returning two objects with the differing fields, the new diff()
generates a changeset with operations to apply with applyChanges(),
including at the array member level for collections and tags. This,
combined with cached pristine copies of objects, will allow for vastly
better conflict resolution, with automatic merging of non-conflicting
changes.

Creators currently don't show granular changes, and ordering might make
it too tough to do so. Relations diffing isn't yet implemented.
2015-05-19 01:17:12 -04:00