Extension talk:Page Forms

Modify Templates
Hi, is there any way to edit Templates in a "user friendly" way? I mean: when I create a new Template, I go to Special:CreateTemplate, and I fill a form. If I want to modify this template, could I go againg to special:CreateTemplate and modify the form instead of editing directly the template? Thanks! --Xtv 13:30, 1 August 2011 (UTC)


 * Unfortunately, no. There's an extension in the works that's intended to take care of this, and related, problems - Page Schemas. It's still in the works, though. Yaron Koren 14:45, 1 August 2011 (UTC)
 * Ok! Thanks anyway! --Xtv 15:24, 1 August 2011 (UTC)

Creating an input form for more than 1 template
Hey all, hope you can help.

I'm developing a Knowledgebase using MediaWiki and SemanticMediaWiki/Semantic Forms - the KB is to store fixes for IT Support problems. As a result, each entry should follow a standard format of having 3 sections called "Symptoms", "Cause" and "Fix". Each of these are defined in 3 separate templates (named fixes, fixes2 and fixes3) and are basically just those 3 words in the Heading 2 style.

I'm trying to create a page whereby a user is presented with 3 textboxes (1 for each template) and saving the page adds whatever text is entered into these textboxes into the appropriate template. For example, the first textbox would be for symptoms - so when the user enters information and the page is saved, it appears within the 'fixes' template/under the heading of Symptoms in the created page.

I think I'm halfway there - I have managed to create the form editing page with the 3 textboxes, however whichever text is entered in the first textbox appears in the area before all templates, the first and second template. So if I enter "HELLO WORLD" into the Symptoms area, "HELLO WORLD2" into the Cause area and "HELLO WORLD3" into the Fix area and save the page, "HELLO WORLD2" appears before the heading "Symptoms", in the Symptoms area and the Cause area, whilst Fix area is left empty.

Here is my code for the page (also, cannot get the 'categories' tag to work - not exactly sure of the function but I'd like the user to be able to choose which category the article belongs to out of the pre-existing ones - I have CategoryTree installed and working).



Fix

 * Hi - it seems like you still have some confusion about forms, and form-definition syntax. There should only be one "free text" input in a form, and it should be outside of any template. The inputs within a "for template" call need to be template fields. Similarly, the "categories" input should be a template field. You need to make use throughout of the " " tag. Yaron Koren 06:52, 5 August 2011 (UTC)


 * Thanks for the reply. So something like " "? Because that doesn't seem to work - it only provides a single-row text entry box whereas I want something more in the style of the freetext area. Also, the information entered doesn't seem to be passed anywhere? I'm reading through the whole documentation now in the hope of understanding it a little better, so sorry if I'm being exceptionally stupid at the moment. Csf90 12:03, 5 August 2011 (UTC+1)


 * You're very close - you just need "input type=textarea", instead of "input type=page". Yaron Koren 14:37, 5 August 2011 (UTC)


 * Excellent, managed to get the right type of input boxes, but no information is being passed to the newly created article from the data entered into them. The new article just had the headings (as defined by the templates). Any ideas? Csf90 09:20, 8 August 2011 (UTC+1)


 * The templates also need to contain, and display, those same fields. Yaron Koren 08:37, 8 August 2011 (UTC)


 * OK, I've been trying to fiddle around but without much luck. This is the code for the first template:

This is the template for Fixes, which adds a table of contents and the first heading of "Symptoms" to each article.


 * This gives funky results when creating an article. Is it tougher because I have three templates that I wish to use in each article? Is there a way to have just 1 and achieve what I want? I've tried looking at example code from Referata Scratchpad but that only seemed to confuse me more. Do I need a Template:Add article (which I don't have) or just the three I do have (Template:Fixes, Template:Fixes2, Template:Fixes3)?


 * For reference, here is a snippet of the (working) Form:Add article code



Symptoms

 * Thanks again, and sorry for the hounding. User:Csf90 11:18, 8 August 2011 (UTC+1)

You're still confusing between forms and templates - templates should not contain form syntax. The page Special:CreateTemplate is the easiest way to make a new template. Yaron Koren 04:21, 9 August 2011 (UTC)


 * OK, I realised I was clearly on the wrong track and start again using the Special Pages (should've done that in the first place). Anyway, I've managed to set it up exactly how I wanted. Thank you for the extension and your help on this page. I do have just two simple questions - is there a way to incorporate WikiEditor 0.2.0 on the Form pages? And if you know, what is the editor that appears at the bottom of this page (that can add tags with the click of a button)? Thanks again! Csf90 15:32, 10 August 2011 (UTC+1)


 * Unfortunately, neither of those can be added to a form - it would be nice if they could, though. Yaron Koren 15:48, 10 August 2011 (UTC)

Wrong display of the datatype "date" with "datetime" input type in tables??
First I created a property called "date", and stated it as a "date" data type (Has type::Date). Afterwards I specified the input type as "datetime" in the corresponding field in the form. Everything works perfect till now.

Then I tried to create a table which inludes a query and one row is the property date. There I have now the following problem. The date is displayed but in front of the day is a number (see example). If I choose listform instead of table then the strange number disappears and the date is displayed correctly.

example: 2455793.520 August 2011 00:00:00 2455761.519 July 2011 00:00:00 2455760.518 July 2011 00:00:00 2455754.512 July 2011 00:00:00 2455753.511 July 2011 00:00:00

I`m sorry for this poor explanation ... but i`m no informatician ;) Thanks very much for your help!


 * Hi - actually, this sounds like a Semantic MediaWiki issue. I would recommend writing to the semediawiki-user mailing list about it. Please mention your versions of MediaWiki, SMW and SF when you do. Yaron Koren 10:32, 5 August 2011 (UTC)


 * Thank you!! I`ll try this suggestion. Greets Sebastian

Problem with date conversions SMW 1.6 with MW1.17
Switching from MW 1.15 with SMW 1.4.3 to 1.17 and 1.6 if one fills a property has type::Date with only a year this functioned correctly interpreting the value as a year but switching to new versions the single value is now interpreted as a unix timestamp leading to all year values to be displayed as seconds offset of Jan 1 1970. Is there a parameter I should set to get back to the correct default behaviour ? Ben Polman


 * Hi - just like with the question above, this sounds like a Semantic MediaWiki issue, rather than a Semantic Forms issue. Yaron Koren 08:08, 8 August 2011 (UTC)

CREATING A DROPDOWN BOX
I apologize if this has been answered, but I didn't find it. So, I copied my forms from an older MW and put them in the new one. My question is this: You will notice that I have a couple of entries like the Stories and Bathrooms, etc. that I would like to be able to have a dropdown selector to display 1, 2, 3, 4. I don't know what kind of code to enter. (E.g.; Bathrooms --- this is a guess but I don't know if it's right. Thanx for your time. --Coffeehound 02:07, 11 August 2011 (UTC)


 * The best approach is to add a semantic property to each such field, and create the property at Special:CreateProperty - there you should specify the set of "allowed values" for it. Yaron Koren 04:37, 11 August 2011 (UTC)


 * So, I am having some trouble here. I created a property for the Stories portion of the form.  It is located http://offgridops.org/foreclosurepedia/index.php/Property:Stories here].  You will note that I added the values in the bottom 1, 2, 3.  I then added input type=combobox as seen in this.  The end result, though, is that the form still only has a blank line to manually enter text.  Perhaps you could simply tell me what I need to define or show me an example somewhere.  Thank you.--Coffeehound 03:35, 13 August 2011 (UTC)


 * You need to add the property to the field in the template. Yaron Koren 05:38, 14 August 2011 (UTC)

Unsupported Type Property Errors
On this page I get an error and when I link to it it goes to a special page. I copied my forms from an old wiki. All I really want it to do is create a page, but regardless I don't really know if I just create a property named after the page title or what. Any help would be appreciated.--Coffeehound 02:09, 11 August 2011 (UTC)


 * You're using the property "Has type" for everything. You should instead have a separate property for each field, like "Has client ID", "Has address", etc. And you definitely shouldn't use "Has type" - it's a special, pre-defined property. Yaron Koren 04:30, 11 August 2011 (UTC)


 * That solved it! I really appreciate your quick response and instructions as well!--Coffeehound 02:37, 13 August 2011 (UTC)

Disable certain forms from appearing in Special:FormStart options
Hello again. I was wondering if it's possible to disable certain forms from showing up in the dropdown list on the Special:FormStart page? Thanks. --Blicarea 03:23, 11 August 2011 (UTC)


 * No. The better approach might be to create your own "form start" page - a normal wiki page with a #forminput for each form you want. Yaron Koren 04:26, 11 August 2011 (UTC)


 * Good idea. Thanks for that.  --Blicarea 11:22, 11 August 2011 (UTC)

Request: Friendlier Edit with Forms
First of all, amazing extension. My request/question is would it be possible to create a more user friendly way to edit text in a form already in existence. For instance maybe graphical boxes whereby one could type in the Form to edit with and then type in the file to edit. The box would make potential suggestions as you typed. The reason for the request is that the non-tech people may be resistant to edit the url. Thank you so very much you are doing important work.

-Brad


 * It's great that you like it. Users shouldn't ever be editing the URL, though - there should be links to forms in the sidebar, and/or form links or #forminput calls in the main page, category pages, etc. Yaron Koren 05:43, 14 August 2011 (UTC)