Commit graph

12 commits

Author SHA1 Message Date
Roan Kattouw 7c8b0ef10b Hack around Parsoid's href prefixing in rendering new links
If we render new links with a plain target, then if you're on a
subpage like Foo/Bar, [[Baz]] will point to Foo/Baz. In order to
avoid this, we fake the link target to be ../Baz and resolve that,
which produces the correct result.

This hack is only needed until Parsoid stops producing ../-prefixed
links. This hack is only applied in view mode, because applying
it to our DOM output back to Parsoid would confuse Parsoid and
cause bugs.

Bug: 58314
Change-Id: Ifb4b63a26235a04e6362fc3e3e57d8773831eb38
2014-03-24 11:24:22 -07:00
Roan Kattouw 78a52f1f80 Display links to nonexistent pages as red
* Add ve.init.mw.LinkCache to track page existence and
  transparently query it
* Populate it with initial data from the parser cache
  if available, obtained in the VE API module
* Use linkCache data in link annotation rendering

This doesn't yet integrate the LinkCache with other
components like the link inspector. That should be
done so we can deduplicate the existence checks.

Additionally, we should generalize LinkCache and use
it for the category existence/status checks as well.

Bug: 37901
Change-Id: I9fd43e8c3864dd375cf6dadfdeedd05e4fe9cf3b
2014-03-20 02:42:33 +00:00
James D. Forrester 0ffd654bed Bump copyright like it's 2014
Change-Id: Ic469ebda2c061dc7da0b4c1625f43a7be55da4fa
2014-01-05 20:06:50 +08:00
Trevor Parscal db9f941fa6 Rename this.$ to this.$element, and this.$$ to this.$
Objectives:
* Rename this.$ to this.$element
* Rename this.$$ to this.$
* Get rid of the need to use this.frame.$$
* Rename OO.ui.Element.get$$ to OO.ui.Element.getJQuery

Changes: (using Sublime Text regex patterns)
* Replace "get$$" with "getJQuery"
* Replace "\.(\$)([^\$a-zA-Z])" with ".$element$2"
* Replace "\.(\$\$)" with ".$"
* Replace "'$$'" with "'$'"
* Set this.$ to null in constructor of OO.ui.Window
* Set this.$ to this.frame.$ in initialize method of OO.ui.Window
* Replace "\.(frame.\$)([^\$a-zA-Z])" with ".\$$2"

Bonus:
* Use this.$() in a bunch of places where $() was erroneously used

Change-Id: If3d870124ab8d10f8223532cda95c2b2b075db94
2013-11-03 23:03:49 -08:00
Roan Kattouw 5c04118c07 Get rid of dmRendering hack in ve.ce.MWInternalLinkAnnotation
Centralize href computation in getHref(). Because getHref() is provided
by the generic LinkAnnotation class, the subclass implementation is
now simpler.

Bug: 51487
Change-Id: Ia6ca85bc84b4f4453b572285836adb631e8d0683
2013-10-28 15:49:08 +00:00
Roan Kattouw 36061c7f5d Render resolved URLs for href and src attributes in CE
URLs are resolved according to the <base> URL from the Parsoid DOM.
For instance, a link can have its href set to '../Foo' in the DM, and
the target will show up as '../Foo' in the link inspector, but the CE
rendering will be <a href="http://localhost/Foo"> (assuming Parsoid sent
<base href="http://localhost/wiki/Bar">).

Bug: 48915
Change-Id: I919135eb758c82361525078f276ca193dc4c4820
2013-10-28 15:49:04 +00:00
Roan Kattouw 8e6bde2f56 Give ce.Annotations a reference to their ce.ContentBranchNode
This gives them a way to reach the dm.Document, which is needed
for ce.Annotations to do URL resolution.

Change-Id: Ia18bd8fc3510ad1b627644cd2c6ebcf148254e05
2013-10-28 15:48:59 +00:00
Roan Kattouw 74b8807df5 Resolve rendered URLs according to the provided <base>
This is done by using the computed property value rather than the
literal attribute value when rendering href and src attributes.
Helpfully, this provides perfect URL resolution natively in the browser,
which means the document's <base> is respected and all that good stuff.

For GeneratedContentNodes, we also need to find all DOM elements inside
the rendered DOM that have href or src attributes and resolve those.
This is done in the new getRenderedDomElements() function, which the
existing cleanup steps (remove <link>/<meta>/<style>, clone for
correct document) were moved into.

In order to make sure that the computed values are always computed
correctly, we need to make sure that in cases where HTML strings
in data-mw are parsed, they're parsed in the context of the correct
document so the correct <base> is applied.

We still need to solve this problem for models that actually store and
edit an href or src as an attribute. I'll post more about that on
bug 48915.

Bug: 48915
Change-Id: Iaccb9e3fc05cd151a0f5e632c8d3bd3568735309
2013-10-28 15:16:05 +00:00
Trevor Parscal efafed3231 Remove ve.{inheritClass,mixinClass} and use OO instead
Change-Id: I8df9226a358a76b661eab6e967ff0d63d361f691
2013-10-18 18:58:08 +02:00
Ed Sanders e6f48c5c93 'Config' -> 'Configuration' in all comments
Because the former isn't a real word.

Change-Id: Ie6ed15f9e390b357bbaa768b57f3c3fd7cf21181
2013-09-25 11:23:16 +01:00
Roan Kattouw 7294c65a2e Add a node class for mw:Nowiki
These represent <nowiki> tags. If the user doesn't edit the text inside
the nowiki, we round-trip the <span typeof="mw:Nowiki"> wrapper cleanly,
but if they do edit it, we unwrap it. This then triggers re-escaping
in Parsoid, and prevents cases where the user edits the text to no
longer need escaping but Parsoid still wraps it in <nowiki> because
of the <span typeof="mw:Nowiki"> wrapper.

In order to detect whether the contents have changed, the nowiki
annotation stores a copy of its contents. To avoid infinite recursion,
we have to exclude this attribute for hash generation.

Bug: 47678
Change-Id: I2edc46b6d87d2f91e952efcb09c0edae5166958f
2013-07-16 19:35:24 -07:00
Roan Kattouw 92c38eab85 The great directory split of 2013
Move all MW-specific files into the ve-mw directory, in preparation
for moving them out into a separate repo.

All MW-specific files were moved into a parallel directory structure
in modules/ve-mw . Files with both generic and MW-specific things were
split up. Files in ve/init/mw/ were moved to ve-mw/init/ rather than
ve-mw/init/mw ; they're still named ve.init.mw.* but we should change
that. Some of the test files for core classes had MW-specific test cases,
so those were split up and the test runner was duplicated; we should
refactor our tests to use data providers so we can add cases more easily.

Split files:
* ve.ce.Node.css
* ve.ce.ContentBranchNode.test.js (MWEntityNode)
* ve.ce.Document.test.js (some core test cases genericized)
* ve.dm.InternalList.test.js (uses mwReference test document)
* ve.dm.SurfaceFragment.test.js, ve.ui.FormatAction.test.js
** Made core tests use heading instead of mwHeading
** Updated core tests because normal headings don't break out of lists
** Moved test runners into ve.test.utils.js
* ve.ui.Icons-*.css
* ve.ui.Dialog.css (MW parts into ve.ui.MWDialog.css)
* ve.ui.Tool.css
* ve.ui.Widget.css (move ve-ui-rtl and ve-ui-ltr to ve.ui.css)

ve.dm.Converter.test.js: Moved runner functions into ve.test.utils.js

ve.dm.example.js:
* Refactored createExampleDocument so mwExample can use it
* Removed wgExtensionAssetsPath detection, moved into mw-preload.js
* Genericized withMeta example document (original version copied to mwExample)
* Moved references example document to mwExample

ve.dm.mwExample.js:
* Move withMeta and references example documents from ve.dm.example.js
* Add createExampleDocument function

ve-mw/test/index.php: Runner for MW-specific tests only

ve-mw/test/mw-preload.js: Sets VE_TESTDIR for Special:JavaScriptTest only

ve.ui.Window.js:
* Remove magic path interpolation in addLocalStyleSheets()
* Pass full(er) paths to addLocalStyleSheets(), here and in subclasses

ve.ui.MWDialog.js: Subclass of Dialog that adds MW versions of stylesheets

ve.ui.MW*Dialog.js:
* Subclass MWDialog rather than Dialog
* Load both core and MW versions of stylesheets that have both

ve.ui.PagedDialog.js: Converted to a mixin rather than an abstract base class
* Don't inherit ve.ui.Dialog
* Rather than overriding initialize(), provide initializePages() which the
  host class is supposed to call from its initialize()
* Rename onOutlineSelect to onPageOutlineSelect

ve.ui.MWMetaDialog.js, ve.ui.MWTransclusionDialog.js:
* Use PagedDialog as a mixin rather than a base class, inherit MWDialog

bullet-icon.png: Unused, deleted

Stuff we should do later:
* Refactor tests to use data providers
* Write utility function for SVG compat check
* Separate omnibus CSS files such as ve.ui.Widget.css
* Separate omnibus RL modules
* Use icon classes in ViewPageTarget

Change-Id: I1b28f8ba7f2d2513e5c634927a854686fb9dd5a5
2013-07-02 20:51:38 -07:00