Commit graph

6 commits

Author SHA1 Message Date
Alex Monk c68b58eedf Try not to die when RESTbase returns a 404
Just assume content = '' like we did with Parsoid

Change-Id: I1b076f4e37a8c54733da0e4535adb7a50ae2a7e5
2015-03-30 08:44:31 +01:00
ecotg 175e60edaf Strip X-Parsoid Performance Headers from Visual Editor
Stripped out X-Parsoid Performance Headers, previously used to gather and
forward Parsoid's performance information, from ApiVisualEditor.php,
ve.init.mw.Target.js and ve.init.mw.TargetLoader.js. Change I936ada7b1 strips
out the corresponding X-Parsoid Performance Headers from Parsoid. Parsoid's
current performance instrumentation is achieved using Graphite and txstatsd.

Change-Id: I57d6f866a7d8287a5115e6236b0fb25bc4d0eabd
2015-03-27 12:03:15 -06:00
Roan Kattouw b19104ed04 Send requests to RESTbase directly when so configured
Also introduces paction=metadata in ApiVisualEditor which
doesn't hit Parsoid but gets all the other information we need.

Bug: T90374
Change-Id: I71edbc0f8dc15a6f8d3672c10ca3c641cc172be7
2015-03-26 16:00:54 -07:00
Roan Kattouw 812cb9aa2c Unbreak TargetLoader when ViewPageTarget.init isn't present
By lazy-initializing mw.libs.ve

Change-Id: I2fea8a0935b43b5a25287f68bd7487c448d006b6
2015-03-17 17:38:29 -07:00
Roan Kattouw f620111b9e Send Parsoid API request immediately when user clicks edit
Move requestPageData from mw.Target to TargetLoader, call it
in init init, and pass the promise it returns into load()
via activate().

Bug: T90372
Change-Id: I828b8474e5a76b3d0d7d08735b4d865c29d2f820
2015-03-16 08:56:42 -07:00
Roan Kattouw d371014e5d Load RL modules in one load.php request, rather than in two stages
This introduces TargetLoader, which manages plugins and RL modules
in a slightly more generic fashion so that Targets themselves don't
have to. This allows us to load all RL modules in one load.php
request, rather than first loading ViewPageTarget which then
loads the other modules.

TargetLoader loads in the bottom queue, so it will be loaded
as part of the main load.php request, but in VPT.init.js we
still have to wait for it with using() because it might not
have arrived yet. This also degrades gracefully on cached pages
where TargetLoader isn't in the bottom queue: it'll be loaded
as a separate request instead, which is suboptimal but no
worse that what we were doing before.

Right now TargetLoader is small enough that it could also be in
the top queue, but in the future we want to add things like
the action=visualeditor API request to it, and mw.Api is
relatively big.

Note: this also makes a breaking change to the plugin API:
plugin callbacks no longer receive the target instance
as a parameter, as they're now executed before the target
has been constructed rather than after. In the long term,
if we want to give plugins access to the target instance,
we could give them the target promise somehow. For now,
I've killed this feature because nothing used it and
the change from a direct object reference to a promise
would have been a breaking change anyway.

Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init.

Bug: T53569
Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
2015-03-15 03:43:05 +01:00