API

Ediphy.API

This object exposes three methods in charge of emitting and managing events that are used in the communication between plugins and the core. These are:

• addMenuButton: this is called to initialize plugins, it calls an event of the type "addMenubutton" that is listened by the component PlugginRibbon and adds a button to itself with the configuration provided as parameter in JSON format(text,icon,etc.) so it can be used later.

• openConfig: it is called when it is needed to have access to the configuration modal when using complex plugins. It works in an asyncronous way, because it returns the reference to the div that has to be rendered. Recieves two parameteres, plugin name whose modal want to have access and a boolean teeling if this is the first time it is accessed (it is mandatory for render method in the plugin). Throws an event "openconfig" kind that is executed by the component PluginConfigModal and makes to display it. Once done, answers the provided event providing div reference mentioned before. Normally, this method is called from the component PluginToolbar when clicking the button "open configuration" or when creating the plugin. Promised were used to implement this.

• renderPlugin: this is the most common method used to render plugins. Calls a "render" event type that is listened inside EditorApp and depending on the "isUpdating" parameter, it throws an action or another to create or update a EditorBox in the application state. Also, it recieves JSON parameters telling the HTML that needs to be rendered, the toolbar, the configuration, its state, a bunch of IDs (the one refering EditorBox itself, its parent and its container) and a series of initial parameters that EditorBox want to have (i.e. position or size).

Ediphy.API.Private

This object exposes a dictionary with all kinds of events used and also five methods thata are in charge of emitting and listening the events in a generic way.

An event always have a property called emit that is a text chain and it uniquely identifies respect the rest of them. Also, if this events want to be answered, it should have an answer property that is also a text chain that is used to uniquely identify it (we recommend to use same word as emit does adding the subfix "_back").

The exposed methods of this object are:

• emit: recieves two parameters, the event name that want to be called and an object that will be added itself as payload. With this values, it creates the event as a CustomEvents and emits it.

• listenEmission: recieves two parameters, event name and a function that will be executed when this is listened. Its role is to add to the window object the listener of the event.

• answer: it does the same role as emit but it uses answer property of the indicated event instead of emit to create the event.

• listenAnswer: it does the same as listenEmission with the particularity that the function recieved as parameter to be executed when the event is listened it will not be executed here but it will passed as parameters to cleanUpAndResolve and this will be executed. Also, a reference will be kept to cleanUPAndResolve after passing its correspondant parameters to be able to delete the event listener, as the following method.

• cleanUpAndResolve: its role is to take out from the object window the event listener, or else, it could be added several times and this will be a failure. To delete it, we need to keep the exact reference to the function assigned to the event, and we've seen it in listenAnswer. Recieves three parameters, that are the name of the event initially called in answer, the function that wants to be executed when the event is recieved and the instance of the CustomEvent called in answer with the payload of this method.

Future Improvements

Make innacessible the private part of the API