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
<bryan.tongminh(a)gmail.com>om>:
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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l