Ticket #3367 (closed New Feature: fixed)
Introduce range iterator API
| Reported by: | garry.yao | Owned by: | fredck |
|---|---|---|---|
| Priority: | Normal | Milestone: | CKEditor 3.0 |
| Component: | General | Version: | |
| Keywords: | Confirmed Review+ | Cc: |
Description (last modified by garry.yao) (diff)
There're many cases when we need to traverse the range from the start boundary node to the end boundary node, it's archiveable by the following codes:
var boundaryNodes = range.getBoundaryNodes();
var firstNode = boundaryNodes.startNode;
var lastNode = boundaryNodes.endNode.getNextSourceNode( true );
var node = firstNode.getNextSourceNode();
while( node )
{
if ( node.getName() == 'span' && currentNode.getAttribute( '_fck_bookmark' ) )
{
node = node.getNextSourceNode();
continue;
}
// Processing logic...
node = node.getNextSourceNode();
}
It's cumbersome due to at least two reasons:
- The collapsed range problem reported at #3292;
- It make code DUP at every plugin for the same logic;
It's necessary to introduce an API for this feature with dom iterator, which already holds a method for iterating over paragraphs. So after the API, other plugins should walking through the range as easy as using the iterator.
Attachments
Change History
comment:2 Changed 4 years ago by fredck
- Status changed from new to assigned
- Type changed from Bug to New Feature
Actually, the idea here is not really replicating the DOM Iterator, but the DOM Walker. I mean, making it possible to traverse all nodes available inside a range boundaries.
comment:3 Changed 4 years ago by fredck
- Keywords Review? added
This patch brings an important change to the DOM Walker concept. It's now limited to a range boundaries, instead of a start/end nodes pair. It makes the walker much more powerful and easy to control.
The few points currently using the walker have been modified to reflect the changes. Several parts of the editor code can be rewritten, simplified and optimized after it.
I've left part of the code commented. Those are features we are not using right now in the editor, but we may need them in the future. As we're uncertain of it at this moment it's better to just leave them there.
comment:5 follow-up: ↓ 6 Changed 4 years ago by garry.yao
- Keywords Review- added; Review? removed
The patch is quite good, while there's two issues:
- The default guard function logic on L48 and L62 of document boundary check is invalid.
- The guard is not performed on specifically the boundary nodes, Please check the attached TC for this problem.
- Some iteration state could be further cached instead of been calculated every iteration, e.g. L71-L82.
- The walker should provide a 'reset' function to facilitate reusing of the walker on same range.
Changed 4 years ago by garry.yao
- Attachment test_range_checkStartOfBlock.patch added
Unit Test Case
comment:6 in reply to: ↑ 5 Changed 4 years ago by fredck
- Keywords Review? added; Review- removed
I've appended the new tests to the patch.
Replying to garry.yao:
- Some iteration state could be further cached instead of been calculated every iteration, e.g. L71-L82.
I've considered that the guard function may change during the iteration. Let's leave it this way for now, just to be safe.
- The walker should provide a 'reset' function to facilitate reusing of the walker on same range.
We don't need it into the code currently. It should be introduced if found needed later, but only if the recreation of the object is really hard to achieve.
comment:7 follow-up: ↓ 8 Changed 4 years ago by garry.yao
- Keywords Review- added; Review? removed
Another bug been identified at #3477, please check test_range_checkStartOfBlock.patch for it, though it's not related to the walker core.
comment:9 Changed 4 years ago by fredck
- Status changed from assigned to closed
- Resolution set to fixed
Fixed with [3463].
comment:10 Changed 4 years ago by garry.yao
- Status changed from closed to reopened
- Keywords Review+ removed
- Resolution fixed deleted
Minor issue that document boundary check is invalid, see the attached test_walker_stopAtBody.patch.
comment:13 Changed 4 years ago by fredck
- Status changed from reopened to closed
- Resolution set to fixed
Garry's patch has been committed with [3465].
Please do not reopen tickets for related fixes, opening new tickets instead.

Fred said he'll take care this ticket and refacting task after this fix will be handled by other new opening tickets.