Per CKEditor, initialize widget added with insertElement, we are doing an insertElement() and then initializing with initOn(). The problem is that some of the elements we are inserting are not supposed to be widgets and initOn() makes them widgets and the context menu doesn't work right. I am having trouble finding any properties inside the item/element to tell if something is/is not a widget so I can then call initOn().
Cross-posted downstream on Drupal.org here https://www.drupal.org/node/2466297
First of all - which element do you mean?
(Note: In this section I am assuming that a widget was correctly and fully initialised.)
Widget element
A widget can obviously consists of many elements. One of them is called the "widget element" and this is the element which you "upcasted" and which you can later access through widget.element.
Since CKEditor 4.5.0 there will be such method available:
Widget.isDomWidgetElement = function( node ) {
return node.type == CKEDITOR.NODE_ELEMENT && node.hasAttribute( 'data-widget' );
};
You can of course already use this code to check if a given node is a widget element.
Widget wrapper
Second important element is the widget's wrapper. It is created during data processing if a widget element was marked to be upcasted or when initOn() is called if the widget element wasn't wrapped yet. You can access this element through the widget.wrapper property.
Since CKEditor 4.5.0 there will be a following method available:
Widget.isDomWidgetWrapper = function( node ) {
return node.type == CKEDITOR.NODE_ELEMENT && node.hasAttribute( 'data-cke-widget-wrapper' );
};
And again - you can use this code already.
Important note here - since you mention insertElemet() in your question. As I explained in CKEditor, initialize widget added with insertElement editor#insertElement() does not trigger data processing. Therefore, element that you insert is inserted as is. This means that the widget wrapper is not created during insertion and will be created once you call initOn().
Finding widgets by any element
Many times you want to find a widget instance by some element that you have (any element that can be inside a widget). There's a useful method for that: getByElement().
What should become a widget? Aka - how to deal with editor.insertElement()?
You mentioned that you use editor.insertElement() and that you don't know which elements are supposed to be widgets. This should never happen. editor.insertElement() is a quite low level method which will not do all the data processing and upcasting magic which editor.insertHtml() does. It means that it is supposed to be used in a different case - when you want to insert exactly the element that you have.
For instance, your table plugin is building a table structure to be inserted into editor. You know that the table is empty, so you control every bit of it (other plugins should not interfere here). It is also important that it's the table's plugin decision, not e.g. a template's plugin decision. The table's plugin control the table feature, while the template plugin only uses tables. So in such case, when you have a full control, you can use editor.insertElement(). Then you always know what you insert and what is supposed to become a widget.
In all other scenarios you should use editor.insertHtml(), so the whole data processing layer is triggered. Thanks to it other features like the widgets system, the link plugin (which turns empty anchors into fake objects), etc. can prepare the data that you insert to be fully editable and integrated.
Tl;dr
If your plugin knows what it does, it can use editor.insertElement(), but since it knows what it does it will know which inserted element must become a widget.
If your plugin does not fully control the situation, then you should use the editor.isertHtml() method which is far more automated and will turn proper elements into widgets based on the upcast callbacks.
Related
I've searched thru Corvid docs and Stack, not finding anything.
Is there a way to appendChild() in Wix Corvid(Code)?
EDIT: Wix does not allow DOM access directly. I assumed that people answering this would know i was looking for an alternative to appencChild and knew this method could not be used as is in Wix.
so to clarify: is there a way to add a child to a parent element using Wix's APIs?
It depends what you are trying to achieve,
the only thing off the top of my head is adding more items to a repeater
which you can do by first getting the initial data from the repeater, adding another item to array and reassign the data property of the repeater
const initialData = $w('#repeater').data
const newItem = {
_id: 'newItem1', // Must have an _id property
content: 'some content'
}
const newData = [...initialData, newItem]
$w('#repeater').data = newData
https://www.wix.com/corvid/reference/$w.Repeater.html#data
In Corvid, you cannot use any function which accesses the DOM.
Coming from one of the developers of Corvid:
Accessing document elements such as div, span, button, etc is off-limits. The way to access elements on the page is only through $w. One small exception is the $w.HtmlComponent (which is based on an iFrame). This element was designed to contain vanilla HTML and it works just fine. You just can't try to trick it by using parent, window, top, etc.
Javascript files can be added to your site's Public folder, but the same limitations apply - no access to the DOM.
Read more here: https://www.wix.com/corvid/forum/main/comment/5afd2dd4f89ea1001300319e
In my project there is one usage case: user click one button and then copy some data to clipboard for next step.
The copied data is related to the clicked button, and is stored in the component state.
I do some search, and find the potential solution as following:
function copyToClipboard(text){
var dummy = document.createElement("input");
document.body.appendChild(dummy);
dummy.setAttribute('value', text);
dummy.select();
document.execCommand("copy");
document.body.removeChild(dummy);
}
to some extend, we need to create a dummy element, set the copied data to the dummy element and select the element, then execute the execCommand(copy) method.
is it possible to do this without creating dummy element? I know there are some react plugin about clipboard, but I just want to use vanilla javascript. thank you
Your solution works well.
If the value you want to copy is not yet rendered on the DOM, your Document.createElement('input')... method is a good way to create a document node that Document knows about, but that is not visible to the user. Once you use .createElement() you can then call execCommand() on it to copy the value to the clipboard.
The execCommand() method is exposed by HTML5's Document. This means Document has to know about the node you are targeting before you can use the method (this is called Selection).
However, if you want to copy text from an element already rendered on the dom (e.g an input in a form), you could use React's callback ref. Here's a good example of using ref to do this. It's pretty simple, so using a library is likely to be overkill.
My web view has several elements, which can be edited by the user to update model objects in the OS X host application.
For some of these elements, when editing delegate methods like webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting: are called, the range arguments are inside a #document-fragment container -without any attribute information at all.
Thus, it is nearly impossible to figure out, what node is being edited - as all id attributes have been stripped.
po proposedRange.commonAncestorContainer.path
/#document-fragment/DIV/DIV/DIV/#text
For other input elements, I get the whole DOM path, with all attribute information intact:
po proposedRange.commonAncestorContainer.path
/#document/HTML/BODY/DIV/DIV/DIV/TABLE/TBODY/TR/TD/DIV/DIV/DIV/DIV/TABLE/TBODY/TR/TD/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/DIV/H1/SPAN/#text
Any ideas what could cause this difference in behavior?
I searched the Prototype docs but found nothing. Did I miss something, or is there no such thing as onshow? I want to call a function when an element (a div in my case) is made visible. Is there such functionality in the Prototype framework? If not, I need a push in the right direction so I can solve it another way.
Thanks!
If you are asking if there is an event that is fired when the .show() method is called on elements there is not.
But you can test if an element is visible by using the $('myelementid').visible() method.
Also a different way I have done it in the past is using the Script.aculo.us .appear() method which has a afterFinish callback - for example
$('myelementid').appear({'afterFinish':function(effect){
//the afterFinish callback passes the effect as the first parameter
//call other function with element
otherfunction(effect.element);
});
technically you would only need to load the effects.js file of Script.aculo.us instead of all of the library to get the core effects methods.
I have an issue about ajax.
make an example: I have a menu list (ul li) and by default the first one has class 'current'.
if I click the second item assign class 'current' to him with jquery and remove it from the previous one.
Now, I need reload the menu list with ajax, so I call the ajax function that calls a php function that return an update html list.
But in this way I lose the 'current' class from the second list, that before I assigned with jquery.
Happens to me many times to have this type of problems.. What is the correct solution to solve it?
one way of doing it is to get the index of the li with the class current and in the ajax success callback assign the current class to the appropriate index
look at this fiddle to get the index of the li http://jsfiddle.net/3nigma/zyayj/
in your success callback
success:function(data){
var i = index -1; // index is zero based and eq() is 1 based
$("ul li:eq(i)").addClass("current");
}
I think your question indicates that you don't already know that web pages are "stateless", meaning that they do not "automatically" hold or store anything that you do with them.
Please see my answer ho a privious question which summarizes the ways to deal with retaining the state of things - the principles would remain the same for your menus.
Stateless HTML