Hot swappable schemas?

1

We’d like to support hot swappable schemas in our solution long term. The idea is that we could add a new schema to a repository and not have to redeploy any code.

This requires serializing and deserializing the schema such that the editor could load it at runtime. I’ve been banging my head against the keyboard trying to make it work. Serializing the spec with Douglas Crockford’s cycling methods, works to get it over the wire. However, in my testing this fails to produce an identical schema when we try to instantiate a new one.

I looked at this discussion, but was not able to get it serializing at all using that method.

Thoughts? Advice? Am I crazy?

2

Definitely don’t try to serialize the Schema object itself—that’s an instance of a class, and there’s no robust way to serialize it.

You could try to serialize the spec you used to build the schema, though that may also contain functions (in the DOM parser and serializer properties) and thus won’t be serializeable as JSON. So you’ll either have to separate the DOM parsing logic from the schema (which is possible, if a little awkward), or load actual JavaScript code somehow.

3

Thanks for the reply Marjin, will take that into consideration and update this thread as it progresses.

4

Any updates about this ? We also face the similar issues recently.

5

I know this is an ancient thread - but I’m also kinda curious what the outcome of this is/was. Unfortunately OP didn’t come back about it here. I actually have the same kind of requirement stated by him.

@marijn - when you mentioned “or load actual JavaScript code somehow” - what JavaScript code did you refer to? What I’m aiming for is to be able to somehow store (as in persist) the configuration for an editor somewhere, to subsequently have it read back at some later point in time. The idea is to be able to add/upload PM plugins to an already up-and-running system, with the goal to make those available to a ‘configurator’. The job of the ‘configurator’ is to craft a schema loosely speaking through point-and-click from the repository of plugins.

6

Looking at the SchemaSpec it looks like the following properties do not qualify to be serialized/deserialized normally:

  • toDOM (nodes, marks)
  • parseDOM (nodes, marks => parseRule)
  • getAttrs, contentElement, getContent (parseRule)

So if for those parts we effectively need to load JavaScript for. Is my understanding correct?

Capturing these elements in a data model, would allow us to create Schemas at runtime, I think.

7

Right, those are what I was referring to.

8

Thank you for the confirmation. So with that - throwing caution to the wind - could these elements be materialized into blocks of code that are run through new Function or (cough) eval?

I’m investigating a solution where PM schemas and plugins can be uploaded to a running system, without downtime - a strategy that I’ve used in the past in a Java back-end system that had a Groovy custom logic shell. It seems that something like this, where custom code (not known at design time) can be added to a running system is not easily achievable (in a safe and performant way) in JavaScript - but I’d be delighted to be corrected.