Opened 10 years ago

Closed 10 years ago

#2871 closed Task (fixed)

Implement DOM range iterator.

Reported by: Martin Kou Owned by: Martin Kou
Priority: Normal Milestone: CKEditor 3.0
Component: General Version: SVN (FCKeditor) - Retired
Keywords: Review+ Cc:

Description

#2864 and #2865 depends on DOM range iterator to work. So the DOM range iterator must be implemented first as a separate plugin.

Attachments (4)

2871.patch (21.1 KB) - added by Martin Kou 10 years ago.
2871_2.patch (21.4 KB) - added by Martin Kou 10 years ago.
2871_3.patch (23.6 KB) - added by Martin Kou 10 years ago.
2871_4.patch (21.8 KB) - added by Martin Kou 10 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 years ago by Martin Kou

Keywords: Review? added
Status: newassigned

This patch also adds trim(), ltrim() and rtrim() under CKEDITOR.dom.node. Also it moved getFirst() and getLast() to CKEDITOR.dom.node, as those functions may be used outside of elements.

Changed 10 years ago by Martin Kou

Attachment: 2871.patch added

Changed 10 years ago by Martin Kou

Attachment: 2871_2.patch added

comment:2 Changed 10 years ago by Martin Kou

Fixed a bug which causes JavaScript errors in CKEDITOR.dom.node::rtrim().

Changed 10 years ago by Martin Kou

Attachment: 2871_3.patch added

comment:3 Changed 10 years ago by Martin Kou

Another update - refactored the block boundary checking logic in dom walker to CKEDITOR.dom.element::isBlockBoundary(), since both the dom walker and the dom iterator code need it. Also, it's found to be needed by the list (#2864) and indent (#2865) plugins being developed.

comment:4 Changed 10 years ago by Frederico Caldeira Knabben

Keywords: Review- added; Review? removed
  • The "domiterator" is the kind of plugin that don't have to go inside the plugins configuration. It's loaded only if we have other plugins that depend on it.
  • As I could note, things have been copied from V2 as is, with no adaptation to V3. It means we'll have to work more on this code later.
  • There was a reason for having getFirst and getLast inside element, and not on node. Actually, they are not useful outside the element scope. For example, "textNode.getFirst()" means nothing. I don't care about the W3C DOM here, as our intention is not to implement it. We have a custom implementation that can be clearer, and so we should avoid such DOM generalities. If part of our code is supposed to do "textNode.getFirst()", then our code must be fixed, as it only impacts on performance, as we know it'll never return a node. Anything that's element specific must go inside the element class only.

Changed 10 years ago by Martin Kou

Attachment: 2871_4.patch added

comment:5 Changed 10 years ago by Martin Kou

Keywords: Review? added; Review- removed

comment:6 Changed 10 years ago by Frederico Caldeira Knabben

Keywords: Review+ added; Review? removed

comment:7 Changed 10 years ago by Martin Kou

Resolution: fixed
Status: assignedclosed

Fixed with [3050].

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