On 4/17/09 6:45 PM, Marco Schuster wrote:
On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibberbr...@wikimedia.org wrote:
* Background JavaScript worker threads
You mean...stuff like bots written in Javascript, using the XML API?
I could imagine also sending mails via Special:Emailuser in the
There is an issue with running a foreground JS thread that is super fast and
might send a lot of request to the server. Heavy processing on the client
side would alleviate the load from the server (if possible) but it might
push another load on the server (in the presented example of sending
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by default.
On Wed, Apr 15, 2009 at 3:05 PM, Brion Vibber br...@wikimedia.org wrote:
Just a heads-up --
Michael Dale is working on some cleanup of how the various JavaScript
bits are
On 4/22/09 9:33 AM, Sergey Chernyshev wrote:
Exactly because this is the kind of requests we're going to get, I think it
makes sense not to have any library bundled by default, but have a
centralized handling for libraries, e.g. one extension asks for latest
jQuery and latest YUI and MW loads
On 4/22/09 9:28 AM, Brian wrote:
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by default.
Rather than bundling multiple separate libraries we aren't going to use
in core code, I'd rather just make sure we've got a consistent
Yep, with jQuery in the core it's probably best to just bundle it.
There is another issue with the code loading and stuff - making JS libraries
call a callback function when they load and all the functionality to be
there instead of relying on browser to block everything until library is
loaded.
This would be a great idea as the library is always updated and has a lot of
features for the front end.
On Wed, Apr 22, 2009 at 12:28 PM, Brian brian.min...@colorado.edu wrote:
Many extensions are now using the Yahoo User Interface library. It would be
nice if mediawiki included it by
No, my link is about 3 ways of loading:
1. Normal script tags (current style)
2. Asynchronous Script Loading (loading scripts without blocking, but
without waiting for onload)
3. Lazyloading (loading script onload).
Number 2 might be usable as well.
In any case changing all MW and
hmm right...
The idea of the scriptLoader is we get all our #1 included javascript in
a single request. So we don't have round trips that would benefit as
much from lazy loading so no need to rewrite stuff that is included that
way already.
I don't think we are proposing convert all scripts to
On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
Are there any plans to use Google Gears for storage on clients? Okay, people
have to enable it by hand, but it shoulda speed up page loads for people
very much (at least for those who use it).
What,
On Fri, Apr 17, 2009 at 1:38 PM, Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
wrote:
On Thu, Apr 16, 2009 at 6:35 PM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
Are there any plans to use Google Gears for storage on clients? Okay,
people
have to enable
On Fri, Apr 17, 2009 at 3:11 PM, Marco Schuster
ma...@harddisk.is-a-geek.org wrote:
Isn't GG supposed to be an implementation of localStorage for browsers who
don't support it yet
I don't think Gears uses the localStorage API. It seems to use its
own APIs. But I've never used either, to be
On 4/16/09 3:35 PM, Marco Schuster wrote:
Are there any plans to use Google Gears for storage on clients? Okay, people
have to enable it by hand, but it shoulda speed up page loads for people
very much (at least for those who use it).
For those not familiar with it, Google Gears provides a few
On Fri, Apr 17, 2009 at 11:42 PM, Brion Vibber br...@wikimedia.org wrote:
* Background JavaScript worker threads
Not super high-priority for our largely client-server site. Can be
useful if you're doing some heavy work in JS, though, since you can have
it run in background without freezing
On Thu, Apr 16, 2009 at 2:35 PM, Sergey Chernyshev
sergey.chernys...@gmail.com wrote:
Speaking of libraries and all, I think it's worth merging libraries in
general and figuring out a way for skin and extension developers to include
libraries in the way that system can only:
- include a
mv_embed has some functions for doing exactly that.
You can run something like: doLoad({list, of, classes, that, i need},
function(){
//code to run now that all those components have been included.
}
It plays well with the script loader and loads it all the requested
components in a single
I have a branch I have made some initial commits to..
http://svn.wikimedia.org/viewvc/mediawiki/branches/script-loader/
(Its not ready yet)...will be great to have some tests to compare it
with... I will be sure to let you know when it is ready ;)
peace,
michael
Sergey Chernyshev wrote:
On Wed, Apr 15, 2009 at 11:05 PM, Brion Vibber br...@wikimedia.org wrote:
Just a heads-up --
Michael Dale is working on some cleanup of how the various JavaScript
bits are loaded by the skins to centralize some of the currently
horridly spread-out code and make it easier to integrate in a
oky... branch /branches/script-loader/ ready for wider testing
after you check out the branch you have to add $wgEnableScriptLoader =
true; to your local settings.
Things I don't tackle in this version of the scriptLoader:
1) checking the version of every msg string packaged in JS (right now
These changes will probably result in some minor adjustments to existing
skins. (I will try not to completely break compatibility cuz I know
there are many custom skins out in the wild that would be no fun to stop
working once they update medaiWiki)
This consolidation of head includes _may_
That's great news. I've been programming in JavaScript quite a lot the
last few years and i think i would've probably gone insane if i hadn't
discovered jQuery. Especially for complex and intricate HTML
selections it's pretty amazing what you can do with jQuery.
Also, the fact that animations are
21 matches
Mail list logo
