On Wed, Jul 1, 2009 at 11:21 AM, William Allen Simpson<william.allen.simp...@gmail.com> wrote: >>> * Doesn't inflate the number of languages used in the operation of the site > > This is the important checkbox, as far as integration with the project (my > first criterion), but is the server side code already running JavaScript? > For serving pages?
No but mediawiki and the sites are already chock-full of client side code in JS. You basically can't do advanced development for MediaWiki or the wikimedia sites without a degree of familiarity with Javascript due to client compatibility considerations. > My general rule: coming over the network, presume it's bad data. In this case were not talking about the language mediawiki is written in, we're talking about a language used for server-side content automation (templates). In that case we'd be assuming the inputs are toxic just like in the client side case, since everything, including the code itself came in over the network. I'll concede that there likely wouldn't be much code reuse, but I'd attribute that more to the starkly different purpose and the fact that the server version would have a different API (no DOM, but instead functions for pulling data out of mediawiki). > And we have far too many examples of existing JS > already being used in horrid templates, being promulgated in important > areas such as large categories, that don't seem to work consistently, and > don't work at all with JavaScript turned off. > I run Firefox with JS off by default for all wikimedia sites, because of > serious problems in the not so recent past! Fortunately this is a non-issue here: Better server side scripting enhances the sites ability to operate without requiring scripting on the client. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
