Commit graph

14 commits

Author SHA1 Message Date
Catrope 613dd14332 New annotation API: convert existing annotations
This changes ve.dm.LinkAnnotation to be a generic annotation for <a>
tags, and adds ve.dm.MWInternalLinkAnnotation and
ve.dm.MWExternalLinkAnnotation as MW-specific subclasses. This nicely
splits out the MW-specific parts in LinkAnnotation, and ideally we'd
also move these files somewhere else to reflect their MW-specificity,
but I haven't gotten to that yet.

Similarly, ve.dm.TextStyleAnnotation is now a generic base class for
simple tag-only-no-metadata annotations, and it has 11 subclasses, one
for each tag we support. This is quite a bit more verbose than the
previous code, but I think it's cleaner and more flexible. I considered
writing a function that would generate a TextStyleAnnotation subclass,
then calling that 11 times, but that's not possible if we want to keep
named functions for the constructors.

Change-Id: Ifba10153eef40280e44025dd72d4e9d9f33b0632
2012-10-12 15:07:25 -07:00
Catrope 7fe7182f43 New annotation API: Annotation and AnnotationFactory classes
Fleshes out ve.dm.Annotation to a class. Annotations in the linear model
will be instances of a subclass of ve.dm.Annotation. Annotations are
defined by subclassing ve.dm.Annotation and registering this subclass
with ve.dm.AnnotationFactory.

ve.dm.AnnotationFactory keeps track of which annotation classes are known,
and has code to match an HTML element to an annotation class, for use in
the converter.

Change-Id: I68802bdb8736ced1f9e04ee49c623944b448141c
2012-10-12 15:07:02 -07:00
Inez Korczyński 15e0c13fa9 Create method ve.Range.isCollapsed() and added some tests for ve.Range class.
Change-Id: I866b00db196a768460b32766b82fbdf896a48fdd
2012-09-28 13:32:26 -07:00
Catrope 7b96fbe3d2 Add a node type for meta nodes
This node type represents <meta> or <link> (transparently, based on the
style attribute). I had to make two node types for this and hack the
toData conversion code directly into ve.dm.Converter, because we don't
have native support for node types that can be both inline and block.
(We should add this in the node API rewrite.)

The CE implementation renders a placeholder (with the same styles as an
alien node) right now. I'm not sure how nice that is, but it's better
than rendering raw <meta>/<link> tags.

This whole thing is a total pile of hacks to make VE deal with
<meta>/<link> tags until we have a proper node types API.

Change-Id: Id6783fcfc35a896db088ff424ff9faaabcaff716
2012-09-10 15:35:30 -07:00
Catrope 5e7c14c868 Manage annotations in ve.AnnotationSet object
Introduced the ve.AnnotationSet class to manage sets of annotations. This
is a generalization of ve.OrderedHashSet, a class that manages a set
using an array and an object keyed by hash.

Converted everything that stores, tracks or passes around annotations to
use ve.AnnotationSet. In particular, this means the linear model now
contains AnnotationSets instead of hash-keyed objects.

This allows us to maintain the order of annotations in the linear model,
and will help fix bugs with annotation ordering and splitting.

Change-Id: I50975b0a95f4cc33017a0b59fdede9ed1eff0124
2012-09-06 14:39:38 -07:00
Timo Tijhof c8ed44fb07 Refactor ve.getHash: Stabilize cross-browser differences; + unit tests
* Replaces c8b4a28936

* Use Object() casting to detect objects instead of .constructor
  (or instanceof). Both .constructor and instanceof compare by reference
  the type "Object" which means if the object comes from another window
  (where there is a different "Object" and "Object.prototype") it will
  drop out of the system and go freewack.

  Theory: If a variable casted to an object returns true when strictly compared
  to the original, the input must be an object.

  Which is true. It doesn't change the inheritance, it doesn't make it inherit
  from this window's Object if the object is from another window's object. All it
  does is cast to an object if not an object already.
  So e.g. "Object(5) !== 5" because 5 is a primitive value as opposed to an instance
  of Number.
  And contrary to "typeof", it doesn't return true for "null".

* .constructor also has the problem that it only works this way if the
  input is a plain object. e.g. a simple construtor function that creates
  an object also get in the wrong side of the if/else case since it is
  an instance of Object, but not directly (rather indirectly via another
  constructor).

* Added unit tests for basic getHash usage, as well as regression tests
  against the above two mentioned problems (these tests fail before this commit).

* While at it, also improved other utilities a bit.
 - Use hasOwnProperty instead of casting to boolean
   when checking for presence of native support.
   Thanks to Douglas Crockford for that tip.
 - Fix documentation for ve.getHash: Parameter is not named "obj".
 - Add Object-check to ve.getObjectKeys per ES5 Object.keys spec (to match native behavior)
 - Add Object-check to ve.getObjectValues to match ve.getObjectKeys
 - Improved performance of ve.getObjectKeys shim. Tried several potential optimizations
   and compared with jsperf. Using a "static" reference to hasOwn improves performance
   (by not having to look it up 4 scopes up and 3 property levels deep).
   Also using [.length] instead of .push() shared off a few ms.
 - Added unit tests for ve.getObjectValues

Change-Id: If24d09405321f201c67f7df75d332bb1171c8a36
2012-08-27 00:14:02 +02:00
Trevor Parscal 1e2502a726 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 10:48:40 -07:00
Trevor Parscal 5752b3fb72 Merge "Add ve.dm.BreakNode to represent <br>" 2012-08-09 21:50:41 +00:00
Catrope 625161e35c Add ve.dm.BreakNode to represent <br>
Change-Id: I3825199c3c8cbe3b50c01e03f39f20cef7c55a28
2012-08-09 14:50:25 -07:00
Trevor Parscal d8ee3c2c29 After much research on error objects, native = good, custom = bad
Stack traces, line numbers, etc. All the approaches I've seen are bad hacks. This is the best way to go.

Change-Id: Ib12e9d2ecfe610bcc89d046005e35cc13efa3d99
2012-08-08 10:48:53 -07:00
Trevor Parscal b4de3ead08 Throw ve.Error instead of string literals
Throwing strings is bad because it doesn't include a lot of important
information that an error object does, such as a stack trace or where
the error was actually thrown from.

ve.Error inherits directly from Error. In the future we may create
more specific subclasses and/or do custom stuff.

Some interesting reading on the subject:
* http://www.devthought.com/2011/12/22/a-string-is-not-an-error/

Change-Id: Ib7c568a1dcb98abac44c6c146e84dde5315b2826
2012-08-08 06:19:00 +02:00
Timo Tijhof b5a12d0167 Register QUnit tests suites in MediaWiki to run from Special:JavaScriptTest
* Also update test/index.html with latest minimalistic format
* Update test suite hardcoded paths to match the definition in
  VisualEditor.php for ResourceLoader
* Issues:
 - 'jquery/jquery.json.js' should not be loaded directly,
   using a dependency instead.
 - Load scripts from the <head> in test/index.html so that
   code that depends on document being ready is catches instead of
   silently being ignored.

Change-Id: I5ad7390137f4d17c153a1bf69f19c4869c08e323
2012-07-27 17:14:23 -07:00
Catrope 1a573480f7 Moved text node test to the correct directory
Change-Id: I6c2146cd051e9e992e6a30a2d5f83d337d454387
2012-07-25 14:49:48 -07:00
Trevor Parscal 76bac7d152 Move test files
Change-Id: Id0a0bd5b4a91f702cad34e9f5e7f2121763abffd
2012-07-25 14:35:49 -07:00