Hey all, http://meta.wikimedia.org/wiki/Summer_of_Code_2006#Upload_form_improvements I would like to submit an application for that but it seems like it requieres some javascript and AJAX and it looks like wikimedia devs are against AJAX as it stated on top of the page (see "Hi folks, please don't add "AJAX" etc" on top). So my question is, is this improvement approved by the wikimedia dev ?
thanx in advance
Pat
Patrick Aljord wrote:
Hey all, http://meta.wikimedia.org/wiki/Summer_of_Code_2006#Upload_form_improvements I would like to submit an application for that but it seems like it requieres some javascript and AJAX and it looks like wikimedia devs are against AJAX as it stated on top of the page (see "Hi folks, please don't add "AJAX" etc" on top). So my question is, is this improvement approved by the wikimedia dev ?
"Add a bunch of AJAX stuff" is not a suitable project. :)
A well-designed upload system, which incorporates some AJAX-y bits as an aid to getting its job done, is a suitable project.
-- brion vibber (brion @ pobox.com)
Pat,
I believe that refers to the proposed AJAX project (which was removed along with a WYSIWYG project that had a scope far too large).
Someone else can probably clarify if you'd be kicked into the Web 2.0 reject pile or not.
christopher
On 4/28/06, Patrick Aljord patcito@gmail.com wrote:
Hey all, http://meta.wikimedia.org/wiki/Summer_of_Code_2006#Upload_form_improvements I would like to submit an application for that but it seems like it requieres some javascript and AJAX and it looks like wikimedia devs are against AJAX as it stated on top of the page (see "Hi folks, please don't add "AJAX" etc" on top). So my question is, is this improvement approved by the wikimedia dev ?
thanx in advance
Pat _______________________________________________ Wikitech-l mailing list Wikitech-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/wikitech-l
On Fri, Apr 28, 2006 at 12:23:13PM +0200, Patrick Aljord wrote:
Hey all, http://meta.wikimedia.org/wiki/Summer_of_Code_2006#Upload_form_improvements I would like to submit an application for that but it seems like it requieres some javascript and AJAX and it looks like wikimedia devs are against AJAX as it stated on top of the page (see "Hi folks, please don't add "AJAX" etc" on top). So my question is, is this improvement approved by the wikimedia dev ?
As Brion Vibber and Christopher Budnick pointed out, each in his own way, I think the concern here is that you're adding needed functionality in a manner that makes good sense -- and that you're not throwing AJAX at it just because AJAX is buzzword-compliant. I, for one, am perfectly happy with unadorned static (X)HTML when it solves the problem quickly, easily, and fully. It runs faster and imposes less server load, too. Where AJAX provides actual measurable benefits, though, it's certainly an option to explore without prejudice.
That's probably pretty much the same attitude others have when they say "please don't add AJAX".
On 4/28/06, Chad Perrin perrin@apotheon.com wrote:
On Fri, Apr 28, 2006 at 12:23:13PM +0200, Patrick Aljord wrote:
Hey all, http://meta.wikimedia.org/wiki/Summer_of_Code_2006#Upload_form_improvements I would like to submit an application for that but it seems like it requieres some javascript and AJAX and it looks like wikimedia devs are against AJAX as it stated on top of the page (see "Hi folks, please don't add "AJAX" etc" on top). So my question is, is this improvement approved by the wikimedia dev ?
As Brion Vibber and Christopher Budnick pointed out, each in his own way, I think the concern here is that you're adding needed functionality in a manner that makes good sense -- and that you're not throwing AJAX at it just because AJAX is buzzword-compliant. I, for one, am perfectly happy with unadorned static (X)HTML when it solves the problem quickly, easily, and fully. It runs faster and imposes less server load, too. Where AJAX provides actual measurable benefits, though, it's certainly an option to explore without prejudice.
That's probably pretty much the same attitude others have when they say "please don't add AJAX".
so are you ok for a " upload progress" and an "lazy loading"? those one requires ajax. the gmail like functionnallity to add several files at the same time is only a little javascript with no server load.
On 4/29/06, Patrick Aljord patcito@gmail.com wrote:
so are you ok for a " upload progress" and an "lazy loading"? those one requires ajax. the gmail like functionnallity to add several files at the same time is only a little javascript with no server load.
Having these features is OK, I think, as long as they degrade gracefully to older browsers (including text mode browsers which may be used by blind people). The editing toolbar is an example of a JavaScript feature in MediaWiki that is only user-visible if the client supports it.
An AJAX-based category selector would be nice, especially if written in such a general way that it can not only be used on the upload form, but possibly also be called from the toolbar, opening in a little pop-up and inserting categories into the edit window.
There's no prohibition against AJAX in MediaWiki or anything like that. To the contrary, there's actually a basic AJAX search autocompletion feature in SVN Trunk, which can be activated by setting $wgUseAjax=true in LocalSettings.php.
I'm the person who proposed the upload form remodeling task, if you want, we can Skype about it and discuss in detail what could be done.
Erik
Chad Perrin wrote:
As Brion Vibber and Christopher Budnick pointed out, each in his own way, I think the concern here is that you're adding needed functionality in a manner that makes good sense -- and that you're not throwing AJAX at it just because AJAX is buzzword-compliant. I, for one, am perfectly happy with unadorned static (X)HTML when it solves the problem quickly, easily, and fully. It runs faster and imposes less server load, too. Where AJAX provides actual measurable benefits, though, it's certainly an option to explore without prejudice.
Although I largely agree with you (especially the "buzzword-compliant" bit, heh!), I must state that AJAX often does run faster and save server load. Imagine there was an AJAX-y way of adding a language link to an existing article. This is just an example. In the traditional way, you have to (1) load up the edit page, (2) submit it, and (3) re-render the article page. Even a separate mechanism to add language tags would have those three steps. With AJAX, however, you would have JavaScript create the UI to enter the tag *and* update the page in-place, client-side. Only the submission step would be an actual server hit.
Timwi
On Sun, Apr 30, 2006 at 01:06:02PM +0100, Timwi wrote:
Chad Perrin wrote:
As Brion Vibber and Christopher Budnick pointed out, each in his own way, I think the concern here is that you're adding needed functionality in a manner that makes good sense -- and that you're not throwing AJAX at it just because AJAX is buzzword-compliant. I, for one, am perfectly happy with unadorned static (X)HTML when it solves the problem quickly, easily, and fully. It runs faster and imposes less server load, too. Where AJAX provides actual measurable benefits, though, it's certainly an option to explore without prejudice.
Although I largely agree with you (especially the "buzzword-compliant" bit, heh!), I must state that AJAX often does run faster and save server load. Imagine there was an AJAX-y way of adding a language link to an existing article. This is just an example. In the traditional way, you have to (1) load up the edit page, (2) submit it, and (3) re-render the article page. Even a separate mechanism to add language tags would have those three steps. With AJAX, however, you would have JavaScript create the UI to enter the tag *and* update the page in-place, client-side. Only the submission step would be an actual server hit.
True -- there are ways to leverage AJAX and similar technologies to reduce server load. It requires care and good planning to implement them, though, and it's of critical importance in a project like MediaWiki to ensure that it degrades gracefully so that everything still works even if the client doesn't allow Javascript. Like I said, if it adds positive value, it's a good idea. You just have to know what you're doing and why you're doing it.
On 4/30/06, Chad Perrin perrin@apotheon.com wrote:
On Sun, Apr 30, 2006 at 01:06:02PM +0100, Timwi wrote:
Chad Perrin wrote:
As Brion Vibber and Christopher Budnick pointed out, each in his own way, I think the concern here is that you're adding needed functionality in a manner that makes good sense -- and that you're not throwing AJAX at it just because AJAX is buzzword-compliant. I, for one, am perfectly happy with unadorned static (X)HTML when it solves the problem quickly, easily, and fully. It runs faster and imposes less server load, too. Where AJAX provides actual measurable benefits, though, it's certainly an option to explore without prejudice.
Although I largely agree with you (especially the "buzzword-compliant" bit, heh!), I must state that AJAX often does run faster and save server load. Imagine there was an AJAX-y way of adding a language link to an existing article. This is just an example. In the traditional way, you have to (1) load up the edit page, (2) submit it, and (3) re-render the article page. Even a separate mechanism to add language tags would have those three steps. With AJAX, however, you would have JavaScript create the UI to enter the tag *and* update the page in-place, client-side. Only the submission step would be an actual server hit.
True -- there are ways to leverage AJAX and similar technologies to reduce server load. It requires care and good planning to implement them, though, and it's of critical importance in a project like MediaWiki to ensure that it degrades gracefully so that everything still works even if the client doesn't allow Javascript. Like I said, if it adds positive value, it's a good idea. You just have to know what you're doing and why you're doing it.
Ok but I'm not a ajax expert so I'd probably reuse stuff from script.aculo.us. Would that be ok? If not I think I'll apply for the External Editor helper app.
Brion Vibber wrote:
Is it GPL or GPL-compatible?
MIT-style; fully compatible.
wikitech-l@lists.wikimedia.org