tinyMCE setup callback versus onAddEditor - tinymce

When you initialize a tinyMCE editor I have noticed two different ways to get called when the editor is created.
One way is using the setup callback that is part of tinyMCE.init:
tinyMCE.init({
...
setup : function(ed) {
// do things with editor ed
}
});
The other way is to hook up to the onAddEditor event:
tinyMCE.onAddEditor.add(function(mgr,ed) {
// do things with editor ed
});
What are the differences between using these two methods?
Is the editor in a different state in one versus the other? For example, are things not yet loaded if I try to access properties on the editor object.
What are reasons to use one over the other?

The difference here is that tinyMCE.onAddEditor adds code to be executed onthe AddEditor event and fires when a new editor instance is added to the tinymce collection
while the setup setting lets you add events to the editor. It gets executed before the editor instances gets rendered.
One other difference is that setup is to be set inside the tinymce initialization call (the configuration setting) while onAddEditor usually gets called inside a tinymce plugin (but you may also set it inside the setup function).

onAddEditor.add gives warning in the latest TinyMCE 4:
Deprecated TinyMCE API call: <target>.onAddEditor.add(..)
.on(nameofevent, function(){...} ) is the proper way to do this in MCE4 if you don't have the backward-compatibility plugin.

Related

How to customize default SaveHandler of an e4 application?

In my e4 application, I am using the default ISaveHandler(which i have not defined explicitly anywhere) as shown in the image.
I just need to update the icon, title & text of this handler, rest works fine for me for single mPart save or multiple mPart save prompt.
I don't want to create my own save handler UI. Even if I could inherit the original one, that will work for me.
[
That dialog is an inner class of org.eclipse.e4.ui.workbench.renderers.swt.WBWRenderer so you can't get at it. I don't think you have any choice but to write your own ISaveHandler and the dialog.
You might be able to use org.eclipse.e4.ui.internal.workbench.PartServiceSaveHandler to do some of the work.
To use your save handler everywhere set it in the main window context. (see this question).

Can't instantiate multiple tinymce editors in different EPiServer gadgets

I'm developing two gadgets in an EPiServer CMS 9.2 site using the old (MVC Controller) style gadgets. Both gadgets need a rich text editor. I've wired in TinyMCE and it work's fine the first time one of the gadgets instantiates the editor but then fails silently after that.
The code to instantiate the element is triggered using the GadgetAttribute.ClientScriptInitMethod and my init function looks like:
MyGadget.init = function (e, gadget) {
$(gadget.element).find('textarea.tinymce').tinymce({
theme: "modern"
});
};
On subsequent invocations even in the same gadget, the call to tinymce() completes without error but the editor is not present in the DOM (as the element before the related <textarea> and the underlying <textarea> is not visible.
What could be causing this? How might I fix it?
You probably need to call the init function for tinymce and pass a selector.
Something along these lines perhaps? (untested)
tinymce.init({
selector: '#gadgetElementId textarea.tinymce',
});
More info here

not able to register two plugins of touch-ui rte dialog

I am using the steps given in the URL to make a color-picker rte plugin
http://experience-aem.blogspot.in/2015/01/aem-6-sp1-touchui-richtext-editor-color-picker-plugin.html
and at the same time I am making another custom rte plugin to do some text modulation.
But only one of them is working using rte.coralui2 as categories.
and both icons are coming at the same location.
If I disable one js then another is working.
I have registered the plugin with different name and I have also used different variables.
I am not able to make the rte plugin button at different location.
Please suggest the possible solution.
it's possible you are overlaying rather than extending the rte.coralui2 category. I suspect your custom clientLibs are competing with each other and only one is available.
It seems like you are using the same steps provided in the blogpost for creating both the plugins and while doing that, you are using the below code twice with different icons :
if(items.indexOf(ExperienceAEM.TCP_UI_SETTING) == -1){
items.splice(3, 0, ExperienceAEM.TCP_UI_SETTING);
}
So, maybe, the icons are being added at the same place and only one of them is shown.
You should create ExperienceAEM.CuiToolbarBuilder Class only once and add both icons inside that class

Hook into onExecCommand event with TinyMCE 4

I am using TinyMCE 4 but the documentation is terrible. I am trying to provide a live preview of the content in another div (outside of the editor). Right now I am listening to these events:
$(document).on('tinymce:changed tinymce:init', ...)
This is working when text is entered, but it does not trigger when commands are executed (changing existing text to bold for example).
It looks like in TinyMCE 3.x there is an onExecCommand event that does what I want. But I can't find any documentation on how to listen to the global jQuery event like I am doing with with change and init. Does anyone know what event it is firing?
In the migration guide you can find the following example:
// Old event
editor.onInit(editor, args) {
// Custom logic
});
// New event
editor.on('init', function(args) {
// Custom logic
});
So the one problem is to get right event name and the right editor instance :)
The onExecCommand() event becomes 'ExecCommand' in v4.
So adding a handler on command execution should be like this (be sure that editors are already initialized when executing code below):
for (ed_id in tinymce.editors) {
tinymce.editors[ed_id].on('ExecCommand', function(args) {
alert(1);
});
}
For some reason this event fires twice when command is executed. I think you will overcome this issue.
Though this method does not uses jQuery bindings, it works for me and possibly will solve your problem too.
In case this helps anyone else, here is a list of all the events tinymce 4 allows:
http://www.tinymce.com/wiki.php/api4:class.tinymce.Editor

How to keep NPAPI plugins alive in ExtJS tabbed views

I'm trying to use a custom video player NPAPI plugin (view FireBreath) inside an tabbed ExtJS application. The plugin lives in one tab, and the others contain presentations of other non-video data.
When switching from tab to tab, the element that contains the plugin is destroyed, and all plugin state is lost. Is there any way to configure an ExtJS tabbed panel so that the html contained in it is not altered when switching to another tab (just hidden)? The alternative is to re-populate the plugin state when returning to the tab, but this would be associated with an unacceptable delay (mostly while waiting for video key frames).
Thanks,
O
I don't know about your ExtJS approach, if you can solve it on that side that would of course be preferrable.
However, if you can't, you can avoid the reinitialization by moving the stream handling to a helper application that is running in the background. The plugin would launch it as needed and receive the stream data from it after registering for it.
The helper would be told when to kill a stream and possibly kill it by itself after some timeout (to avoid session leaks in case of crashing plugins etc.).
I was about to consider a helper application as recommended above, or look into rewriting the plugin to be windowless. Both might be more robust solutions for other JS frameworks.
Fortunately, the solution ended up being simpler than this, at least for ExtJS. By default, ExtJS sets "display: none" on the tabbed view's div whenever it is undisplayed, which calls the plugin destructor. After doing a little more looking through their enormous API, ExtJS has a parameter hideMode as part of the Ext.panel.Panel base class:
'display' : The Component will be hidden using the display: none style.
'visibility' : The Component will be hidden using the visibility: hidden style.
'offsets' : The Component will be hidden by absolutely positioning it out of the visible area of the document. This is useful when a hidden Component must maintain measurable dimensions. Hiding using display results in a Component having zero dimensions.
Defaults to: "display"
Setting the parent Panel that contains the plugin to hideMode: 'offsets' fixed the problem perfectly.