Hello, I'm testing out the new CK widget system. I am able to create block and inline widgets. However, I don't seem to be able to create inline widgets with "editables". My editables are always read-only. If I change my inline editable to a block editable (i.e. say from <span> tags back to <div> tags), then the "editables" rules that are setup for the widget work - I can edit content defined by the editable.
It just seems that with inline widgets, any editables rules are always ignored, and the widget is essentially read-only. My only option to get editing suport for inline widgets seems to make a dialog with an input field...which I would rather avoid. Since I'd like the user to simply edit the content right in the inline editor, and provide simple formatting such as bold / italic, when need be. Is this a known bug or is there an approach that can be followed today to support editables for inline widgets?
Thanks
Shan
We had to block possibility
We had to block possibility to created nested editables on elements not included in CKEDITOR.dtd.$editable hash (which only contain some stable, block elements). Those elements are considered as safe ones and editables made on other ones (especially on inline elements) may work incorrectly.
However, you can always extend CKEDITOR.dtd.$editable object and see if it works for you stable enough.
I reported a ticket for this: http://dev.ckeditor.com/ticket/10932
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
Thanks reinmar, I'll give it
Thanks reinmar, I'll give it a shot and see how it goes. My scenario is I would like a way to compose footnotes within the editor by using an inline editable widget. The inline editable will be the footnote text. Since the footnote might contain normal styled text, and also italicized text, I thought it would make sense to compose that way versus via a pop-up dialog.
I would advise you not to
I would advise you not to merge a separate field, which in my opinion footnote may be, into other editable. If you can keep it separately, then this is the way to go. But of course it depends on context, so I may be incorrect.
Piotrek (Reinmar) Koszuliński
CKEditor JavaScript Developer
--
CKSource - http://cksource.com
--
Follow CKEditor on: Twitter | Facebook | Google+
I'm not a hardcore ckeditor
I'm not a hardcore ckeditor developer, just started with it and working on a proof of concept using widgets for variables (sort of mailmerge), footnotes, and possibly other stuff. Just so I'm understanding what you're saying, when you say "if you can keep it separately, then this is the way to go". Do you mean "if you can keep the footnotes separately from the actual contents within your editor, then this is the way to go"?
The background for the project is, we're creating an online report builder. The report builder will allow the user to edit their content online, and then generate a Word document of that content. Content can be re-used, and is broken into a data model of section / subsection, where subsection might contain 1 : n paragraphs, which are reusable for other reports.
Any of these paragraphs might have footnotes within them, such that if the paragraphs are reused in other reports, the footnotes should follow on, and number accordingly. What I was thinking as a worst case scenario is using a syntax in the editor to allow writers to mark footnotes, such as ${{footnote - text of footnote}}. But then I thought that an inline widget could be a good fit, since it would ensure that the footnote technical markup remained intact.
The footnotes can't be numbered at this point, as they will be numbered dynamically when reports are generated into Microsoft Word documents.
I think the report writing flow would work better if footnotes were marked into the given paragraphs as widgets, or via some sort of markup syntax, versus as a separate list of footnote text items, along with reference points in the content that would refer to those footnote text items. Sorry for the long thought narrative, hope it helps to understand what we're trying to accomplish and if the approach that is being researched seems to be the best fit in your opinion.
Thanks