Ticket #7240 (closed New Feature: fixed)

Opened 4 years ago

Last modified 3 years ago

CKEditor should expose the names/ids of dialog windows, tabs and fields

Reported by: Anna Owned by: Saare
Priority: Normal Milestone: CKEditor 3.6
Component: UI : Dialogs Version: 3.0
Keywords: Cc:

Description

These values are crucial for all sorts of customizations and it is vital that we make them accessible to developers. By accessible I don't mean having to search for them somewhere inside the millions of lines of CKEditor source code.

This information must be available in the API docs and auto-updated on all changes of the dialog window source codes.

Please note this is also one of the most asked for problem areas on our forum.

Attachments

7240.patch (5.1 KB) - added by Saare 4 years ago.
7240_2.patch (7.5 KB) - added by Saare 4 years ago.
7240_3.patch (10.2 KB) - added by Saare 3 years ago.
7240_4.patch (10.2 KB) - added by Saare 3 years ago.
devtools.html (3.7 KB) - added by Anna 3 years ago.
devtools sample
index.html (4.6 KB) - added by Anna 3 years ago.
index.html file for the _samples folder

Change History

comment:1 Changed 4 years ago by wwalc

  • Keywords Discussion added

When CKEditor is running source mode we could add an extra attribute to each UI element in the dialog, which would hold the real path to the element: "tabId:elementId".

This way, when using the inspector in Firebug on the URL field of the Image dialog, instead of the following:

<input type="text" aria-required="true" aria-labelledby="cke_346_label" id="cke_345_textInput" class="cke_dialog_ui_input_text">

one would see also:

"info:txtUrl"

In release version this extra information could be hidden, to avoid performance issues.

comment:2 Changed 4 years ago by fredck

What about a plugin that shows tooltips when rolling-over the dialog elements?

comment:3 Changed 4 years ago by Saare

Considering that this information is to be viewed by developers, I don't think that adding attribute or a tooltip plugin is the right way to go.
I tend to agree with Anna more here, we can develop a tool that creates a list of dialog, tab and field names into a special document that is to be distributed or put online.
If we go "old fashion", we can even do that manually as changes in dialog names/tab names/field names is rather rare.

comment:4 Changed 4 years ago by fredck

I meant a developer plugin in fact, which must be enable by hand, just like the uicolor plugin. It could also include other information, like the element type. It'll be definitely usable... it's enough to open the dialog and have everything there, including custom fields, which would not be documented by us.

comment:6 Changed 4 years ago by wwalc

A tooltip plugin sounds like a way to go.

The problem with having it described in the documentation is that:

  1. Some dialogs contain lot of elements, so the list of elements for the Link dialog would be long, how could you design it so that it was easy to find the element you're looking for?
  2. Dialogs added by thirdparty plugins will still not be documented
  3. Such a tooltip plugin could show even much more information in the future, like the current definition of this element etc.

comment:7 Changed 4 years ago by Saare

Ok, I see your points, I'm ok with that.

comment:8 Changed 4 years ago by Anna

  • Status changed from new to confirmed

Sounds great to me, too, and I am sure this tool will really help the developers get up to speed with customizing CKEditor. As stated above, it can also be extended to cover other functionalities dedicated to CKEditor developers so I am all for that.

comment:9 Changed 4 years ago by Saare

  • Status changed from confirmed to assigned
  • Owner set to Saare

Changed 4 years ago by Saare

comment:10 Changed 4 years ago by Saare

  • Status changed from assigned to review

comment:11 Changed 4 years ago by Anna

Great job, Saar, I really like it.

One problem I see is that the tooltips seem to interfere with the input fields that they cover:

  • If you click the text field inside the tooltip and try to write something, the characters are not entered.
  • If you click the text field outside the tooltip, the characters are entered, but the tooltip covers them so it's not immediately clear whether filling the field works or not.

Perhaps the click event on the field should cause the tooltip to hide and uncover the field?

Would it make any sense to also show the ids of the dialog window buttons? I can see the "Clear" button from the color picker has a tooltip, for example, while in the Selection Field dialog window the "Down" button has one (albeit with "undefined" id) and the rest of them don't. Is removing the buttons a valid use case for CKEditor developers?

Changed 4 years ago by Saare

comment:12 Changed 4 years ago by Saare

New patch covers everything me and Anna have discussed about, including:

  • Some buttons didn't have tooltips.
  • Tooltips for tab names as well.
  • Positioning of the tooltip now doesn't interupt editing.
  • Added padding for text.

comment:13 Changed 3 years ago by wwalc

  • Status changed from review to review_failed
  • Is it possible to display the tooltip straight below the element? When viewing the Link dialog, the tooltip for the URL field looks a bit bad on the right side.
  • How about using something like:
    <div tabindex="-1" id="cke_tooltip" style="z-index: 10020; top: 513.5px; left: 681px; display: block; padding: 5px; opacity: 1; border: 2px solid #333;">
    <h2 style="font-size: 1.1em; border-bottom: 1px solid; margin: 0; padding: 0 5px 5px 0;">Element information</h2>
    <ul style="padding: 0pt; list-style-type: none;">
    <li><strong>Dialog name:</strong> link<br></li>
    <li><strong>Tab id:</strong> info</li>
    <li><strong>Element id:</strong> url</li>
    <li><strong>Element type:</strong> <a style="color:white" href="http://docs.cksource.com/ckeditor_api/symbols/CKEDITOR.dialog.definition.textInput.html" target="_blank">text</a></li>
    </ul>
    </div>
    

to display the tooltip? I'd format a bit the tooltip box and add an extra information: the type of the element with a direct link to the documentation about it.

  • When element ID is undefined, I'd display something like "not set".
  • In the second patch lang/en.js is missing.
  • Do we really need to add CSS rules to _source/skins/xyz/dialog.css? I'd say that plugins should be totally separated from the editor.
  • The scaytcheck dialog is broken when this plugin is enabled:
    el is null
    el.on( 'mouseover', function(), line 100
    

Changed 3 years ago by Saare

comment:14 Changed 3 years ago by Saare

  • Status changed from review_failed to review

Putting <not set> instead of a missing ID is not relevant, as the whole dialog system relies on the element IDs, and the plugin will silently fail without them (the cause of the last bug described by Anna in comment:11). We should make suere we got IDs all across our core dialog. The patch handles the ones Wiktor and I found.
Besides that, everything we've discussed about and an additional minor bug fix are included in the 3rd patch.

comment:15 Changed 3 years ago by Anna

I really love the current version, from the user's perspective, that is. This is even better than I initially thought we can come up with -- great job, Saar. I am sure this will become an invaluable tool for the CKEditor developers. R+ from me.

comment:16 Changed 3 years ago by wwalc

  • Keywords Discussion removed
  • Type changed from Task to New Feature
  • Milestone set to CKEditor 3.6

comment:17 Changed 3 years ago by fredck

  • Status changed from review to review_failed

Nothing to add. Nice job!

Please just remove the "dialog" require. This tool should not change the editor. So it should not load the dialog plugin if no other plugin is loading it.

Changed 3 years ago by Saare

comment:18 Changed 3 years ago by Saare

  • Status changed from review_failed to review

comment:19 Changed 3 years ago by fredck

  • Status changed from review to review_passed

comment:20 Changed 3 years ago by alfonsoml

There's something very obvious missing in the patch, and it's a sample page with the plugin so people can use it easily, as well as allowing us to use it at any time in the rev. site.

I would suggest to apply the approved patch and then add a simple test page (another extra plugin with missing sample is the tableresize)

comment:21 Changed 3 years ago by Anna

Good catch, Alfonso. Attached is my proposal (devtools.html sample) and a modified index.html file from the _samples folder.

Changed 3 years ago by Anna

devtools sample

Changed 3 years ago by Anna

index.html file for the _samples folder

comment:22 Changed 3 years ago by Saare

  • Status changed from review_passed to closed
  • Resolution set to fixed

HOW DID WE NOT THINK OF THAT?! ;)
Thanks Alfonso, Anna.
Fixed with [6679].

comment:23 Changed 3 years ago by Saare

Oops, committed on trunk.
Reverted with [6680] and fixed again on the branch with [6681].

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy