Extension talk:SimpleForms.php

This talk page pertains specifically to the development of this extension. For more general discussion about bugs and usage etc, please refer to the mediawiki.org talk page at MW:Extension talk:Simple Forms

Using MediaWiki Ajax instead of MooTools

0.3.13 has had the following snippet of code added in preparation for the 0.4 release which will no longer depend on Mootools for its ajax functionality. <php> if ($wgUseAjax && $_REQUEST['action'] == 'ajax' && $_REQUEST['rs'] == 'wfSimpleFormsAjax') { $_REQUEST['action'] = 'render'; if (is_array($_REQUEST['rsargs'])) foreach ($_REQUEST['rsargs'] as $arg) if (preg_match('/^(.+?)=(.+)$/',$arg,$m)) $_REQUEST[$m[1]] = $m[2]; } </php> This allows us to use the sajax_do_call function from MediaWiki's ajax.js, but this works by requesting the AjaxDispatcher class to execute a function specified in the request and to return the results of the function. This is not quite the way SimpleForms needs it to work because the AjaxDispatcher is instantiated before any high-level MediaWiki objects have been instantiated, but SimpleForms needs to return the fully rendered page content with all extension activated etc.

The code above gets around this problem by detecting if incoming requests from sajax_do_call are specifying a function called "wfSimpleFormsAjax", and if so the action is changed to render so the request will no be handled by the AjaxDispatcher. The sajax_do_call argument list is shifted into the main $_REQUEST array as if it came from a normal GET or POST request. Note that there is actually no function called wfSimpleFormsAjax, it is just a dummy value used to identify the 'sajax_do_call request as one for SimpleForms to handle instead of the AjaxDispatcher.

Here is an example SimpleForms input which makes an ajax request using the sajax_do_call function:

onClick=sajax_do_call('wfSimpleFormsAjax',['title=no-such-article'],document.getElementById('sajax-test'))|value=Sajax Test}} this is a div tag with id attribute set to "sajax-test" The button has the following JavaScript code in its onClick event: <js>sajax_do_call('wfSimpleFormsAjax',['title=no-such-article'],document.getElementById('sajax-test'))</js>

MediaWiki API

There is a MediaWiki API under development which will allow modifcation of content via request variables inherently.

It appears that links do not parser in the edit summary e.g. this diff. Would be a nice to be able to link to the form deriving content--Sven 21:29, 30 June 2007 (NZST)

SimpleForms expects wikitext with links etc to be passed, but you have to put <nowiki> around it so that it's not parsed before being assigned to the form attribute. --Nad 22:01, 30 June 2007 (NZST)

Edit forms

Initially I was thinking of having an #edit parser-function which extends the #form functionality to behave differently from action=edit and the CreateArticle specialpage.

After starting the SimpleDatabase specialpage I realised that being able to open a form ajaxly that is connected to another articles content (that article acts as the forms data-source) is more intuitive, and doesn't require two different ways of defining forms.

Possibly a better solution still could be to use an editform parameter with action=edit. The parameter would determine which definition to update (by template name, with id too if necessary to disambiguate). The parameter should also be able to specify to update all (which could be a good setting for the normal edit action's url too). Maybe allowing a list of template/id's would be good too.

• Each template definition needs to be able specify a list of forms which are able to edit it.
• Using action=edit with forms could be the best way to handle article updating since it would use MediaWiki's edit tokens properly

Semantic Forms

This way of integrating with the existing edit system is how the SemanticForms CreateForm special-page works. Maybe SimpleForms should not try and handle the structured data side of things at all and should only handle the functionality-based inputs.

• Semantic red-link example

Source Edit Policy

So what's the policy on editing the source of this extension? I see registered users are allowed to edit it, so I'm concluding it's not "Keep your damn dirty hands off of it." But is there any sort additional etiquette other than "make sure it works?" Ask for permission? Provide purpose and details of the edit? —Sledged (talk) 13:44, 7 March 2008 (NZDT)

Go for it :) make sure that updates are runnable and not broken though. I've been working on a new version 0.4 but haven't had time for a few months to make any progress. The new one is designed to use the MediaWiki API for updating content, and will make it simple to map forms to template fields. --Nad 16:10, 7 March 2008 (NZDT)

That sounds a lot like Semantic Forms without the need for Semantic MediaWiki. —Sledged (talk) 13:48, 8 March 2008 (NZDT)

We'll be making heavy use of SMW too, but we want to have our forms work with AJAX and skip the edit form, but that's not in the Semantic Forms road map --Nad 14:51, 8 March 2008 (NZDT)

I wouldn't mind seeing that functionality in this extension, but there's a few pitfalls you should avoid.

• Don't require headings be put inside templates. This is quite an annoyance for me with SF. Putting headings in templates is a bad policy to begin with, but to require it such a thing in order to use the forms...
• Follow redirects to the underlying template.
• Make sure the extension recognizes subst:SomeTemplate and SomeTemplate as the same template.
• Give users control of newline characters between templates. I've had a number of templates that require that templates begin on the same line where the last one ended. Conversely, a user may want more than on newline between a pair of template calls.
• With the loops extension I don't have to define a finite number of template arguments. A user can enter |arg1=val1 |arg2=val2 |arg3=val3 ... |argN=valN so long as the arguments are consecutively numbered. So the form should be allow more fields to be added dynamically by the user. SF does this with respect to a set of fields associated with a template call, but not a specific field within a template call.
• Handle pipes and braces entered by users that prematurely end template arguments and template calls. Or any other aberrant wiki-markup for that matter.

—Sledged (talk) 18:30, 8 March 2008 (NZDT)