Commit graph

24 commits

Author SHA1 Message Date
Inez Korczyński 1e85621bd9 Reduction of renderContents calls
There is no need to call renderContents in ContentBranchNode constructor
because it is going to be called anyways in onSplice

Change-Id: Id1ab983668299658ecd6e89a37667cc34c701689
2013-05-10 00:28:30 +00:00
Catrope 3d21609ca9 Move completeHistory from dm.Surface to dm.Document
Per IRL conversation with Trevor, that's where it belongs.

Change-Id: I9eae05380597ed83122f29864b77d2278d3dd863
2013-05-09 14:54:25 -07:00
Trevor Parscal 7233ea8f1b EventEmitter API cleanup
The EventEmitter API we inherited from Node.js and then bastardized was
getting awkward and cumbersome. The number of uses of ve.bind was getting
out of control, and removing events meant caching the bound method in a
property. Many of the "features" of EventEmitter wasn't even being used,
some causing overhead, others just causing bloat. This change cleans up
how EventEmitter is used throughout the codebase.

The new event emitter API includes:
* emit - identical to the previous API, no longer throws an error if you
  emit error without a handler
* once - identical to the previous API, still introduces a wrapper* on -
  compatible with the previous API but has some new features
* off - identical to removeListener in the previous API
* connect - very similar to addListenerMethods but doesn't wrap callbacks
  in closures anymore
* disconnect - new, basically the opposite of addListenerMethods

Another change that is made in this commit is mixing in rather than
inheriting from EventEmitter.

Finally, there are changes throughout the codebase anywhere
connect/disconnect could be used.

Change-Id: Ic3085d39172a8a719ce7f036690f673e59848d3a
2013-05-02 15:05:59 -07:00
Roan Kattouw 72e06d9cbf Deduplicate childUpdate events based on transaction and appliedness
Previously, they were only being deduplicated based on the transaction,
which meant that an undo was seen as a duplicate (but then if you undid
again, that wasn't a duplicate).

Change-Id: If432ea28e6c206a2ad5562e529e2d3ed808c20e4
2013-04-25 17:08:30 -07:00
Inez Korczyński 93357b8f34 Performance improvement for getRenderedContents
Instead of calling $.append for every single char - buffer and call $.append only when really needed.

Change-Id: I53acfa795ea5dc6a8ca39ce11017daa85c9151d2
2013-04-25 14:15:01 -07:00
Inez Korczyński f21a385bd9 Refactor renderContents() deduplication code
Change-Id: Ib8672b51fc236cac805b88a99d07b3c496548cbd
2013-04-23 16:10:18 -07:00
Ed Sanders 6ad61d4ddb Add data model support for MediaWiki references
So far just read-only.

Bug: 39599
Change-Id: I6daff5c5969e5fdc871f8f346cf790b4302ae080
2013-04-23 10:17:42 +01:00
Inez Korczyński a13713e3a4 Fix bug in ContentBranchNode that caused renderContents to be called not enough
Change-Id: Idff61d405404eccb43c0f36cbfc7eba5af30bad9
2013-04-18 16:11:59 -07:00
jenkins-bot d28c5548d5 Merge "Make the AnnotationSet constructor take an array of indexes" 2013-04-18 21:50:25 +00:00
Inez Korczyński d809dc7e37 Added inline comment explaining not obvious purpose of code
Change-Id: Ib9ea1307ebe58c03abd00dcf8b96681d6901a3d4
2013-04-18 13:39:56 -07:00
Catrope eac44c39f4 Make the AnnotationSet constructor take an array of indexes
Before, it took an array of objects and translated those to indexes
using the store. Literally every caller outside of the test suite got
an array of indexes from the linear model, translated those to objects,
then passed them into the AnnotationSet constructor which translated
them right back to indexes.

The previous behavior was kind of ridiculous on its face, but the
reason we found it is because Inez was investigating the performance
degradation when bolding a line and found that half of it was due
to the hundreds of ve.getHash() calls caused by this behavior.

Change-Id: I38df8ae9f6392849dacf477ea2f804283c964417
2013-04-18 10:56:03 -07:00
Inez Korczyński e786c5c2f0 Avoid rendering content of ve.ce.ContentBranchNode multiple times when only one transaction is applied
Change-Id: I940bb96b670afb7ab3de524919b56912d027a2ef
2013-04-17 12:16:04 -07:00
Catrope 27875c8220 Reduce code duplication for annotation rendering
ve.dm.Converter and ve.ce.ContentBranchNode were duplicating a fair bit
of logic for annotation rendering. Moved the annotation opening and
closing logic into ve.dm.Converter.openAndCloseAnnotations, and
implemented both annotation rendering code paths in terms of that
function with callbacks for caller-specific behavior.

Change-Id: I7cba7d2fda7002287b07949a1b8120ba80bfe854
2013-04-09 23:38:03 +00:00
Catrope 2eb0d2a6b2 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-08 18:10:16 -07:00
Ed Sanders fdf30b1ac8 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-30 10:06:34 +00:00
Ed Sanders edcaaf9edc Use static.name once for ce and dm nodes
Add a static.name property to ce nodes and make sure both ce
and dm nodes always use the static.name property in constructors
and registration calls.

The result of this is that any given node type should now only
appear once in the code as a string.

Bug: 45701
Change-Id: Ibf31de16ab28ad58209c1443cd74f93dda278998
2013-03-07 17:19:39 -08:00
James D. Forrester 82114467f1 Bump copyright notice year range to -2013 over -2012
199 files touched. Whee!

Change-Id: Id82ce4a32f833406db4a1cc585674f2bdb39ba0d
2013-02-19 15:37:34 -08:00
Trevor Parscal bf5ba1ea2b Fixed documentation errors
Many of these problems were introduced in I859b5871a9d2f17d970c002067c8ff24f3513e9f

Change-Id: Ifc2dc4934f782c4ce5107e3a356e357aef754083
2013-01-22 23:38:01 +00:00
Trevor Parscal 8d33a3de0d 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-16 15:37:59 -08:00
Timo Tijhof b11bbed7a6 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-05 01:16:32 +01:00
Inez Korczyński 34a7ff381d Rename and cleanup ve.ce.Surface locking state
Get rid of ve.ce.Surface.locked (and isLocked, lock, unlock) and instead introduce ve.ce.Surface.renderingEnabled (and isRenderingEnabled, enableRendering, disableRendering) which names are way less confusing and more specific. Also add use of isRenderingEnabled to ve.ce.ContentBranchNode.

Change-Id: I72e9e8f8dfbf43784d7e616369acc3e9649c715a
2012-12-05 15:19:56 -08:00
Catrope 6d5d23d93d (bug 42707) JS error when deleting across an inline alien
ContentBranchNode shouldn't rerender on update, only on childUpdate.
When deleting across an inline node, update was emitted after the splice
had occurred in the DM but before the spice event was emitted that
caused the splice to happen in CE, leading to detached nodes and
associated sadness. See the bug for more details.

Change-Id: I2d44231b6e27efdb3f12967556cff174d9364d25
2012-12-05 11:19:18 -08:00
Trevor Parscal 23bd31a855 (bug 42555) Fixed onUpdate over-writing in ve.ce.HeadingNode
When the content rendering stuff was moved to ve.ce.ContentBranchNode the onUpdate methods being used to update the DOM wrapper in ve.ce.HeadingNode was overlooked, so heading were not rendered on update anymore.

Change-Id: I994b8c43123c3cd02b9a550d5d7eac7d5052418e
2012-11-30 11:39:46 -08:00
Catrope e148234c29 Render inline annotations in CE
Moved annotation rendering from ce.Textnode into the new
ce.ContentBranchNode class. This allows us to render annotations that
span across multiple nodes.

* Add ce.ContentBranchNode, inheriting ce.BranchNode
* Make ce.{Paragraph,Heading,Preformatted}Node inherit ce.ContentBranchNode
* Made ce.ContentBranchNode render its child nodes with anntations,
  using .getAnnotatedHtml() on the child nodes
* Put a default implementation for .getAnnotatedHtml() in ce.LeafNode
* Override this in ce.TextNode to do escaping and whitespace handling
* Removed rendering code from ce.TextNode (this.$ is now unused there)
* Removed ce.TextNode.onUpdate() and ce.BranchNode.clean(), now unneeded
* Have ce.BranchNode propagate update events from children, so
  ce.ContentBranchNode can rerender when its children change
* Update tests, add test case for escaping of &<>'"

Change-Id: I4600e984b287c6ff9267f4281d2f09bab9e1ad95
2012-11-28 11:21:59 -08:00