Looks like the code doesn't use clientSideStorage

[OscarGodson]

Is there a reason? This is for storing drafts in case, for example, your browser or computer crashes, the server goes down, etc.

[jackmcdade]

It was creating issues pre-loading the contents of the specified data. I could test it again, but it was overwriting what i wanted to edit in the first place with older content.

[OscarGodson]

What do you mean exactly? Why would the DB copy be older if everything is saved correctly? Shouldn't they be in sync?

Each file object has a modified date like:

filename: {
  content: "hello world",
  created: "2012-08-11T00:41:59.626Z",
  modified: "2012-08-11T00:41:59.626Z"
}

So, if you're storing it somewhere else (as most of the time you would be) you'd check the modified dates. A crude implementation would be:

var local = new Date(editor.getFiles('bar2219').modified).getTime()
  , db = new Date(fileFromDb.modified).getTime()
// Is local modified time smaller than the DB's?
if (local < db) {
  // If so, then the local copy is old, replace with the DBs version:
  editor.importFile('filename', fileFromDb.content);
}

// If it wasnt older we could skip the import because
// it's either the same version or an unsaved draft

I'm asking mainly because most implementations so far turn this off and im trying to investigate why, and try to make it better. All feedback appreciated :) I made it an option originally in case a dev is doing their own client side draft saving.

[jackmcdade]

A couple things. First, we don't have a database. This is a flat-file driven CMS :) So there's only ever one version of a file, and most people use git for version control.

Second, users can mix and match entries all sorts of fieldtypes, Epic Editor just being one of them. I don't like it behaving drastically different than the other fields as it can cause confusion. So I opted to turn it off to prevent inconsistency, even if it technically might be an improvement.

[OscarGodson]

Awh, this makes sense. You could never lose a DB connection. And the version control piece would make it kinda hard. This is indeed a special case. The only thing it'd help in your case is a connection loss or if you wanted to continue writing offline (like on a plane).

Since they are flat files you could simply use the actual file's modified date just as easily.

Good points and this helps a lot thanks!

On Sep 21, 2012, at 6:39 PM, "Jack McDade" notifications@github.com wrote:

A couple things. First, we don't have a database. This is a flat-file driven CMS :) So there's only ever one version of a file, and most people use git for version control.

Second, users can mix and match entries all sorts of fieldtypes, Epic Editor just being one of them. I don't like it behaving drastically different than the other fields as it can cause confusion. So I opted to turn it off to prevent inconsistency, even if it technically might be an improvement.

— Reply to this email directly or view it on GitHub.