Hi
I was planning to make an api sandbox for mediawiki as a part of gsoc 2011.
while going through mediawiki documentation, i found that many functions needed POST rather than GET requests. i am planning for flickr like api sandboxhttp://www.flickr.com/services/api/explore/?method=flickr.contacts.getListfor mediawiki. in flickr the documentation of every method has a link to api explorer (sandbox) where user can test different values for each parameter and the result is displayed in a div in the same page.
media wiki sandbox will display available parameters that can be used for a particular method (drop-down if the values are previously known). the user can fill the forms with his own values. the api then will send a GET or POST request (AJAX request) according to the scenario (using JQuery or some other JS library) and display the results in a div in the same page. the page shall also display a url for executing the same ajax request.
to make the api sandbox really useful, it ideally should have automatic php code generation too ( i don't know if it is overambitious ). for example for login and logout, user can just give his userid and password and the code he would write for php is automatically displayed.
i eagerly await for suggestions
-- Salil IRC : _Salil_
On Mon, Mar 28, 2011 at 5:39 PM, SALIL P A salilpa007@gmail.com wrote:
to make the api sandbox really useful, it ideally should have automatic php code generation too ( i don't know if it is overambitious ). for example for login and logout, user can just give his userid and password and the code he would write for php is automatically displayed.
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.
Bryan
thanks bryan :)
Salil P A
On Mon, Mar 28, 2011 at 9:40 PM, Bryan Tong Minh bryan.tongminh@gmail.comwrote:
On Mon, Mar 28, 2011 at 5:39 PM, SALIL P A salilpa007@gmail.com wrote:
to make the api sandbox really useful, it ideally should have automatic
php
code generation too ( i don't know if it is overambitious ). for example
for
login and logout, user can just give his userid and password and the code
he
would write for php is automatically displayed.
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.
Bryan
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2011/3/28 Bryan Tong Minh bryan.tongminh@gmail.com:
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)
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@gmail.com:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
i have built a simple mockup file in salilpa.com/wiki. here i have implemented the Opensearch http://www.mediawiki.org/wiki/API:Opensearch method. it has a simple form structure and on click opens a new tab with the results.
i could not ajaxify the request because of the restriction Origin http://salilpa.com is not allowed by Access-Control-Allow-Origin.
i have used jquery and plan to use it extensively once the code is hosted on wiki server
expecting valuable comments
Salil P A
On Mon, Mar 28, 2011 at 11:04 PM, Krinkle krinklemail@gmail.com wrote:
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@gmail.com:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
JSONP is exactly the reason why cross-domain works. It allows you to use callbacks and get the data from there.
ie. something like the following will work to en.wikipedia.org from your domain as well:
<code> $.ajax({ url: 'http://en.wikipedia.org/w/api.php', 'data' : { format: 'json', action: 'opensearch', search: 'Hello', namespace: '0|4|10' }, dataType: 'jsonp', // adds a callback-parameter to data success: function( response ) { if ( !response || !response[0] || !response[1].length ) { return; // error or no results } alert( response[1].join( ',' ) ); // results ! } }); </code>
Op 28 mrt 2011, om 19:57 heeft SALIL P A het volgende geschreven:
i have built a simple mockup file in salilpa.com/wiki. here i have implemented the Opensearch http://www.mediawiki.org/wiki/API:Opensearch method. it has a simple form structure and on click opens a new tab with the results.
i could not ajaxify the request because of the restriction Origin http://salilpa.com is not allowed by Access-Control-Allow- Origin.
i have used jquery and plan to use it extensively once the code is hosted on wiki server
expecting valuable comments
Salil P A
On Mon, Mar 28, 2011 at 11:04 PM, Krinkle krinklemail@gmail.com wrote:
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@gmail.com:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
http://www.mediawiki.org/wiki/User:Salil : final Gsoc proposal
expecting your valuable comments
regards Salil P A
On Wed, Mar 30, 2011 at 4:41 AM, Krinkle krinklemail@gmail.com wrote:
JSONP is exactly the reason why cross-domain works. It allows you to use callbacks and get the data from there.
ie. something like the following will work to en.wikipedia.org from your domain as well:
<code> $.ajax({ url: 'http://en.wikipedia.org/w/api.php', 'data' : { format: 'json', action: 'opensearch', search: 'Hello', namespace: '0|4|10' }, dataType: 'jsonp', // adds a callback-parameter to data success: function( response ) { if ( !response || !response[0] || !response[1].length ) { return; // error or no results } alert( response[1].join( ',' ) ); // results ! } }); </code>
Op 28 mrt 2011, om 19:57 heeft SALIL P A het volgende geschreven:
i have built a simple mockup file in salilpa.com/wiki. here i have implemented the Opensearch http://www.mediawiki.org/wiki/API:Opensearch method. it has a simple form structure and on click opens a new tab with the results.
i could not ajaxify the request because of the restriction Origin http://salilpa.com is not allowed by Access-Control-Allow- Origin.
i have used jquery and plan to use it extensively once the code is hosted on wiki server
expecting valuable comments
Salil P A
On Mon, Mar 28, 2011 at 11:04 PM, Krinkle krinklemail@gmail.com wrote:
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@gmail.com:
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 28.03.2011, 19:39 SALIL wrote:
I was planning to make an api sandbox for mediawiki as a part of gsoc 2011.
while going through mediawiki documentation, i found that many functions needed POST rather than GET requests. i am planning for flickr like api sandboxhttp://www.flickr.com/services/api/explore/?method=flickr.contacts.getListfor mediawiki. in flickr the documentation of every method has a link to api explorer (sandbox) where user can test different values for each parameter and the result is displayed in a div in the same page.
media wiki sandbox will display available parameters that can be used for a particular method (drop-down if the values are previously known). the user can fill the forms with his own values. the api then will send a GET or POST request (AJAX request) according to the scenario (using JQuery or some other JS library) and display the results in a div in the same page. the page shall also display a url for executing the same ajax request.
to make the api sandbox really useful, it ideally should have automatic php code generation too ( i don't know if it is overambitious ). for example for login and logout, user can just give his userid and password and the code he would write for php is automatically displayed.
Since this project wasn't accepted for GSoC, I decided to do it myself. Although there is still some work to do, it's already in extensions/ApiSandbox and awaits your comments, suggestions and bashing:) Description page is at http://www.mediawiki.org/wiki/Extension:ApiSandbox
wikitech-l@lists.wikimedia.org