Because of that an API Sandbox may be able to be created completely client side.
The extension would contain a little bit of php to load the modules and pass interface messages, declare the .i18n files and the rest could be an OOP JavaScript module using jQuery (which is in core now) to do .post /get/ajax/getJSON and UI elements (jQuery UI). I'm not saying we should do it completely client side, simply because we can. But if there's no need for a new API module etc. that would be nice :-) To save some generation time, the basic html structure should probably be built server-side through subclassing SpecialPage. -- Krinkle Op 28 mrt 2011, om 18:43 heeft Roan Kattouw het volgende geschreven: > 2011/3/28 Bryan Tong Minh <[email protected]>: >> That would be the best way to go. You really don't want to do this >> manually. Every API modules has a function getFinalParamDescription() >> which will give you the parameter description, including the defaults >> and the variable type. Best look at ApiBase::makeHelpMsgParameters() >> how this is handled by the documentation generator. >> > I said this on IRC but I'll repeat it here: the API exposes the data > from getFinalParamDescription() and friends through action=paraminfo. > > Roan Kattouw (Catrope) > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
