Add support for internal pages in link dialog

[Piotrek Koszuliński]

Pull request: ​https://github.com/ckeditor/ckeditor-dev/pull/9

This feature would be very valuable for CMSes.

[Wiktor Walc]

Few thoughts based on my past experience with link browsers.

1. There is a "Link" tab in the Image dialog where such link browser would be needed as well.

2. "Tree view" is definitely needed, to present the structure of a site in order to make it easier to find the right page

3. There should be at least two few methods o defining the list of available links.

a) an array/object with the list of links (and page titles), might be useful for small sites.

b) a callback function that should return available links. This is to make it possible to load links on demand, depending e.g. on the context where editor is running. Even on the same page, different instances may need different sets of links.

Ad 3b) The callback function should not be called just once. On large sites it is nearly impossible to load and return all links at once. Large sites will have nested groups of links and the first call will list only the top level set of links:

[
  {
     url : '/',
     title : 'Home page'
  },
  {
     url : '/articles',
     title : 'Articles',
     hasChildren : true
  },
  {
     url : '/blog',
     title : 'Blog',
     hasChildren : true
  },
  {
     url : '/wiki',
     title : 'Wiki',
     hasChildren : true
  }
]

If a link has hasChildren property set to true, then it should be possible to expand further the tree with links using e.g. [+]. In such case another callback function should be called with the parent url passed as an argument, to load child links.

The result after the first call to getInternalLinks()

[+] Articles
[+] Blog
    Home page
[+] Wiki

Now when user clicks [+] next to Wiki, getInternalLinks('/wiki') is called. If it returns:

[
  {
     url : '/wiki/developers_guide',
     title : 'Developers Guide',
     hasChildren : true
  },
  {
     url : '/wiki/users_guide',
     title : 'Users Guide',
     hasChildren : true
  }
]

then we should end up with:

[+] Articles
[+] Blog
    Home page
[-] Wiki
    [+] Developers Guide
    [+] User Guide

I'm wondering if it would not be even better to pass the whole object that represents the link as an argument instead of just an URL. This way if someone returns more information about the link (e.g. ID in a database):

  {
     url : '/wiki',
     title : 'Wiki',
     hasChildren : true,
     id : 21
  }

he will be able to use this additional data to retrieve child links.

4. I believe that sorting by page title should not be done automatically.

[Wim Leers]

Replying to wwalc:

I agree with all of wwalc's notes (they're very clearly laid out too!). The only two things I have to add are:

• Please don't make the tree view compulsory.
• Please also provide an "autocomplete callback" style functionality as well; where the server side can decide what kind of matching (prefix, partial, fuzzy) to perform on which aspect of links (title, description, URL).

[Piotrek Koszuliński]

#288 was marked as duplicate.

This ticket has more up to date comments.

[Matthew Leffler]

Subscribing.

[Bram Goffings]

Yeah I agree with the above. A Tree structure in a cms isn't important at all. An autcomplete widget is! :) Btw I'm only used to the "old" ckeditor. Just tested the demo and the link widget is already an improvement.

[Wim Leers]

Replying to aspilicious:

Yeah I agree with the above. A Tree structure in a cms isn't important at all. An autcomplete widget is! :)

Thanks for chiming in, aspilicious :) (He's also a Drupal core contributor.)

I wouldn't say that a tree structure is not important at all for a CMS. That's oversimplifying to the other extreme. There are definitely valid use cases for CMSes that use a tree paradigm as the central concept of structuring and navigating content. It's not because Drupal doesn't do that, that CKEditor should not support tree-based navigation as well.