Working With MediaWiki
like that of a dropdown, to let the user see all the available values at once. You can also set the combo box to only allow the autocomplete values, and not any arbitrary values, thus having it function even more like a dropdown, by adding the additional parameter "existing values only" to the field tag.
Autocompleting on outside values
Autocompleting on values from outside the wiki is currently a rather intensive process, because you have to massage the outside data to get it into exactly the right format. Ideally this will change in the future, so that arbitrary lists of values can be used within forms. Until then, to have a field autocomplete on outside values, you have to take the following steps:
Create a page/web service that takes in a substring via the query string, and displays a set of autocompletion values; the values should be in JSON format, and look like the JSON returned by the MediaWiki API (see here ). This also makes it easy to autocomplete on the values from another wiki.
Decide on a short string to represent this URL.
Add a line to LocalSettings.php that looks like this:
$sfgAutocompletionURLs[' URL-identifier-string '] = ' URL ';
The URL in this line should look like a call to that web service, but with the substring replaced by the string "".
[4.]Add the parameter "
values from url= URL-identifier-string
" to the relevant field in the form definition.
Multiple values for the same field
Semantic Forms supports having multiple values within a given field, and some form input types — like “checkboxes” and “listbox” — are specifically geared for fields that contain multiple values. Text and textarea fields can also support autocompletion for multiple values. If a form field is meant to hold multiple values, the corresponding template field should most likely contain a call to either #arraymap or #arraymaptemplate — see here . Regardless of what is contained in the template, though, the fact that a field is meant to hold multiple values can be hard-coded in the form definition by adding the parameter "list" to the {{{field}}} tag. The parameter "delimiter=" can also be helpful, if the delimiter between values is meant to be something other than the default (a comma).
Multiple-instance templates
If you add the ’multiple’ parameter to a template, it will allow for multiple (or no) instances of this template in the form, and therefore in the generated page. The sample form here is a good example of a form with multiple-instance templates. There’s a button labeled "Add another"; clicking on it will create a new instance of that template and its fields. Instances can be removed, by clicking on the “Remove” button, and they can also be rearranged, by clicking on the “ribbed arrow” icon on the right-hand side and dragging the instance up or down within the set.
You can rename the "Add another" button to any other text, using the "
add button text=
" parameter. For instance, to change the button to read “Add another occupation” for a template called “Occupation”, you could have
:
{{{for template|Occupation|multiple|add button text=Add another occupation}}}
If you want to semantically store all the data contained in these multiple-instance templates, it is recommended to use the Semantic Internal Objects extension — see here .
Uploading files
If a field in the form is meant to hold the name of an uploaded file (say, an image), you can allow users to upload this file directly through the form. This is done simply by adding the parameter “uploadable” to that field’s declaration in the form definition. This will add a link reading “Upload file” next to this field in the form; if the user clicks on this link, it will pop up a “lightbox”-style window that lets the user upload a file. Once the user has done so, the window will close, and the field will contain the name of the uploaded file. (For more on uploading files, see here .)
If the field is configured to contain a list of values, the new file name will be appended to whatever was there before; otherwise, the file name will overwrite whatever the field contained before.
Defining the bottom of the form
The user inputs at the bottom of the form can be customized using the “standard input” tag. The layout, inclusion and text of each input can be modified. Each user input is defined as a “standard input” tag with its own value; the allowed values are:
save
(for the “Save page”
Weitere Kostenlose Bücher