generic "backend" save/load plugin

[bwl21]

Stefano wrote:

We probably can deploy a generic "backend" save/load plugin that takes an url to be invoked at load and another to POST saves, but I don't know what is "generic" (a single save POST with both the metadata and the generated html? 2 different methods to save the metadata and to "export" the generated html?). We'll have to see some people embed use-case in order to better understand this and make some better plugin to help future integration.

I open this issue in order to discuss the methods for such a plugin. Here are the initial proposals. I will update the issue from time to time based on the discussion.

simple version

• save an email (JSON and html) additional fields: date, time, username
• list available emails
• delete an email
• load an email

  advance mode

• save an email with versions
• list versions of an email
• compare versions of an email
• restore earlier version of an email

[CaptainHypertext]

I'm currently trying to implement Mosaico in our CRM as a newsletter editor, working with the plugin posted in issue #73.

If I were implementing back-end saving in Mosaico, I would do it differently. Instead of providing different urls in the config for image uploading, downloading, saving, I would use callbacks. That would give the developer a lot more flexibility.

For example, there could be a save option, and save could be a function like this:

Mosaico.init({
    onImageUpload: function() {},
    onSendTest: function() {},
    onSave: function(saveObject) {
        // saveObject could contain metadata, json configuration, and html

        // My sample callback
        $.post('https://example.com/template/save/42', saveObject)
            .done(function() {
                return true;
            })
            .fail(function(jqXHR, textStatus, error) {
                return false;
            })
        );
    }
}, plugins);

If for nothing else, do it for saving. That way the dev can choose if they want to use html or json, provide a unique ID, or whatever. Also consider the fact that a lot of back end websites these days don't use relative URLs, but use routing for everything. I had to cobble together some messy code to satisfy the relative URL requirements.

That's just my two cents, based on my experiences with the numerous other plugins I've used. That said, this is a very impressive plugin, and I salute its creator for making it open source!

[bago]

At this time mosaico doesn't provide a "save" backend, so there is no configuration for "saving" (not an url nor a callback).

Image upload instead needs an URL because it also deals with "progress" and "drag & drop" and I don't think it would be easy to be implemented by callback.

You can define your own command buttons and their callbacks via plugin like this comment explain: https://github.com/voidlabs/mosaico/issues/73#issuecomment-198584809

So, you already have a way to define your own callbacks for the "top-right" buttons and it is not so hard to do (this doesn't apply to "image upload backend" as I already explained).

Placing an "onSave" in the "Mosaico.init" gives "Mosaico" a knowledge it currently doesn't have/need, so I prefer to leave it in a plugin until I identify a better solution. Also having a single callback would be sub-optimal if you want to store the JSON: generating the output html have an high cost, while generating the JSON is much lightweight.. it wouldn't make sense to generate the HTML when the user wants to save only the JSON.

I didn't get your "relative urls" issue: Mosaico is already used in production in environmens where routes are used. Please open a specific issue with details if you think there is an issue.