Extension talk:Page Forms

Append "Media:" before the names of uploaded files
After a file is uploaded, I want to create a link to the uploaded file automatically. For example, if you upload a file named "hoge.jpg" and save the page, then the page contains a red link to "hoge.jpg". But, we cannot see the uploaded image by clicking the link. So, I want to change the link to "Media:hoge.jpg". Does anyone have a good idea to do that?

You could achieve this using an Array Map Template. First, create a template with a form that updates a parameter in a template (which you probably already have done). In the example below, this parameter is called files, and the Array Map Template (which is a standard wiki template) is called Formfile.

Then I created a template called Formfile which looks like this:

The way the template above works a user can either upload the file using Semantic Forms, or just type the name of the file into the field. If the file exists (they uploaded it) it will display a link. Otherwise they'll get a "click to upload" message. --Gkullberg 15:21, 5 January 2010 (UTC)

Autocompletion for multiple properties/namespaces?
Is it possible have autocompletion for more than one property or namespace? For example, it would be nice to be able to have autocompletion on the main namespace and another namespace called "Activity" like this:

autocomplete on namespace=,Activity

Is this possible? --Gkullberg 21:37, 5 January 2010 (UTC)


 * Unfortunately, no... and I can't think of any hacks around it, either. Yaron Koren 21:56, 5 January 2010 (UTC)

Issue with query string and the two steps process with #forminput
Hi Yaron

I am having difficulties getting #forminput to work with pre-set query strings. I would like to use a #forminput to force certain values to a form (namely, a login name).

If I use a page name that already exists, the query string seems to be lost once the form switched to Edit instead of Add.

If I do add a new page, the query string is preserved and the form fields are populated with the values from the query string.

Is that an intended behavior ?

I am using version 1.8.6

- Laurent Alquier


 * Hi, yes, this is intended behavior - you can't override what's in the page already using the form. The principle is that just going to the form and hitting "save" should never change the data in an existing page. If you disagree with that, we can talk about that. Yaron Koren 04:11, 7 January 2010 (UTC)


 * Thanks for the clarification. I agree with the principle - it is safer that way. However, some features of the forms already break that principle (having a field of type List overwrites values in the field that do not match the list for example), and I can see cases where it is beneficial to have a form provide values by query string in edit mode. Maybe having a check for empty values before overwriting with query string parameters could help ? - Laurent


 * It's true that the principle sometimes gets broken... though that, by itself, isn't a reason to break it further. I'm confused, though: do you agree with the principle or not? Yaron Koren 04:34, 7 January 2010 (UTC)


 * I do agree it is safer to have this default behavior :) - Laurenr

Return Free Text with #ask
I would like to be able to return the value in Free Text when using #ask to create a table or a map.

For a little more background: I started out with a description field of the type text. It was having problems with wrapping and displaying content. The Free Text field works really well, but I do not know how to access that data outside of calling the form.


 * Unfortunately, you can't do that - you'll have to go back to using the "Text" type. What were the problems you had with displaying content? It could be that using $smwgLinksInValues could help. Yaron Koren 16:59, 7 January 2010 (UTC)

Upload file tag broken via #formlink
When I add a page by setting an automactic page name, using #formlink, the floatbox to upload a file doesn't appear after clicking the 'upload file' link behind the field.

I made an example of this problem on referata.com: If you fill out the form the usual way the regular floatbox does appear. However if you add a page with #formlink: http://www.referata.com/wiki/Linkformlinktest Clicking 'upload file' opens the upload window as whole page instead of a floatbox.

Is there a way to make the floatbox appear? -JosCo 09:50, 12 January 2010 (UTC)


 * That's odd, although it's a bit of a minor bug, since the query string you have in there (the last parameter) is incorrect - it's just "Formlinktest", but it needs to be either empty or of the form "template-name[field-name]=value", etc. Yaron Koren 23:10, 14 January 2010 (UTC)


 * Thanx for the help. It works like a charm indeed. -JosCo 14:48, 16 January 2010 (UTC)

Page content showing up at bottom of form after upgrading to latest version of SF
In my old version of SF, when I'm in a form and I view the source of the page I see a hidden variable like this:



Note: I can't seem to get the above text to display without wiki evaluation so you will need to edit this comment to see what I'm talking about.

However, after upgrading to the latest version, I see a bunch of page content down at the bottom of the form coming from the page that the form is editing. When I view the source of the page it seems that this content is from a hidden form variable that item isn't converting the {'s and ['s to their HTML equivalents anymore:



Any idea what's wrong? --Gkullberg 20:40, 12 January 2010 (UTC)


 * You've indeed found a bug - this will be fixed in the next version of SF, but it can be fixed now by changing line 1183 of /includes/SF_FormPrinter.inc from:


 * to:

Yaron Koren 19:20, 21 January 2010 (UTC)


 * I still have this problem with partial forms in version 1.8.8. With a regular form it appears to work fine, but if I add the tag at the beginning of a form it replaces, for example, a "{" with the corresponding character code. (I'll space it out so it displays: & # 1 2 3). It likewise replaces all vertical pipes and brackets. End result is the template that goes with the form no longer works. I was upgrading all the way from version 1.6: it worked fine there. -- Chris 03:33, 4 February 2010 (UTC)

Class 'SMWPropertyValue' not found
After adding the include_once-line to LocalSettings.php I got: Fatal error: Class 'SMWPropertyValue' not found in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_LinkUtils.inc on line 79

With error_reporting set to E_ALL I get: Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM - assumed 'SF_NS_FORM' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 183 Notice: Use of undefined constant SF_NS_FORM_TALK - assumed 'SF_NS_FORM_TALK' in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php on line 153 Warning: Cannot modify header information - headers already sent by (output started at /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php:183) in /usr/share/mediawiki/includes/WebResponse.php on line 10 Warning: Cannot modify header information - headers already sent by (output started at /var/lib/mediawiki/extensions/SemanticForms/includes/SF_GlobalFunctions.php:183) in /usr/share/mediawiki/includes/WebResponse.php on line 10 Fatal error: Class 'SMWPropertyValue' not found in /var/lib/mediawiki/extensions/SemanticForms/includes/SF_LinkUtils.inc on line 79

Any ideas what could be wrong?

I took the MediaWiki from stable debian package and it's version 1.12.0. The SemanticMediaWiki is also from stable debian package and it's version is 1.2. The SemanticForms is version 1.8.7. I've set the mediawiki to be finnish (not sure if it has something to do with this.)

-- Tero Laxström, 26 January 2010


 * Hi, the issue is that SF no longer supports versions of SMW before 1.4. I would recommend upgrading your version of SMW (upgrading MediaWiki itself wouldn't hurt either); and if you have any contact with the Debian people, please tell them they're packaging an old version. Yaron Koren 18:03, 26 January 2010 (UTC)

Transclusion of forms (i.e., treating them like templates)
I've created a test form, Form:A. There's nothing special about Form:A; it contents are typical. Now I create a second form, Form:B. The contents of Form:B are: Now when I visit Form:B, the expected behavior would be that I'd see precisely the same thing that I'd see if I visited Form:A. But that's not the case.

Here I've treated Form:A like a template, "transcluding" it into Form:B. We might like to go farther and perform additional substitution on Form:A, giving it parameters like any template. Why would one want to do such a thing? For situations when it is necessary to dynamically generate a form:
 * Complicated data-entry scenarios
 * Data pre-processesing steps
 * Multi-step data "wizards"
 * etc.

My specific use-case requires that I do some complicated pre-processing in order to decide a page name. So, I'd like to have an initial form take care of the page-name-entry steps and dynamically generate a second form where the user inputs the remaining data. Sadly, it seems that forms cannot be treated as templates. Am I correct in this? It is certainly possible that I'm missing something in my attempts to make form transclusion work. If I'm indeed correct, are there any work-arounds or maybe some more concise machinery for doing what I want to do?

Thanks all! And great work on this software! 189.153.80.253 04:40, 27 January 2010 (UTC)


 * What you're talking about should work, in theory - see here for what may be the problem. Yaron Koren 04:54, 27 January 2010 (UTC)


 * Yaron, can you recommend a method for creating a multi-step data entry process of the kind mentioned above? I'd like to use Forms to walk the user through some decision steps to make sure they add data the appropriate category. Cheers! 24.206.104.84 21:39, 31 January 2010 (UTC)


 * You could check out the "Header Tabs" extension - it's a way of separating out form sections that can function sort of like a wizard... Yaron Koren 23:53, 31 January 2010 (UTC)


 * What would be ideal would be to have one form create another, the second form being of a "temporary" nature in that it would be deleted at the end of the data-entry process. Is something like this possible? 24.206.104.84 16:29, 3 February 2010 (UTC)


 * That's not possible, although it doesn't sound all that ideal, either... it sounds like a hack. Though then again, I think wizards only make sense when one's input in one set of fields influences what other fields are shown later on - and SF can't do that at the moment either. Yaron Koren 20:26, 3 February 2010 (UTC)

Space in query string #formlink; upload tag not working
When adding a page via #formlink with a space in the query string the upload tag doesn't work. For an example see this form.  The Formlink is: " http://www.referata.com/wiki/Special:AddData/Formlinktest?Setpagetitle[City]=City with space in name " The floatbox doesn't appear. I noticed a related bugfix in version 1.2.5. My current SF version 1.8.5. -JosCo 14:41, 29 January 2010 (UTC)


 * My guess is that you're using the IE browser - is that true? This seems to be a problem on IE (which I always forget to test on), but not in any other browser. Yaron Koren 16:23, 29 January 2010 (UTC)


 * Yeah, that's true. I see now in FF it works fine, but I'm afraid I can't really expect all users in the company to change the browser because of this. Would it be possible to make a fix for it, or maybe can you think of a possible workaround for this issue? -JosCo 15:59, 30 January 2010 (UTC)


 * No, I can't rely on anyone to give up IE, much as I would like to. :) This will be fixed in the next version. Yaron Koren 13:42, 2 February 2010 (UTC)


 * Ok, I will check it out. :) Thank you for the great help. -JosCo 15:16, 3 February 2010 (UTC)

"Edit with form"-Tab missing
I've just installed a fresh svn version of mediawiki (1.16alpha, r61710), Semantic Mediawiki (Version 1.5h-SVN, r61710) and Semantic Forms (Version 1.5h-SVN, r61710). After that I used "Create Class". Everything looks fine, except that no "edit with form" tab is shown. --ThomasKalka 12:44, 30 January 2010 (UTC)


 * This was resolved on the mailing list; the problem was that the current SVN version of SMW is buggy. Yaron Koren 13:38, 3 February 2010 (UTC)

mandatory check stopped working properly
Hi,

I have some forms with a field marked as mandatory.

When the form is saved, and this mandatory field is empty, the error message flashed briefly beside the field, but the then form saves itself anyway.

Any idea what could be wrong? Thanks Jon


 * Is there a URL for this, or could you reproduce it on a public wiki? Yaron Koren 04:57, 2 February 2010 (UTC)

Problem with the "One-Step-Progress" after Extension Update
Hi, I have a little Problem after updating to the newest Extension Version.

We are using buttons like "Add Person" to create a new Person in our Wiki.

The Page name is normally the Persons Name so we use the INFO-Tag like this:

Before the Update a Person created by the "One-Step-Progress" got the Page name of the Person, but now the Page name is "Person/Your-Name" ???

Can someone help me to change it back to Normal?

-- Simon Bachenberg 11:05GMT+1 - 03.02.2010

I found my error! the "super_page=" Tag seems to work now it should, so everything makes sens :-) after removing it i got what i wanted to have.

-- Simon Bachenberg

= The "one-step process," template parameters, and their default values =

Form:TestB Special:AddData/TestB



Template:TestB

Here, I attempt to set the page name by using the "one-step process." The idea is that, in the event that the user fails to supply the page name via the form, a default name is set. What is relevant, though, is that I attempt to set this default at the level of the template rather than the form. That is, I would like the default name to be retrieved from the default value of the "Page name" parameter in the template. Using such a technique, we could use the template to do complicated pre-processing in order to set the page name. Unfortunately, even this small example fails. Does anyone know why?

Thanks! 24.206.104.84 18:37, 3 February 2010 (UTC)


 * Note that this is a much simpler use-case than the one I am actually interested in. What I'd REALLY like to do is have a form that requests a "page prefix" and a "page suffix" and sets the page name as a complicated function of the two. The idea is to implement this "complicated function" at the level of the template, where its output would supply the default value to the "page name" parameter for the template, a parameter that can be referenced in the form's info tag. Sadly, it seems that the template may not be fully processed - defaults applied, sub-templates called - before the page name is set. Does anyone have any thoughts on the situation? Thanks again. 24.206.104.84 19:13, 3 February 2010 (UTC)


 * Hi, you can't set the default in the template - it has to be in the form, as you've discovered. If there's some specific formula you want applied to create the page name, and it's not currently doable in SF, please write to the semediawiki-user list about it - it might require a discussion about how best to implement it. Yaron Koren 17:50, 4 February 2010 (UTC)


 * Will do. Should I also update the Forms documentation so that it's a little clearer about this lack of capability? 24.206.104.84 18:45, 4 February 2010 (UTC)


 * Sure - wherever you think there's a clearer way to express something in the documentation, feel free to change it. Yaron Koren 21:28, 4 February 2010 (UTC)

= Is the #formlink documentation up to date? =

The example from the documentation

does not produce a button. Instead, it produces a standard link that looks like link text=Push this button to go to the form! (but minus the little external linky thing). 24.206.104.84 05:02, 5 February 2010 (UTC)