Commit graph

8 commits

Author SHA1 Message Date
Ed Sanders 4f768f3734 Integrate with BetaPreferences
Look at logo Michael.

Bug: 52686
Change-Id: I3cfada2ea264184698de5f322c1fe5041b37b8c8
2013-09-10 10:20:14 -07:00
Timo Tijhof bdd1a73eaa data: Rename MessagesModule to DataModule
Also..
* removed an incorrrect comment referring to the old module
  name (standalone didn't use the VisualEditorMessagesModule).
* made it use debug mode to determine whether to minify or
  prettify the js code.

Change-Id: I493007649fba27e7faab0cf743eded5f68714c50
2013-08-29 18:07:35 -07:00
Roan Kattouw ceb81353fc mw.Target: Removed unreachable badtoken recovery code
This code caught badtoken errors on load, but we can't get those
any more since the API module was split and we no longer send a token
on load. badtoken handling on save is done in mw.ViewPageTarget.

Bug: 51253
Change-Id: Idb172ee46b7142681d41e593eacd9600b8f11a9a
2013-07-31 00:45:28 +00:00
Roan Kattouw e49df7f9d9 Infrastructure for loading plugins in the MW integration
Server-side, plugins can register themselves by adding to
$wgVisualEditorPluginModules. This is the recommended way for
MW extensions to extend VE. Client-side, plugins can register
themselves through mw.libs.ve.addPlugin(), which takes a string
(RL module name) or a callback.

When VisualEditor loads, we load the registered plugin modules in
parallel with ext.visualEditor.core. Note that they're loaded in
parallel, not after, and so the plugins should explicitly depend
on ext.visualEditor.core if they use or extend classes in VE core.
Once the modules finish loading and user and site scripts have run,
we execute the registered plugin callbacks. These callbacks can
optionally return a promise. We gather these promises and wait for
all of them to be resolved, then initialize the editor.

This allows Gadgets to extend VE by top-loading a small module that
depends on ext.visualEditor.viewPageTarget.init and calls
mw.libs.ve.addPlugin( 'ext.gadget.bottomHalfGadget' ); , the bottom
half being a hidden Gadget that depends on ext.visualEditor.core and
contains the actual code. The addPlugin() call needs to be in a
top-loading module because otherwise there's no guarantee that the
plugin will be registered before the user clicks edit and VE loads.

User and site scripts can extend VE by simply calling addPlugin()
directly, as mw.libs.ve is already present when user scripts run (since
it's top-loaded) and VE waits for 'user' and 'site' to run before
executing plugins.

If user/site scripts need to load additional JS files, they can load
these with $.getScript() and return the corresponding promise:
mw.libs.ve.addPlugin( function() { return $.getScript( 'URL' ); } );

For a diagram of all this, see
https://www.mediawiki.org/wiki/File:VE-plugin-infrastructure.jpg :)

VisualEditor.php:
* Add $wgVisualEditorPluginModules

VisualEditor.hooks.php:
* Expose $wgVisualEditorPluginModules in JS

ve.init.mw.ViewPageTarget.init.js:
* Add mw.libs.ve.addPlugin function that just stores the registered
  values in an array and passes them into the mw.Target when it's
  being initialized

ve.init.mw.Target.js:
* Add $wgVisualEditorPluginModules to the set of modules to load when
  initializing VE
* Add a Deferred (this.modulesReady) to track module loading
* Add addPlugin() and addPlugins() methods that add to either
  this.modules or this.pluginCallbacks
* In load(), instead of mw.loader.load()ing this.modules, use using()
  to load this.modules plus user and site, and fire onModulesReady()
  when they're loaded
* In onModulesReady(), execute the registered callbacks, gather the
  returned promises, wait for all of them to be resolved, then resolve
  this.modulesReady
* Fire onReady based on this.modulesReady being resolved, rather than
  using a second using() call

Bug: 50514
Change-Id: Ib7d87a17eaac6ecdb8b0803b13840d7ee58902df
2013-07-26 19:31:56 +00:00
Roan Kattouw 393807462e Render check boxes from EditPage
EditPage has a lovely getCheckboxes() function which includes the
minor and watch checkboxes as rendered by MW core, as well as any
checkboxes extensions like FlaggedRevs might have added. Output
these in the API, render them, and send their values back.

ApiVisualEditor.php:
* Build a fake EditPage, get its checkboxes, and return them

ApiVisualEditorEdit.php:
* Pass through posted request data to ApiEdit, which passes it
  through to EditPage thanks to Idab5b524b0e3 in core

ve.init.mw.ViewPageTarget.js:
* Remove minor and watch checkboxes from the save dialog template
  and replace them with a generic checkbox container
* Have getSaveOptions() pull the state of all checkboxes in
** Special-case minor and watch, and pass the rest straight through
** Move normalization from true/false to presence/absence here, from
   ve.init.mw.Target.prototype.save(), because here we know which ones
   are checkboxes and we don't know that in save() without
   special-casing
* Remove getSaveDialogHtml(), we don't need to hide checkboxes based on
  rights anymore because in that case the API just won't send them to us.
** Moved logic for checking the watch checkbox down to where the same
   logic for the minor checkbox already is
* Unwrap getSaveDialogHtml() in setupSaveDialog()
* Access minor and watch by their new IDs throughout

ve.init.mw.Target.js:
* Get and store checkboxes from the API
* Pass all keys straight through to the API

Bug: 49699
Change-Id: I09d02a42b05146bc9b7080ab38338ae869bf15e3
2013-07-24 00:02:14 -07:00
Timo Tijhof 46f40dc696 api: Split save action into separate API module
This allows us to make the token no longer a requirement
for non-save actions while still using the built-in system
for token verification.

Update documentation for "oldid" since it is not required even
outside (paction=save). In fact, if we require it VE loading
fails because it doesn't pass oldid unless it has to when
restoring a specific version.

Bug: 50424
Change-Id: I7b1b50a43648b1cc40a984340846efdb0ba2ecc9
2013-07-11 15:37:23 -07:00
Timo Tijhof d16fef546a mw.ViewPageTarget: Fix incorrect retention of the wrong oldid
* Only pass the oldid to the API from #load if we restoring from
  oldid in the url. Otherwise load the latest version.
* Setting 'restoring' from mw.Target instead of mw.ViewPageTarget
  so that we don't rely on mw.ViewPageTarget in mw.Target#load.
* Fix the API to not require 'oldid' to be passed.
* Fix the API to actually return the 'newrevid' property. It
  was doing a no-op on a $result that is never used due to the
  same variable being overwritten with the result of parseWikitext.
* Moved updating of wgCurRevisionId to mw.ViewPageTarget as it
  belongs there (possible future inline editors probably act
  on a different page than the main one). Also made it only
  update if it isn't undefined, so that a null edit doesn't
  result in wgCurRevisionId being unset.

Bug: 49943
Bug: 50441
Change-Id: I221e5038f95eadf6d87013e80f12394f0376a293
2013-07-08 16:11:23 -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
Renamed from modules/ve/init/mw/ve.init.mw.Target.js (Browse further)