... I was looking at commons upload form JavaScript load profile is like
a long waterfall or rather a steep river :(
http://metavid.org/promo/round_trips.png
Would be much nicer do 1 or 2 request instead of 27 ... true... a lot
are gadgets and what not.. but even on a not logged in Main page visit
on En we hit 6 scripts all loading one after another...
The patch to switch over to the script loader involves a lot of
conditionals in a lot of skins... the majority of the scripts get piped
through page serving so a fix to import & group js per wikiTitles would
be added ... (and we would pass along their revision id in the url for
caching support)... all the existing code would run "as is" where the
scriptLoader config var is turned off. While I am touch all of those
parts of the code I might as well pass the css loading to a
loader/grouper as well.
if we are going this way... I will take a pass at making a patch since
it would make other pieces I am working on a lot easier to integrate
with localization.
comments in-line:
Brion Vibber wrote:
> On the other hand we don't want to delay those interactions; it's
> probably cheaper to load 15 messages in one chunk after showing the
> wizard rather than waiting until each tab click to load them 5 at a time.
>
> But that can be up to the individual component how to arrange its loads...
>
>
right ... I used the "tab" example since its a natural load point since
we have to load the JSON search results for the requested query the
interface already displays a little loading animation ... but as Mr.
Maxwell points out given latency its better to front load a lot more ...
that can easily be tweaked towards more front loading ... but if we
have a dozen remote archive integrations maybe not so fun to load them
all at initial run time or maybe you don't want to load the video player
js code for people just interested in grabbing images...or in video
sequences loading all the transitions and all the filters when only fade
to black is used.
anyway .... the idea is it gives developers more flexibility in choosing
what js classes they want to load at any point in time without inuring
HTTP latency request costs for logical modularization of js code into
separate files. Likewise we don't want to /have to/ front load all the
msg text even if we choose to do that for /most/ cases for performance
reasons.
> I'm a bit less certain about this; primarily it creates redundant copies
> of message text between the .js and the .i18n.php files, which is a
> maintenance problem.
>
> Secondarily, it means you lose localization support if you disable the
> JS serving. Currently we do JS localization by doing the lookups in PHP
> and exporting those as JS variables or writing them directly into calls
> to JS functions in the HTML output. This kinda sucks because of the
> degree of manual intervention, but a more basic 'list out which vars you
> need and export them' should be straightforward and avoids the duplication.
>
I would like to eventually take out the msg from the javascript files
and only store a key list in js and the full Msgs only in the php. ...
but for now will just have to deal with duplication... yes it makes
things a bit bothersome... but retains portability and flexibility while
we iron out and standardize the script loader. Once the script loader
is solid it should be adaptable to being used in other CMSs so we can
retain portability and localization and just require the script loader.
> There may also be difficulties with handling the distinction between
> message lookups which need to go to content language and those which
> need to be in the UI language... we also would rather not lose the
> ability to use language-specific features like {{PLURAL:}} and
> {{GENDER:}} which are needed for proper localization of many languages.
>
yea these parts are a bit tricky... I imagine we can detect if we ever
touch those magic words in the msg key list and then export some
additional json keys for a script to use in cases of contextual
swapping.... meaning our js will have to parse those magic words mirror
their logic and then swap based on additional keys proved in the
language packing.
>
> (Note for those who didn't peek at the code -- this is overridable at
> runtime with ?debug=true on the script load; we'd presumably want to be
> able to pass that on from web page views as well.)
>
>
>
added debug var check from web page views in r47713 ...
I did not mention it last time but we also include js code to take
advantage of the script loader system. It passes along any debug request
or unique svn id, auto checks all the libraries as to not request
anything that is already loaded, and groups the requests using the
script loader. So once you have mv_embed lib in place you can "auto
load" libraries with:
mvJsLoader.doLoad({ 'libname' :
'lib_location_in_case_script_loader_is_off', 'lib2' : 'lib2_location'},
function(){
//code to run now that the all the libs are ready
});
Like the localization msg system this logic is hampered by the fact the
script loader is /optional/. If we required the script loader it could
be simpler:
requireOnce( {'list', 'of', 'libs', 'to', 'load'}, function(){
//code to run now that the libs are ready
});
peace,
--michael
_______________________________________________
Wikitech-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
