mediawiki-extensions-Visual.../modules/ve/dm/ve.dm.Annotation.js

176 lines
5.6 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
/*!
* VisualEditor DataModel Annotation class.
*
* @copyright 2011-2013 VisualEditor Team and others; see AUTHORS.txt
* @license The MIT License (MIT); see LICENSE.txt
*/
/**
* Generic DataModel annotation.
*
* This is an abstract class, annotations should extend this and call this constructor from their
* constructor. You should not instantiate this class directly.
*
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
* Annotations in the linear model are instances of subclasses of this class. Subclasses should
* only override static properties and functions.
*
* @class
* @extends {ve.dm.Model}
* @constructor
* @param {Object} element Linear model annotation
*/
ve.dm.Annotation = function VeDmAnnotation( element ) {
// Parent constructor
ve.dm.Model.call( this, element );
// Properties
this.name = this.constructor.static.name; // For ease of filtering
};
/* Inheritance */
OO.inheritClass( ve.dm.Annotation, ve.dm.Model );
/* Static properties */
/**
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
* About grouping is not supported for annotations; setting this to true has no effect.
*
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
* @static
* @property {boolean} static.enableAboutGrouping
* @inheritable
*/
ve.dm.Annotation.static.enableAboutGrouping = false;
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
/**
* Automatically apply annotation to content inserted after it.
*
* @type {boolean}
*/
ve.dm.Annotation.static.applyToAppendedContent = true;
/**
* Abandon continuation when a wordbreak is generated
*
* @type {boolean}
*/
ve.dm.Annotation.static.splitOnWordbreak = false;
/**
* Static function to convert a linear model data element for this annotation type back to
* a DOM element.
*
* As special facilities for annotations, the annotated content that the returned element will
* wrap around is passed in as childDomElements, and this function may return an empty array to
* indicate that the annotation should produce no output. In that case, the child DOM elements will
* not be wrapped in anything and will be inserted directly into this annotation's parent.
*
* @static
* @inheritable
* @method
* @param {Object|Array} dataElement Linear model element or array of linear model data
* @param {HTMLDocument} doc HTML document for creating elements
* @param {ve.dm.Converter} converter Converter object to optionally call .getDomSubtreeFromData() on
* @param {HTMLElement[]} childDomElements Children that will be appended to the returned element
* @returns {HTMLElement[]} Array of DOM elements; only the first element is used; may be empty
*/
ve.dm.Annotation.static.toDomElements = function ( /*dataElement, doc, converter, childDomElements*/ ) {
throw new Error( 've.dm.Annotation subclass must implement toDomElements' );
};
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
/* Methods */
/**
* Convenience wrapper for .toDomElements() on the current annotation
* @method
* @param {HTMLDocument} [doc] HTML document to use to create elements
* @see ve.dm.Model#toDomElements
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
*/
ve.dm.Annotation.prototype.getDomElements = function ( doc ) {
return this.constructor.static.toDomElements( this.element, doc || document );
Great Annotation Refactor of 2013 This changes the annotation API to be the same as the node API, sans a few boolean flags that don't apply. The APIs were different, but there was really no good reason why, so this makes things simpler for API users. It also means we'll be able to factor a bunch of things out because they're now duplicated between nodes, meta items and annotations. Linear model annotations are now objects with 'type' and 'attributes' properties (rather than 'name' and 'data'), for consistency with elements. They now also contain html/0/* attributes for HTML attribute preservation, which obsoletes the htmlTagName and htmlAttributes properties. dm.Annotation subclasses take a reference to such an object and implement conversion using .static.toDataElement and .static.toDomElements just like nodes do. The custom .getHash() functions are no longer necessary because of the way HTML attribute preservation was reimplemented. CE rendering has been moved out of dm.Annotation (it never made sense to have CE rendering functions in DM classes, this was bothering me) and into separate ce.Annotation subclasses. These are very similar to CE nodes in that they have a this.$ generated based on something in the DM; the main difference is that nodes listen to events and update themselves, whereas annotations are static and are simply destroyed and rebuilt when they change. This change also adds whitelisted HTML attribute rendering for annotations, as well as class="ve-ce-FooAnnotation" attributes. Now that annotation classes produce real DOM nodes rather than weird objects describing HTML tags, we can't generate HTML as a string in ce.ContentBranchNode anymore. getRenderedContents() has been rewritten to be much more similar to the way the converter renders annotations; in fact, significant parts of it were copied from the converter, so that should be factored out in the future. This change actually fixes an annotation rendering discrepancy between ce.ContentBranchNode and dm.Converter; see the diff of ve.ce.ContentBranchNode.test.js. ve.ce.MWEntityNode.js: * Remove stray property ve.dm.MWExternalLinkAnnotation.js: * Store 'rel' attribute ve.dm.TextStyleAnnotation.js: * Put all the conversion logic in the abstract base class ve.dm.Converter.js: * Also feed annotations through getDomElementsFromDataElement() and createDataElement() ve.dm.Node.js: * Fix undocumented property ve.ce.ContentBranchNode.test.js: * Add descriptive messages for each test case * Compare DOM trees, not HTML strings * Compare without all the class="ve-ce-WhateverAnnotation" clutter ve.ui.LinkInspector.js: * Replace direct .getHash() calls (evil!) with ve.getHash() Bug: 46464 Bug: 44808 Change-Id: I31991488579b8cce6d98ed8b29b486ba5ec38cdc
2013-04-02 17:23:33 +00:00
};
/**
* Get an object containing comparable annotation properties.
*
* This is used by the converter to merge adjacent annotations.
*
* @returns {Object} An object containing a subset of the annotation's properties
*/
ve.dm.Annotation.prototype.getComparableObject = function () {
var hashObject = this.getHashObject();
delete hashObject.htmlAttributes;
return hashObject;
};
/**
* HACK: This method strips data-parsoid from HTML attributes for comparisons.
*
* This should be removed once similar annotation merging is handled correctly
* by Parsoid.
*
* @returns {Object} An object all HTML attributes except data-parsoid
*/
ve.dm.Annotation.prototype.getComparableHtmlAttributes = function () {
var comparableAttributes, attributes = this.getHtmlAttributes();
if ( attributes[0] ) {
comparableAttributes = ve.copy( attributes[0].values );
delete comparableAttributes['data-parsoid'];
return comparableAttributes;
} else {
return {};
}
};
/**
* HACK: This method adds in HTML attributes so comparable objects aren't serialized
* together if they have different HTML attributes.
*
* This method needs to be different from getComparableObject which is
* still used for editing annotations.
*
* @returns {Object} An object containing a subset of the annotation's properties and HTML attributes
*/
ve.dm.Annotation.prototype.getComparableObjectForSerialization = function () {
var object = this.getComparableObject(),
htmlAttributes = this.getComparableHtmlAttributes();
if ( !ve.isEmptyObject( htmlAttributes ) ) {
object.htmlAttributes = htmlAttributes;
}
return object;
};
/**
* HACK: Check if the annotation was generated by the converter
*
* Used by compareToForSerialization to avoid merging generated annotations.
*
* @returns {boolean} The annotation was generated
*/
ve.dm.Annotation.prototype.isGenerated = function () {
var attributes = this.getHtmlAttributes();
return attributes[0] && attributes[0].values && attributes[0].values['data-parsoid'];
};
/**
* HACK: Compare to another annotation for serialization
*
* Compares two annotations using getComparableObjectForSerialization, unless
* they are both generated annotations, in which case they must be identical.
*
* @param {ve.dm.Annotation} annotation Annotation to compare to
* @returns {boolean} The other annotation is similar to this one
*/
ve.dm.Annotation.prototype.compareToForSerialization = function ( annotation ) {
// If both annotations were generated
if ( this.isGenerated() && annotation.isGenerated() ) {
return ve.compare( this.getHashObject(), annotation.getHashObject() );
}
return ve.compare(
this.getComparableObjectForSerialization(),
annotation.getComparableObjectForSerialization()
);
};