wikimedia/mediawiki-extensions-VisualEditor
1
0
Fork 0
mirror of https://gerrit.wikimedia.org/r/mediawiki/extensions/VisualEditor synced 2024-11-29 16:44:51 +00:00
Code Issues Packages Projects Releases Wiki Activity
mediawiki-extensions-Visual.../modules/ve/test/dm/ve.dm.SurfaceFragment.test.js

514 lines
19 KiB
JavaScript
Raw Normal View History

JSDuck: Generated code documentation! See CODING.md for how to run it. Mistakes fixed: * Warning: Unknown type function -> Function * Warning: Unknown type DOMElement -> HTMLElement * Warning: Unknown type DOM Node -> HTMLElement * Warning: Unknown type Integer -> Mixed * Warning: Unknown type Command -> ve.Command * Warning: Unknown type any -> number * Warning: Unknown type ve.Transaction -> ve.dm.Transaction * Warning: Unknown type ve.dm.AnnotationSet -> ve.AnnotationSet * Warning: Unknown type false -> boolean * Warning: Unknown type ve.dm.AlienNode ve.dm doesn't have a generic AlienNode like ve.ce -> Unknown type ve.dm.AlienInlineNode|ve.dm.AlienBlockNode * Warning: Unknown type ve.ve.Surface -> ve.ce.Surface * ve.example.lookupNode: -> Last @param should be @return * ve.dm.Transaction.prototype.pushReplace: -> @param {Array] should be @param {Array} * Warning: ve.BranchNode.js:27: {@link ve.Node#hasChildren} links to non-existing member -> (removed) * Warning: ve.LeafNode.js:21: {@link ve.Node#hasChildren} links to non-existing member -> (removed) Differences fixed: * Variadic arguments are like @param {Type...} [name] instead of @param {Type} [name...] * Convert all file headers from /** to /*! because JSDuck tries to parse all /** blocks and fails to parse with all sorts of errors for "Global property", "Unnamed property", and "Duplicate property". Find: \/\*\*([^@]+)(@copyright) Replace: /*!$1$2 * Indented blocks are considered code examples. A few methods had documentation with numbered lists that were indented, which have now been updated to not be intended. * The free-form text descriptions are parsed with Markdown, which requires lists to be separated from paragraphs by an empty line. And we should use `backticks` instead of {braces} for inline code in text paragraphs. * Doc blocks for classes and their constructor have to be in the correct order (@constructor, @param, @return must be before @class, @abstract, @extends etc.) * `@extends Class` must not have Class {wrapped} * @throws must start with a {Type} * @example means something else. It is used for an inline demo iframe, not code block. For that simply indent with spaces. * @member means something else. Non-function properties are marked with @property, not @member. * To create a link to a class or member, in most cases the name is enough to create a link. E.g. Foo, Foo.bar, Foo.bar#quux, where a hash stands for "instance member", so Foo.bar#quux, links to Foo.bar.prototype.quux (the is not supported, as "prototype" is considered an implementation detail, it only indexes class name and method name). If the magic linker doesn't work for some case, the verbose syntax is {@link #target label}. * @property can't have sub-properties (nested @param and @return values are supported, only @static @property can't be nested). We only have one case of this, which can be worked around by moving those in a new virtual class. The code is unaltered (only moved down so that it isn't with the scope of the main @class block). ve.dm.TransactionProcessor.processors. New: * @mixins: Classes mixed into the current class. * @event: Events that can be emitted by a class. These are also inherited by subclasses. (+ @param, @return and @preventable). So ve.Node#event-attach is inherited to ve.dm.BreakNode, just like @method is. * @singleton: Plain objects such as ve, ve.dm, ve.ce were missing documentation causing a tree error. Documented those as a JSDuck singleton, which they but just weren't documented yet. NB: Members of @singleton don't need @static (if present, triggers a compiler warning). * @chainable: Shorthand for "@return this". We were using "@return {classname}" which is ambiguous (returns the same instance or another instance?), @chainable is specifically for "@return this". Creates proper labels in the generated HTML pages. Removed: * @mixin: (not to be confused with @mixins). Not supported by JSDuck. Every class is standalone anyway. Where needed marked them @class + @abstract instead. Change-Id: I6a7c9e8ee8f995731bc205d666167874eb2ebe23
2013-01-04 08:54:17 +00:00
/*!
Major Documentation Cleanup * Made method descriptions imperative: "Do this" rather than "Does this" * Changed use of "this object" to "the object" in method documentation * Added missing documentation * Fixed incorrect documentation * Fixed incorrect debug method names (as in those VeDmClassName tags we add to functions so they make sense when dumped into in the console) * Normalized use of package names throughout * Normalized class descriptions * Removed incorrect @abstract tags * Added missing @method tags * Lots of other minor cleanup Change-Id: I4ea66a2dd107613e2ea3a5f56ff54d675d72957e
2013-01-15 23:38:49 +00:00
* VisualEditor DataModel SurfaceFragment tests.
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
*
Bump copyright notice year range to -2013 over -2012 199 files touched. Whee! Change-Id: Id82ce4a32f833406db4a1cc585674f2bdb39ba0d
2013-02-19 23:37:34 +00:00
* @copyright 2011-2013 VisualEditor Team and others; see AUTHORS.txt
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
* @license The MIT License (MIT); see LICENSE.txt
*/
QUnit.module( 've.dm.SurfaceFragment' );
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
/* Tests */
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
QUnit.test( 'constructor', 8, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface );
// Default range and autoSelect
assert.strictEqual( fragment.getSurface(), surface, 'surface reference is stored' );
assert.strictEqual( fragment.getDocument(), doc, 'document reference is stored' );
assert.deepEqual( fragment.getRange(), new ve.Range( 0, 0 ), 'range is taken from surface' );
Reversed the default value of autoSelect in surface fragments Arguments with default truthy arguments are evil Change-Id: I3fb972af1b8f52837497950281c537fe09eb7975
2012-10-13 00:29:32 +00:00
assert.strictEqual( fragment.willAutoSelect(), true, 'auto select by default' );
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
assert.strictEqual( fragment.isNull(), false, 'valid fragment is not null' );
// Invalid range and autoSelect
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( -100, 100 ), 'truthy' );
assert.equal( fragment.getRange().from, 0, 'range is clamped between 0 and document length' );
assert.equal( fragment.getRange().to, 61, 'range is clamped between 0 and document length' );
Reversed the default value of autoSelect in surface fragments Arguments with default truthy arguments are evil Change-Id: I3fb972af1b8f52837497950281c537fe09eb7975
2012-10-13 00:29:32 +00:00
assert.strictEqual( fragment.willAutoSelect(), false, 'noAutoSelect values are boolean' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
} );
QUnit.test( 'onTransact', 1, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
surface = new ve.dm.Surface( doc ),
fragment1 = new ve.dm.SurfaceFragment( surface, new ve.Range( 1, 56 ) ),
fragment2 = new ve.dm.SurfaceFragment( surface, new ve.Range( 2, 4 ) );
fragment1.removeContent();
assert.deepEqual(
fragment2.getRange(),
new ve.Range( 1, 1 ),
'fragment ranges are auto-translated when transactions are processed'
);
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment1.destroy();
fragment2.destroy();
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
} );
QUnit.test( 'adjustRange', 3, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 20, 21 ) ),
adjustedFragment = fragment.adjustRange( -19, 35 );
assert.ok( fragment !== adjustedFragment, 'adjustRange produces a new fragment' );
assert.deepEqual( fragment.getRange(), new ve.Range( 20, 21 ), 'old fragment is not changed' );
assert.deepEqual( adjustedFragment.getRange(), new ve.Range( 1, 56 ), 'new range is used' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
} );
QUnit.test( 'collapseRange', 3, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 20, 21 ) ),
collapsedFragment = fragment.collapseRange();
assert.ok( fragment !== collapsedFragment, 'collapseRange produces a new fragment' );
assert.deepEqual( fragment.getRange(), new ve.Range( 20, 21 ), 'old fragment is not changed' );
assert.deepEqual( collapsedFragment.getRange(), new ve.Range( 20, 20 ), 'new range is used' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
collapsedFragment.destroy();
fragment.destroy();
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
} );
UnicodeJS library to implement Unicode standards Initially just with a Wordbreak module to implement Unicode standard on 'Default Word Boundaries'. Due to it's standaloneability this has been written as a separate library. Non-BMP characters are currently not supported. Bug: 44085 Change-Id: Ieafa070076f4c36855684f6bc179667e28af2c25
2013-03-18 11:31:14 +00:00
QUnit.test( 'expandRange (closest)', 1, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
surface = new ve.dm.Surface( doc ),
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 20, 21 ) ),
exapandedFragment = fragment.expandRange( 'closest', 'invalid type' );
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
assert.strictEqual(
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
exapandedFragment.isNull(),
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
true,
'closest with invalid type results in null fragment'
);
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
exapandedFragment.destroy();
fragment.destroy();
Added some unit tests for ve.dm.SurfaceFragment Also: * Made a fragment with a null range become a null fragment * Fixed incorrect order of arguments for binding a handler to transact event * Added getters for surface, document and range * Fixed several instances of passing a document instead of a surface into the constructor of a new surface fragment * Fixed closest mode in expandRange - needed to check if parent existed before checking for it's type * Fixed uses of ve.Transaction (doesn't exist) that were supposed to be uses of ve.dm.Transaction (does exist) Change-Id: Ide13d9d2d1637399188c98c2e8b6e0826caeecc4
2012-08-17 17:48:40 +00:00
} );
UnicodeJS library to implement Unicode standards Initially just with a Wordbreak module to implement Unicode standard on 'Default Word Boundaries'. Due to it's standaloneability this has been written as a separate library. Non-BMP characters are currently not supported. Bug: 44085 Change-Id: Ieafa070076f4c36855684f6bc179667e28af2c25
2013-03-18 11:31:14 +00:00
QUnit.test( 'expandRange (word)', 1, function ( assert ) {
var i, doc, surface, fragment, newFragment, range, word, cases = [
{
phrase: 'the quick brown fox',
range: new ve.Range( 6, 13 ),
expected: 'quick brown',
msg: 'range starting and ending in latin words'
},
{
phrase: 'the quick brown fox',
range: new ve.Range( 18, 12 ),
expected: 'brown fox',
msg: 'backwards range starting and ending in latin words'
},
{
phrase: 'the quick brown fox',
range: new ve.Range( 7, 7 ),
expected: 'quick',
msg: 'zero-length range'
}
];
QUnit.expect( cases.length*2 );
for ( i = 0; i < cases.length; i++ ) {
doc = new ve.dm.Document( cases[i].phrase.split('') );
surface = new ve.dm.Surface( doc );
fragment = new ve.dm.SurfaceFragment( surface, cases[i].range );
newFragment = fragment.expandRange( 'word' );
range = newFragment.getRange();
word = cases[i].phrase.substring( range.start, range.end );
assert.strictEqual( word, cases[i].expected, cases[i].msg + ': text' );
assert.strictEqual( cases[i].range.isBackwards(), range.isBackwards(), cases[i].msg + ': range direction' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
newFragment.destroy();
UnicodeJS library to implement Unicode standards Initially just with a Wordbreak module to implement Unicode standard on 'Default Word Boundaries'. Due to it's standaloneability this has been written as a separate library. Non-BMP characters are currently not supported. Bug: 44085 Change-Id: Ieafa070076f4c36855684f6bc179667e28af2c25
2013-03-18 11:31:14 +00:00
}
} );
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
QUnit.test( 'removeContent', 2, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
surface = new ve.dm.Surface( doc ),
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 1, 56 ) ),
expectedData = ve.copyArray( ve.dm.example.data.slice( 0, 1 ) )
.concat( ve.copyArray( ve.dm.example.data.slice( 4, 5 ) ) )
.concat( ve.copyArray( ve.dm.example.data.slice( 55 ) ) );
ve.setProp( expectedData[0], 'internal', 'changed', 'content', 1 );
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
fragment.removeContent();
assert.deepEqual(
doc.getData(),
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
expectedData,
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
'removing content drops fully covered nodes and strips partially covered ones'
);
assert.deepEqual(
fragment.getRange(),
new ve.Range( 1, 1 ),
'removing content results in a zero-length fragment'
);
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
} );
QUnit.test( 'insertContent', 3, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 1, 4 ) );
fragment.insertContent( ['1', '2', '3'] );
assert.deepEqual(
doc.getData( new ve.Range( 1, 4 ) ),
['1', '2', '3'],
'inserting content replaces selection with new content'
);
assert.deepEqual(
fragment.getRange(),
new ve.Range( 4, 4 ),
'inserting content results in a zero-length fragment'
);
fragment.insertContent( '321' );
assert.deepEqual(
doc.getData( new ve.Range( 4, 7 ) ),
['3', '2', '1'],
'strings get converted into data when inserting content'
);
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Added tests for removeContent and insertContent Also fixed the arguments given to insertContent and double-translating the range Change-Id: I7cb7dcfcee1c88f2052c63e31a0ed37eaaf645ab
2012-08-24 22:24:23 +00:00
} );
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
QUnit.test( 'wrapNodes/unwrapNodes', 10, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
originalDoc = ve.dm.example.createExampleDocument(),
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 55, 61 ) );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
// Make 2 paragraphs into 2 lists of 1 item each
fragment.wrapNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
assert.deepEqual(
doc.getData( new ve.Range( 55, 69 ) ),
[
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
{
'type': 'list',
'attributes': { 'style': 'bullet' },
'internal': { 'changed': { 'created': 1 } }
},
{ 'type': 'listItem', 'internal': { 'changed': { 'created': 1 } } },
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
{ 'type': 'paragraph' },
'l',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' },
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
{
'type': 'list',
'attributes': { 'style': 'bullet' },
'internal': { 'changed': { 'created': 1 } }
},
{ 'type': 'listItem', 'internal': { 'changed': { 'created': 1 } } },
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
{ 'type': 'paragraph' },
'm',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
],
'wrapping nodes can add multiple levels of wrapping to multiple elements'
);
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 55, 69 ), 'new range contains wrapping elements' );
fragment.unwrapNodes( 0, 2 );
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
assert.deepEqual( doc.getData(), originalDoc.getData(), 'unwrapping 2 levels restores document to original state' );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 55, 61 ), 'range after unwrapping is same as original range' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
// Make a 1 paragraph into 1 list with 1 item
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 9, 12 ) );
fragment.wrapNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
assert.deepEqual(
doc.getData( new ve.Range( 9, 16 ) ),
[
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
{
'type': 'list',
'attributes': { 'style': 'bullet' },
'internal': { 'changed': { 'created': 1 } }
},
{ 'type': 'listItem', 'internal': { 'changed': { 'created': 1 } } },
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
{ 'type': 'paragraph' },
'd',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
],
'wrapping nodes can add multiple levels of wrapping to a single element'
);
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 9, 16 ), 'new range contains wrapping elements' );
fragment.unwrapNodes( 0, 2 );
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
assert.deepEqual( doc.getData(), originalDoc.getData(), 'unwrapping 2 levels restores document to original state' );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 9, 12 ), 'range after unwrapping is same as original range' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 8, 34 ) );
fragment.unwrapNodes( 3, 1 );
assert.deepEqual( fragment.getData(), doc.getData( new ve.Range( 5, 29 ) ), 'unwrapping multiple outer nodes and an inner node' );
assert.deepEqual( fragment.getRange(), new ve.Range( 5, 29 ), 'new range contains inner elements' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
} );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
QUnit.test( 'rewrapNodes', 4, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
surface = new ve.dm.Surface( doc ),
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 43, 55 ) ),
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
expectedDoc = ve.dm.example.createExampleDocument(),
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
expectedSurface = new ve.dm.Surface( expectedDoc ),
expectedFragment = new ve.dm.SurfaceFragment( expectedSurface, new ve.Range( 43, 55 ) ),
created = { 'changed': { 'created': 1 } },
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
expectedData;
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
// set up wrapped nodes in example document
fragment.wrapNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
expectedFragment.wrapNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
// range is now 43, 59
// Compare a rewrap operation with its equivalent unwrap + wrap
// This type of test can only exist if the intermediate state is valid
fragment.rewrapNodes(
2,
[{ 'type': 'definitionList' }, { 'type': 'definitionListItem', 'attributes': { 'style': 'term' } }]
);
expectedFragment.unwrapNodes( 0, 2 );
expectedFragment.wrapNodes(
[{ 'type': 'definitionList' }, { 'type': 'definitionListItem', 'attributes': { 'style': 'term' } }]
);
assert.deepEqual(
doc.getData(),
expectedDoc.getData(),
'rewrapping multiple nodes via a valid intermediate state produces the same document as unwrapping then wrapping'
);
assert.deepEqual( fragment.getRange(), expectedFragment.getRange(), 'new range contains rewrapping elements' );
// Rewrap paragrphs as headings
// The intermediate stage (plain text attached to the document) would be invalid
// if performed as an unwrap and a wrap
expectedData = ve.copyArray( doc.getData() );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 59, 65 ) );
fragment.rewrapNodes( 1, [ { 'type': 'heading', 'attributes': { 'level': 1 } } ] );
expectedData.splice( 59, 1, { 'type': 'heading', 'attributes': { 'level': 1 }, 'internal': created } );
expectedData.splice( 61, 1, { 'type': '/heading' } );
expectedData.splice( 62, 1, { 'type': 'heading', 'attributes': { 'level': 1 }, 'internal': created } );
expectedData.splice( 64, 1, { 'type': '/heading' } );
assert.deepEqual( doc.getData(), expectedData, 'rewrapping paragraphs as headings' );
assert.deepEqual( fragment.getRange(), new ve.Range( 59, 65 ), 'new range contains rewrapping elements' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
} );
QUnit.test( 'wrapAllNodes', 10, function ( assert ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument(),
originalDoc = ve.dm.example.createExampleDocument(),
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 55, 61 ) ),
expectedData = ve.copyArray( doc.getData() );
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
// Make 2 paragraphs into 1 lists of 1 item with 2 paragraphs
fragment.wrapAllNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
assert.deepEqual(
doc.getData( new ve.Range( 55, 65 ) ),
[
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
{
'type': 'list',
'attributes': { 'style': 'bullet' },
'internal': { 'changed': { 'created': 1 } }
},
{ 'type': 'listItem', 'internal': { 'changed': { 'created': 1 } } },
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
{ 'type': 'paragraph' },
'l',
{ 'type': '/paragraph' },
{ 'type': 'paragraph' },
'm',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
],
'wrapping nodes can add multiple levels of wrapping to multiple elements'
);
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 55, 65 ), 'new range contains wrapping elements' );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment.unwrapNodes( 0, 2 );
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
assert.deepEqual( doc.getData(), originalDoc.getData(), 'unwrapping 2 levels restores document to original state' );
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 55, 61 ), 'range after unwrapping is same as original range' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
// Make a 1 paragraph into 1 list with 1 item
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 9, 12 ) );
fragment.wrapAllNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
assert.deepEqual(
doc.getData( new ve.Range( 9, 16 ) ),
[
Add change marking for Parsoid's benefit * Add map of change markers per offset to Transaction * Map is populated by TransactionProcessor * Markers are reversed on rollback * Removals aren't marked, Parsoid can detect these using DSR discontinuities Change-Id: I2290886ab411c6ad6162044ed85c091313613e51
2012-10-23 00:53:58 +00:00
{
'type': 'list',
'attributes': { 'style': 'bullet' },
'internal': { 'changed': { 'created': 1 } }
},
{ 'type': 'listItem', 'internal': { 'changed': { 'created': 1 } } },
ve.dm.SurfaceFragment: Implement wrapNodes and wrapAllNodes Change-Id: I378f0aad0286a6c90adeb4602a57d6617154e8b6
2012-08-24 22:25:37 +00:00
{ 'type': 'paragraph' },
'd',
{ 'type': '/paragraph' },
{ 'type': '/listItem' },
{ 'type': '/list' }
],
'wrapping nodes can add multiple levels of wrapping to a single element'
);
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 9, 16 ), 'new range contains wrapping elements' );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment.unwrapNodes( 0, 2 );
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
assert.deepEqual( doc.getData(), originalDoc.getData(), 'unwrapping 2 levels restores document to original state' );
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
assert.deepEqual( fragment.getRange(), new ve.Range( 9, 12 ), 'range after unwrapping is same as original range' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 5, 37 ) );
assert.throws( function() {
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment.unwrapNodes( 0, 20 );
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
}, /cannot unwrap by greater depth/, 'error thrown trying to unwrap more nodes that it is possible to contain' );
expectedData.splice( 5, 4 );
expectedData.splice( 29, 4 );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment.unwrapNodes( 0, 4 );
Implement SurfaceFragment.unwrapAllNodes and fix wrapAllNodes. wrapAllNodes was calulating the new selection incorrectly. This has been fixed and a test added. unwrapAllNodes takes a depth as its argument and unwraps that many elements from inside the selection. Tests for wrap/unwrap apply also now check that applying a wrap and then its inverse as an unwrap result in the document reverting to its original state. Change-Id: I7dcacdfb5894be59ffad69b369d7b32933a25b61
2013-02-22 20:49:13 +00:00
assert.deepEqual(
doc.getData(),
expectedData,
'unwrapping 4 levels (table, tableSection, tableRow and tableCell)'
);
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
} );
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
QUnit.test( 'rewrapAllNodes', 6, function ( assert ) {
var expectedData,
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
doc = ve.dm.example.createExampleDocument(),
originalDoc = ve.dm.example.createExampleDocument(),
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 5, 37 ) ),
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
expectedDoc = ve.dm.example.createExampleDocument(),
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
expectedSurface = new ve.dm.Surface( expectedDoc ),
expectedFragment = new ve.dm.SurfaceFragment( expectedSurface, new ve.Range( 5, 37 ) ),
created = { 'changed': { 'created' : 1 } };
// Compare a rewrap operation with its equivalent unwrap + wrap
// This type of test can only exist if the intermediate state is valid
fragment.rewrapAllNodes(
4,
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
expectedFragment.unwrapNodes( 0, 4 );
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
expectedFragment.wrapAllNodes(
[{ 'type': 'list', 'attributes': { 'style': 'bullet' } }, { 'type': 'listItem' }]
);
assert.deepEqual(
doc.getData(),
expectedDoc.getData(),
'rewrapping multiple nodes via a valid intermediate state produces the same document as unwrapping then wrapping'
);
assert.deepEqual( fragment.getRange(), expectedFragment.getRange(), 'new range contains rewrapping elements' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
expectedFragment.destroy();
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
// Reverse of first test
fragment.rewrapAllNodes(
2,
[
{ 'type': 'table', },
{ 'type': 'tableSection', 'attributes': { 'style': 'body' } },
{ 'type': 'tableRow' },
{ 'type': 'tableCell', 'attributes': { 'style': 'data' } }
]
);
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
expectedData = originalDoc.getData();
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
expectedData[5].internal = created;
expectedData[6].internal = created;
expectedData[7].internal = created;
expectedData[8].internal = created;
assert.deepEqual(
doc.getData(),
expectedData,
'rewrapping multiple nodes via a valid intermediate state produces the same document as unwrapping then wrapping'
);
assert.deepEqual( fragment.getRange(), new ve.Range( 5, 37 ), 'new range contains rewrapping elements' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
// Rewrap a heading as a paragraph
// The intermediate stage (plain text attached to the document) would be invalid
// if performed as an unwrap and a wrap
fragment = new ve.dm.SurfaceFragment( surface, new ve.Range( 0, 5 ) );
fragment.rewrapAllNodes( 1, [ { 'type': 'paragraph' } ] );
expectedData.splice( 0, 1, { 'type': 'paragraph', 'internal': created } );
expectedData.splice( 4, 1, { 'type': '/paragraph' } );
assert.deepEqual( doc.getData(), expectedData, 'rewrapping a heading as a paragraph' );
assert.deepEqual( fragment.getRange(), new ve.Range( 0, 5 ), 'new range contains rewrapping elements' );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
} );
Implement SurfaceFragment.rewrapAllNodes rewrapAllNodes is effectively the same as unwrap then wrap except it operates as one transaction as so avoids a potentially invalid intermediate state. Added some more comments for unwrapAllNodes and renamed a varaible for consistency. Fixed a typo in Transaction.newFromWrap comment. Bug: 45242 Change-Id: Ie752a788d087055d97c7c6f75f59c6a2680d26c7
2013-02-25 22:32:29 +00:00
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
function runIsolateTest( assert, type, range, expected, label ) {
Store data in LinearData class with an index-value store for objects Created an IndexValueStore class which can store any object and return an integer index to its hash map. Linear data is now stored in ve.dm.LinearData instances. Two subclasses for element and meta data contain methods specific to those data types (ElementLinearData and MetaLinearData). The static methods in ve.dm.Document that inspected data at a given offset are now instance methods of ve.dm.ElementLinearData. AnnotationSets (which are no longer OrderedHashSets) have been moved to /dm and also have to be instantiated with a pointer the store. Bug: 46320 Change-Id: I249a5d48726093d1cb3e36351893f4bff85f52e2
2013-03-20 22:35:05 +00:00
var doc = ve.dm.example.createExampleDocument( 'isolationData' ),
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
surface = new ve.dm.Surface( doc ),
fragment = new ve.dm.SurfaceFragment( surface, range ),
data;
data = ve.copyArray( doc.getFullData() );
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
fragment.isolateAndUnwrap( type );
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
expected( data );
assert.deepEqual( doc.getFullData(), data, label );
Death and/or destruction So. It turns out that the design of SurfaceFragment is a little - shall we say - wonky. One of the best things about ve.dm.SurfaceFragment is its magical ability to retain the intention of its range, even as transactions are being processed. This ability is granted by each fragment listening to the surface's change event, and responding by using translateRange for each transaction that gets processed. Surface fragments also have these clever methods that allow you to get a fragment based on another, which makes adjusting the range easy to do inline without having to manually store multiple fragments or modifying the original. This sounded good, and we seemed to all be convinced it was well designed. But if you add a console.log( 'hello' ); to the first line of ve.dm.SurfaceFragment.prototype.onTransact, and then start using the bold tool on various selections of text, you will find that there may indeed be a flaw. What you will probably realize is that the number of times that particular line of code is being called is disturbingly large, and increases each time you do just about anything in the editor. What's going on? How did we get here? Read on… It turns out that fragments are immortal. We create them, they listen to the surface's transact event, we are done with them, but the surface keeps on emitting events to the now long forgotten about fragments. They continue to build up over time, never go out of scope, and bloat the hell out of our program. The same ended up being true of toolbars - and each time the context menu fired up a new one the old one was left in limbo, still responding to events, still taking up memory, but not being visible to the user. All of this immortality was causing strange and difficult to track down problems. This patch fixes this by introducing a destroy method. This method unbinds events, allowing the object to finally fall out of scope and die - and more importantly stop receiving notifications of changes. This is a hack, but Ed will no doubt get this situation sorted out properly by making fragments lazy-evaluate their selections by only storing an identifier of the most recent transaction they were based on, see bug 47343. Change-Id: I18bb986001a44732a7871b9d79dc3015eedfb168
2013-04-18 18:44:40 +00:00
fragment.destroy();
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
}
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
QUnit.test( 'isolateAndUnwrap', 4, function ( assert ) {
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
var rebuilt = { 'changed': { 'rebuilt': 1 } },
createdAndRebuilt = { 'changed': { 'created': 1, 'rebuilt': 1 } };
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
runIsolateTest( assert, 'MWheading', new ve.Range( 12, 20 ), function( data ) {
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
data[0].internal = rebuilt;
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
data.splice( 11, 0, { 'type': '/list' } );
data.splice( 12, 1 );
data.splice( 20, 1, { 'type': 'list', 'attributes': { 'style': 'bullet' }, 'internal': createdAndRebuilt });
}, 'isolating paragraph in list item "Item 2" for MWheading');
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
runIsolateTest( assert, 'heading', new ve.Range( 12, 20 ), function( data ) {
data.splice( 11, 0, { 'type': 'listItem' } );
data.splice( 12, 1 );
data.splice( 20, 1, { 'type': '/listItem' });
}, 'isolating paragraph in list item "Item 2" for heading');
runIsolateTest( assert, 'MWheading', new ve.Range( 89, 97 ), function( data ) {
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
data[75].internal = rebuilt;
data[76].internal = rebuilt;
data[77].internal = rebuilt;
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
data.splice( 88, 1,
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
{ 'type': '/tableRow' },
{ 'type': '/tableSection' },
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
{ 'type': '/table' }
);
data.splice( 99, 1,
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
{ 'type': 'table', 'internal': createdAndRebuilt },
{ 'type': 'tableSection', 'attributes': { 'style': 'body' }, 'internal': createdAndRebuilt },
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
{ 'type': 'tableRow', 'internal': createdAndRebuilt }
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
);
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
}, 'isolating "Cell 2" for MWheading');
runIsolateTest( assert, 'MWheading', new ve.Range( 202, 212 ), function( data ) {
data[186].internal = rebuilt;
data[187].internal = rebuilt;
data[188].internal = rebuilt;
data.splice( 201, 1,
{ 'type': '/list' }, { 'type': '/listItem' }, { 'type': '/list' }
);
data.splice( 214, 1,
{ 'type': 'list', 'attributes': { 'style': 'bullet' }, 'internal': createdAndRebuilt },
{ 'type': 'listItem', 'internal': createdAndRebuilt },
{ 'type': 'list', 'attributes': { 'style': 'number' }, 'internal': createdAndRebuilt }
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
);
Refactor convert to use isolateAndUnwrap isolateAndUnwrap now unwraps to a level determined by a target type i.e. the type you are going to convert to. Also in this commit wrap/unwrap/rewrap have been refactored to use getLengthDifference. unwrap now takes an inner/outer unwrap depth. Change-Id: I3c6249de43232a9ef64f498a0aaf66b1c44973f2
2013-03-01 01:20:59 +00:00
}, 'isolating paragraph in list item "Nested 2" for MWheading');
(bug 45423) Create SurfaceFragment.isolate method This method will take a selection of siblings and ensure they are the only chlidren in their first parent which can be placed anywhere (for example the first parent of a tableCell which can be placed anywhere is a table, and for a listItem is a list). The method ensures no redundant empty tags are created, so if the selection encompasses all siblings then no action is taken. Also in this commit are two test cases run against ve.dm.example.isolationData. Change-Id: I783bd5ecd9d43d61f9b2685985409b4d746cbe94
2013-02-21 19:20:43 +00:00
} );
Reference in a new issue Copy permalink