Extension talk:Page Forms/Archive August to September 2011

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).

{{#forminput:form=Add article|size=40|default value=Article name here...|button text=Create!}}

</noinclude><includeonly>

<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>

== Symptoms ==
{{{for template|Fixes}}}
{| class="formtable"
{{{standard input|free text}}}
|}

{{{end template}}}

== Cause ==
{{{for template|Fixes2}}}
{| class="formtable"
{{{standard input|free text}}}
|}

{{{end template}}}

== Fix ==
{{{for template|Fixes3}}}
{| class="formtable"
{{{standard input|free text}}}
|}
{{{end template}}}


{{#categories:top category=fixes}}


{{{standard input|summary}}}
{{{standard input|minor edit}}} {{{standard input|watch}}}
{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}
</includeonly>

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 "{{{field}}}" tag. Yaron Koren 06:52, 5 August 2011 (UTC)

Thanks for the reply. So something like "{{{field|Fixes|mandatory|size=80|input type=page|rows=6}}}"? 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:

<noinclude>
This is the template for Fixes, which adds a table of contents and the first heading of "Symptoms" to each article.
</noinclude><includeonly>
{| class="wikitable"
! __TOC__
! == Symptoms ==
| {{{field|Symptoms|mandatory|size=80|input type=textarea}}}
|}
</includeonly>

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

{{#forminput:form=Add article|size=40|default value=Article name here...|button text=Create!}}

</noinclude><includeonly>
<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
== Symptoms ==
{{{for template|Fixes}}}
{| class="formtable"
{{{field|Symptoms|mandatory|size=80|input type=textarea}}}
|}

{{{end template}}}

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)

The strange number in the beginning was a bug of a special skin called "fratman_enhanced"; after changing it back to default the problem was solved! 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)

You`ll find a hint for the solution of your problem under the following link: https://bugzilla.wikimedia.org/show_bug.cgi?id=30395 Greets Sebastian

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)

I am still in the dark. Is there someone I could hire to simply change the line for me? I figure one line = $25USD. Perhaps y'all have a list of folks I can go to? I know it is probably simple, but I don't want to waste more of your time as obviously I am not going to catch on here. Thank you for your patience and consideration, by the way! ;)--Coffeehound 13:21, 14 August 2011 (UTC)

I'd suggest going to the mailing list or IRC channel. Yaron Koren 14:35, 14 August 2011 (UTC)

I never could find anyone; however, I figured it out. Probably not the most efficient way I did it, but it worked. In hindsight, I do thank you as you motivated me to learn! ;)--Coffeehound 04:04, 15 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)

Your quick response was amazing and very appreciated. Let me be clearer. Let's say somebody uses a form to write an article. However, later on somebody else wants to edit the same article in the same form layout. How can somebody open the article and the form at the same time and edit the content inside the form? Also is there a way to edit a form that is already in existence in a "semantic" way rather than using the wikiscript? Thank you so much. Your extensions have dramatically changed my wiki, I apologize for my general lack of computer programming knowledge. -Brad

That's great to hear, again. This might be helpful, for what you're asking about. Yaron Koren 23:03, 14 August 2011 (UTC)

Arraymap

Hi, I'm working with the Arraymap parser function.

Currently on SporeWiki, we use the following:

{{#arraymap:1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,127,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152,153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179,180,181,182,183,184,185,186,187,188,189,190,191,192,193,194,195,196,197,198,199,200|,|number|<!--
 Row number -->{{#if:{{{headernumber|}}}|<tr class="{{{classnumber|}}} header"><th colspan="2" style="text-align: center; {{{headerstyle|}}}">{{{headernumber|}}}</th></tr>| {{#if:{{{labelnumber|}}}|{{#if:{{{datanumber|}}}|<tr class="{{{classnumber|}}}"><td style="font-weight: bold; vertical-align: top; {{{labelstyle|}}}">{{{labelnumber|}}}</td><td style="{{{datastyle|}}}">{{{datanumber|}}}</td></tr>}}|  {{#if:{{{datanumber|}}}|<tr class="{{{classnumber|}}}"><td colspan="2" class="{{{classnumber|}}}" style="text-align: center; {{{datastyle|}}}">{{{datanumber|}}}</td></tr>}} }} }}|}}

For our infobox code. However, our Navbox code uses things like:

|groupA1 =
|contentA1 =

So, can #arraymap possibly be used for:

{{#if:{{{nestedA|}}}{{{nestedplainA|}}}|<!--
-->{{Navbox/alt/aux<!--
-->|image meta style={{{style images|}}}<!--
-->|flags=alpha<!--
-->|meta colcount={{#expr:1{{#if:{{{image|}}}|+2}}{{#if:{{{imageleft|}}}|+2}}}}<!--
-->|sideimage2={{{imageleft|}}}|sideimage2 style={{{imageleft style|}}}<!--
-->}}<!--
-->{{#if:{{{nestedA|}}}|{{:{{{nestedA}}}|nested}}|{{{nestedplainA}}}}}<!--
-->|<!--
-->{{Navbox/alt/aux<!--
-->|block={{{blockA|}}}|block meta style={{{style blocks|}}}|block style={{{blockA style|}}}<!--
-->|content member style={{{style contentsA|}}}|content meta style={{{style contents|}}}<!--
-->|content1={{{contentA1|}}}|content1 style={{{contentA1 style|}}}<!--
-->|content2={{{contentA2|}}}|content2 style={{{contentA2 style|}}}<!--
-->|content3={{{contentA3|}}}|content3 style={{{contentA3 style|}}}<!--
-->|content4={{{contentA4|}}}|content4 style={{{contentA4 style|}}}<!--
-->|content5={{{contentA5|}}}|content5 style={{{contentA5 style|}}}<!--
-->|content6={{{contentA6|}}}|content6 style={{{contentA6 style|}}}<!--
-->|content7={{{contentA7|}}}|content7 style={{{contentA7 style|}}}<!--
-->|content8={{{contentA8|}}}|content8 style={{{contentA8 style|}}}<!--
-->|group member style={{{style groupsA|}}}|group meta style={{{style groups|}}}<!--
-->|group1={{{groupA1|}}}|group1 style={{{groupA1 style|}}}<!--
-->|group2={{{groupA2|}}}|group2 style={{{groupA2 style|}}}<!--
-->|group3={{{groupA3|}}}|group3 style={{{groupA3 style|}}}<!--
-->|group4={{{groupA4|}}}|group4 style={{{groupA4 style|}}}<!--
-->|group5={{{groupA5|}}}|group5 style={{{groupA5 style|}}}<!--
-->|group6={{{groupA6|}}}|group6 style={{{groupA6 style|}}}<!--
-->|group7={{{groupA7|}}}|group7 style={{{groupA7 style|}}}<!--
-->|group8={{{groupA8|}}}|group8 style={{{groupA8 style|}}}<!--
-->|header={{{headerA|}}}|header meta style={{{style headers|}}}|header style={{{headerA style|}}}<!--
-->|image meta style={{{style images|}}}<!--
-->|image1={{{imageA|}}}|image1 style={{{imageA style|}}}<!--
-->|image2={{{imageleftA|}}}|image2 style={{{imageleftA style|}}}<!--
-->|member style={{{styleA|}}}|meta style={{{style|}}}<!--
-->|meta options={{{options|}}}|options={{{optionsA|}}}<!--
-->|flags=alpha<!--
-->|meta colcount={{#expr:1{{#if:{{{image|}}}|+2}}{{#if:{{{imageleft|}}}|+2}}}}<!--
-->|sideimage2={{{imageleft|}}}|sideimage2 style={{{imageleft style|}}}<!--
-->}}<!--
-->}}

At all?--Technobliterator 20:21, 17 August 2011 (UTC)

OMG. I have absolutely no idea, but #arraymaptemplate might work better, for your purposes. Yaron Koren 21:33, 17 August 2011 (UTC)

Hahaha, sorry about the mindblowing :P What'd be the syntax for #arraymaptemplate?--Technobliterator 21:36, 17 August 2011 (UTC)

It's described in the extension page - just search for "arraymaptemplate". Yaron Koren 21:43, 17 August 2011 (UTC)

I think I get it. Can two of these parser functions overlap?--Technobliterator 22:09, 17 August 2011 (UTC)

Yeah - you can embed parser functions in one another. Yaron Koren 11:38, 18 August 2011 (UTC)

WYSIWYG Extension

Hi,

is there a plan to integrate the CKeditor via the WYSIWYG extension? This would be really great since the WYSIWYG extension works much better in newer browsers than the FCKeditor extension.

Thanks and greetings --Filburt 11:42, 18 August 2011 (UTC)

Please have a look at ...WYSIWYG Extension, Yaron gave some input on the status of cooperation with the WYSIWYG extension. --MWJames 14:33, 18 August 2011 (UTC)

values={{#arrayprint:MyResults}}

The heading is the example of the concept. It would be great to have parsing attached to values=. Obviously there are limitations, as there are with the parsing related to default=. In particular, I've got properties on several pages, and I want to create a checkbox input that lists the various properties. For that case, I'd do something like

{{#arraydefine:CoAnchors| {{#ask: [[Category:Event Description]] [[Has CoAnchor::~*]]
|?Has CoAnchor=
|link=none
|mainlabel=-
}}
}}
{{#arrayunique:CoAnchors}}
{{#arraysort:CoAnchors|asc}}
Select Your Top 3 Co-Anchors:<br>
{{{field|CoAnchor List|values={{#arrayprint:CoAnchors}}|input type=checkboxes}}}

For those of you who don't want to wait for something more official, the change is easy enough:

Index: ~/extensions/SemanticForms/includes/SF_FormPrinter.php
===================================================================
--- ~/extensions/SemanticForms/includes/SF_FormPrinter.php	(revision 218)
+++ ~/extensions/SemanticForms/includes/SF_FormPrinter.php	(revision 219)
@@ -735,7 +735,8 @@
				$field_args['remote autocompletion'] = true;
			} elseif ( $sub_components[0] == 'values' ) {
				// remove whitespaces, and un-escape characters
-				$possible_values = array_map( 'trim', explode( ',', $sub_components[1] ) );
+				// Make values= use the parser so that arrays can be used
+				$possible_values = array_map( 'trim', explode( ',', $wgParser->recursiveTagParse( $sub_components[1] ) ) );

Keep in mind that my version may be different from yours with respect to line numbers and possibly the source itself.

Incidentally, if there's already a better way to set values like this, please let me know. Thanks. --Skew 07:27, 20 August 2011 (UTC)

Autogrow bug

As previously reported on the mailing list, there seems to be a bug with the autogrow option on text fields. The text fields appear twice as long as necessary in Firefox, and only one line high in Opera. rotsee 12:54, 20 August 2011 (UTC)

(I don't know if the Opera bug has to do with this.) rotsee 13:01, 20 August 2011 (UTC)

Bug reported here https://bugzilla.wikimedia.org/show_bug.cgi?id=30926 Badon 04:41, 16 September 2011 (UTC)

I can confirm this in FF7 as well as IE8. In FF7, I tried activating autogrow on a few fields. This worked as expected when creating new pages; however, upon editing existing pages with moderate amounts of text, the field was out of control. For instance, a field that had about 50 lines of text, the field actually loaded with about 150 rows, 100 of which were empty.    Thorncrag   19:09, 5 October 2011 (UTC)

Prevent regular editing using action=edit

Hello. I am trying to prevent regular editing by means of action=edit while still enabling editing using action=formedit. Is this a possibility? Thanks. --67.171.96.146 00:58, 24 August 2011 (UTC)

No - though you can hide the "action=edit" tab - see here. Yaron Koren 03:31, 24 August 2011 (UTC)

You can probably write an extension to redirect the user using the AlternateEdit hook. It would still be possible to get around it using the API, and possibly other ways as well, though. rotsee 19:23, 26 September 2011 (UTC)

Feature request for partial forms

Using partial forms one can add multiple instances of the same template, which is extremely useful if you need to compile lists and store property values with Semantic Internal Objects. There’s a remove button for every template added, but only one add button right at the bottom. Would it be somehow possible to add an add button – for example under the remove button – so that templates can also be inserted at the appropriate position? I think that would be a very useful feature. Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 09:06, 25 August 2011 (UTC)

There's a request in Bugzilla about this. I'm not planning to add it in currently, because I fear that all those buttons would overwhelm the interface somewhat, and because the majority of wikis don't need it. Still, if someone were to create a patch for it (with a setting so that admins could get rid of the buttons), I would add it in to the code. Yaron Koren 19:43, 25 August 2011 (UTC)

OK, thanks for your answer. I agree that it should be an optional element. I'll see if anything comes up. Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 07:12, 26 August 2011 (UTC)

calling a pop-up form from within another form

Is it possible to use a pop-up form link from within another form? From what I can tell, it doesn't seem as though it's allowed. Would that be a sensible feature? My thinking is that it would be used to add new pages that are related to what is currently being edited or it could be used in lieu of multiple instance templates (when appropriate). Such an approach may be a way to control adding subpages and doing so from the parent page's edit form may be logical place for that to happen.

No, it's not possible; and no, I don't think it would be a sensible feature. A popup from a popup, in any context, sounds to me like a bad idea. Instead, you could have the page, once it was created, contain some form links to make additional pages. Yaron Koren 22:45, 29 August 2011 (UTC)

Yeah, I didn't think of a pop-up from another pop-up. That would be hideous. So if I have form links (using #formlink parser function) from form page, how can I force that to open in new window? I guess at the very least, that is what I'm going after.

Oh, sorry - I don't know why I thought you were talking about a popup from another popup. In any case, I think the solution is to have popup forms from within the page itself - which you can accomplish by adding calls to "#formlink|popup|..." to the relevant template. Yaron Koren 13:29, 30 August 2011 (UTC)

Yeah, that was the route I decided to take. Thanks for your input! Always appreciated.

I am having a bit of trouble

exactly how do i use the '<TemplateName[FieldName]>' tag and get it to work. I am using MW ver 1.16 and SMW Forms version 2.21 The documentation is a little unclear as to what the tag should look like and where it should go Can you help???

What is the name of the field you want to include in the page title, and what's the name of the template it belongs to? Yaron Koren 23:00, 30 August 2011 (UTC)

FieldName = Oragnizations TemplateName = Production:Requirements

thanks for your quick response

In that case, your "page name=" value should include "<Production:Requirements[Organizations]>". (Hopefully a colon in the template name works, by the way - I've never seen that before, so I don't know for sure if it'll work.) Yaron Koren 15:53, 31 August 2011 (UTC)

i will let you know

what i am trying to do is have the Article get in the correct Category when the user creates a new one, eliminating one source of data entry error

Making multiple pages with one form

OK what I am trying to do is make a form that creates some page, but also creates a few sub pages and add a template to those

example: I can make this page without trouble from within a form Creature:<name> But I also want to make Creature:<name>\stats and Creature:<name>\info and maybe more.

So basically I create Creature:<name> and the other will automatically appear.

I have read about every page on the web, but I can not find anything about this. Is this possible?

You can sort of do that, by having the main, newly-created page point to its subpages with semantic properties - and then add a "Creates pages with form" to those properties. That way, the system will generate the subpages automatically. Yaron Koren 16:19, 1 September 2011 (UTC)

Interesting, will give that a go, thanx

getting started moved to example subpage

I found the getting started section no help at all. with no conrete examples, it was not very much help as the section below. so i moved it to the example sub page. Bigbull 02:21, 4 September 2011 (UTC)

Delimiters with commas and spaces

I previously forgot to mention that the latest version of SF appears to have a stricter approach to delimiters for lists of values. While in earlier versions a comma and a space were also accepted as input values, SF now accepts commas only (so the list would look like "1,2,3,4,5" rather than "1, 2, 3, 4, 5", unless a different output is specified using #arraymap). Oddly enough this limitation does not apply to alternative delimiters which may have been chosen in the template (#arraymap...) and in the form (delimiter=..). I may have overlooked things, but is this intended behaviour? Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 17:47, 4 September 2011 (UTC)

No, that's not intended behavior. Would it be possible for you to demonstrate this problem on a public wiki, like http://scratchpad.referata.com ? Yaron Koren 18:00, 4 September 2011 (UTC)

Yes it would, see http://scratchpad.referata.com/wiki/Special:FormEdit/Multiplevalues/Multiplevalues and click on "Show Preview". The following error message occurs after trying to save the page or get a preview: "There were errors with your form input; see below." ==> [field] "must be a valid number". It occurs only when the associated property has been defined as one of type "Number". Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 19:08, 4 September 2011 (UTC) I also left a note on the main page. Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 10:46, 5 September 2011 (UTC)

Any ideas so far? Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 07:51, 11 September 2011 (UTC)

Should this be reported at Bugzilla? Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 14:11, 29 September 2011 (UTC)

https://bugzilla.wikimedia.org/show_bug.cgi?id=31321. Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 09:21, 3 October 2011 (UTC)

Sorry for the lack of responses - I didn't see your last few messages here until now. I'll respond on the Bugzilla page. Yaron Koren 12:07, 3 October 2011 (UTC)

Internet Explorer won't create a page with form (resolved)

Hi again, Yaron. Users of Internet Explorer are not able to create pages using my forms. IE users can edit pages with forms, and they can run queries, but they cannot create pages. When they attempt to save, the page jumps quickly to the top and says in bold red "There were errors with your form input; see below", as if a mandatory field had been left empty. I removed all mandatory properties from my fields for testing purposes, but that didn't work either. I am frantically trying to figure out what's going on, and expect it might have something to do with my autocomplete fields? While bug testing, I am not attempting to add content via any of the multiple instance templates in the form (none of those are mandatory).

Semantic Forms 2.2, MediaWiki 1.17.0. Firefox and Chrome work fine 100% of the time. I'm using IE9.0.8112.16421 on Windows 7. Other users reporting the problem are using unspecified versions of IE. You can see the problem for yourself here: http://www.worlddirectoryofchurches.org/Special:FormEdit/Church/Test_123 Thanks so much for your help.

Hi - it looks like you have a custom Javascript file, "form-church.js" - my hunch is that this might be what's indirectly causing the problem. I would try temporarily removing that, and seeing if that fixes the problem. Scanning briefly through that file, it looks like there are some strange things in there - you have div IDs containing spaces, like "Ruins input", which I don't think is allowed. Yaron Koren 00:32, 7 September 2011 (UTC)

Thanks for the quick response. I removed the custom script and tried again in IE, and you were right. My script is doing something IE doesn't like. It's not a JavaScript error though (the issue you are referring to with IDs is just me calling $("#Ruins input"), selecting inputs inside the div with ID "Ruins"). So there must be some conflict between the way your script calls jQuery and mine does. I quickly swapped all my $'s for "jQuery", to see if that would fix it, but it didn't yet. I'll let you know what the problem is, but thanks for pointing me in the right direction.

It was just a dumb error on my part. I was trying to programmatically create a mandatory field with JavaScript depending on whether or not a checkbox had been checked. The code didn't seem to work for me in Firefox or Chrome, but apparently it was working in IE, essentially creating another mandatory field which my users and I weren't filling in. I had left that code in my script accidentally instead of removing it; thus my problem. Sorry to waste your time! ugh Blicarea 02:19, 7 September 2011 (UTC)

Cool. It's alright - it didn't take more than a few minutes of work on my part... Yaron Koren 02:32, 7 September 2011 (UTC)

Updating semantic templates when type of property changed

Hey,

I got a problem with one of the Semantic Forms templates I used. I changed the type of some of my properties recently, but the form, which uses this template, wasn't updated and shows the same input fields as before. I tried to refresh semantic data, but it doesn't work.

Versions: MediaWiki 1.16.1 PHP 5.3.3 MySQL 5.1.49 Semantic Forms 2.0.8 SemanticMediaWiki 1.5.6

Best regards

Previous comment added by User:137.193.68.236. Please sign your post using four tildes

When you say you "changed the type of some of my properties", you mean the data type (e.g. Page, String, Quantity, Number, etc.), right? I don't see how changing the data type should affect the input fields. Could you elaborate? Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 11:12, 8 September 2011 (UTC)

Yes, I meant the data types, but I got a solution for my problem. It was nothing about data types. The thing was, that the fields in the form were not named like the fields in the template. So the Wiki didn't recognize the right properties for the input fields. So it was my fault:-) Thank you for your answer!!

Glad it's sorted then! Cavila ^{MW 1.17, MySQL 5.1.57, Php 5.2.17} 07:53, 11 September 2011 (UTC)

Uploadable field and KML files

Hi,

I want to enable users to upload a KML file to my wiki via a form field.

I've set my wiki to accept KML files, and they can be uploaded normally into the wiki. But when I try to upload them into a uploadable form field, the interface just won't accept KML. I double click the KML file, and nothing appears in the path field.

Other extensions work fine. Does this happen for anyone else? is this a bug?

Cheers, Jon

selectable list of pages in template

Hi,

I generated a category named "Szenario". "Szenario" has 3 semantic properties and one of them has type "Page". The idea is, that this property can only take on values of another category, called "Prozess". The question now is, whether it is possible to build a inputbox with the list of pages in "Prozess" and insert this box in a template, which defines the category "Szenario".

Best regards...

Ok, I found a solution, which is absolutely acceptable for me. I edited the form "Szenario" and added to the property field the value "autocomplete on category = Prozess". Now the autocomplete function appears when I fill out the template.

"show on select" bugs in "multiple instance templates"

(SF v2.2.1)

I have come across buggy behavior with Semantic Forms. I currently have a "show on select" (dropdown) field within a form used on a multiple instance template. Adding an instance yields expected behavior (ie, when I select a value on the dropdown, my div is no longer hidden). Once I go back to edit, the dropdown has the saved value selected, as expected. However, ALL the div's (not just the one I need to show) are unhidden and the "add another"/"remove" buttons do not work.

If I remove the "multiple" tag from the template, everything seems fine.

Walking through the page in debug mode, I find that the id attributes in the HTML form has already been replaced with origid. The buggy behavior seems to be related to the partOfMultiple variable in SemanticForms.js being set to false. Instead of setting ShowOnSelect values (around line 356 of SemanticForms.js) by looking up origid attribute, it is basing it off of an id attribute that does not exist. Am I correct to assume that if partOfMultiple had been set to true that this would be fine? Where is that variable set? I'm just taking a guess at what may be at the root of the problem here, but I'm not totally sure.

PS, there seems to be an issue with saving edits on referata's scratchpad. Thus I have been unable to recreate this behavior outside of my wiki.

Hi - thanks for trying to replicate this problem on Scratchpad. There was a bug that affected saving on Referata, that has now been fixed - although right now the wiki is hosed, anyway. Once it's working again normally, could you reproduce the issue? Thanks for your patience. Yaron Koren 20:58, 19 September 2011 (UTC)

Okay, I have recreated the issue. It is actually when there are multiple "show on select" fields in a multiple instance template form. See scratchpad example. note that all div's are shown & that "add another/remove" buttons are non-functional expected behavior should be more like that seen on new page creation.

I had a look at your code and found that you set the template for the nested object as the for template value - according to referata nested templates example you are supposed to set the main template's name here:

{{{info|partial form}}}{{{for template|Infobox album}}} <!-- Note the name of the "main" template. -->

This is very confusing as anyone would intuitively set the "sub template" here - to let the system know at some point what template to use. Instead, this is supposed to work with nested templates - and the names of the sub templates and the parameters therein are indicated together like in {{{field|Extra chronology Artist|…}}} (see below) --Achimbode 11:46, 29 September 2011 (UTC)

Thanks for the insight. I see what you are saying, but in the "show on select test" example, I don't believe that there are actual 'nested templates' within the main template. The page would result in something like:

{{TestTemplate | O1=1 | O2=A}}
{{TestTemplate2 | O3=Test001 | Date= 10/04/2011 | End date= 10/04/2011 }}
{{TestTemplate2 | O3=Test002 | Date= 10/04/2011 | End date= 10/04/2011 }}

instead of looking like the following it were to have a 'nested template'

{{TestTemplate | O1=1 | O2=A | TestTemplate2={{TestTemplate2 | O3=Test001 | Date=10/04/2011 | End date=10/04/2011}} }}

It is set up this way in order to create multiple SIO's. I don't believe flattening the template could create multiple SIO instances, correct? Also, this seems to be a bug when 'show on select' is used with a multiple instance (unnested) template.

Hi - it seems like there are at least two issues here. But I just looked into the "show on select" issue on the Referata test form, and it looks like the issue is that the ID "multiday" is being used twice. Re-use of an ID isn't allowed in HTML anyway, and SF can't handle that situation. If you change one of the two IDs, it should hopefully work. Yaron Koren 20:37, 6 October 2011 (UTC)

IE Error in uploadable with multi forms setting SIOs

(SF v2.2.1, too, see topic above)

Hi Yaron, hi Jeroen and all others,

the above is very similar to the multiple form problem with SIOs I was trying to explain to you about on the SMWCon. I love these features, but as said above, it is very difficult to understand the concepts in the beginning. And you will not always want to nest the templates. So the following example should be possible - and it almost works, except for some little issues like uploadable and autocomplete.

On the Form page:

{{{for template|Ergebnisse}}}
... (form inputs for the page)...
{{{end template}}}


<div id="div_sio_block" style="display:{{#if: ... some condition ... |block|none }}"><html><a name="SIO"/></html>
{{{standard input|save}}}
{{{for template|Variante as SIO|multiple|label=SIO Variante}}}
...
|-
! [[Property:MyImage|my image]]: 
| {{#info: ...}}{{{field|myImage|property=myImage|size=102|autocomplete on namespace=File|uploadable}}}
...
{{{end template}}}
</div>

I got the following error:

'parent.document.getElementById(...)' ist Null oder kein Objekt (engl.: is Null or not an Object) on page Special:UploadWindow, line 2

in JavaScript:

     <script type="text/javascript">
		parent.document.getElementById("input_12").value = 'Frangipani Flowers.jpg';
		parent.jQuery.fancybox.close();

HTML: in fact, it only has an origID="input_12", but no id attribute...

<input name="Variante Still eintragen[1a][Ergebnisbild]" tabIndex="11" class="autocompleteInput createboxInput ui-autocomplete-input" role="textbox" aria-haspopup="true" type="text" size="102" autocomplete="off" autocompletesettings="Datei" origID="input_12" jQuery1317280462908="41" aria-autocomplete="list" value="Dock.jpg"/>

In Firefox the whole input field is not shown at all - it is wrapped into a display:none span

<span class="smwttcontent" style="display: none;">

I also tried to set info|partial form, but that did not help either... - of course, as you have to indicate the main template's name (see referata nested templates example). So my suggestion would be to name main and sub templates more explicitely, which might make this great feature more intuitive and less error prone and at the same time allow for other constructs that do not use nested templates -- Achimbode 11:46, 29 September 2011 (UTC)

Read the example page again and found that I have mistaken a suggestion for the official concept of doing it. But still: how does one solve this to avoid the upload errors? Can't find an other JS error on then form page that could explain the behavior... --Achimbode 12:54, 29 September 2011 (UTC)

Multiple property values in a template for a form using Semantic Internal Objects

As noted recently in the semediawiki-users mailing list, using a template to populate Extension:Semantic Internal Objects (SIO) does not directly allow the use of #arraymap: or #arraymaptemplate: to store multiple values for a specific property.

The workaround suggested by Yaron was to use the "list" functionality of SIO. This is not documented on the Extension:Semantic_Forms/Semantic_Forms_and_templates page, so here is an example of how this can work in a template:

 {{#set_internal:ObjectToPageProperty
 |PropertyOne={{{ValueOne|}}}
 |PropertyTwo={{{PropertyTwo|}}}
 |Multi-valueProperty#list={{#arraymap:{{{multi-valueproperty|}}}}}
 }}

The only drawback to this is that the multi-value properties MUST be comma-separated, which is why the arraymap above does not take any parameters (separator defaults to "," and output defaults to the value separated by the separator, in this case {{{multi-valueproperty}}}. If you want commas in your values, use the HTML character entity code for a comma: &#044;

This also appears to work with page-type properties that have commas in their names, as long as you use the HTML character entity code.

If the workaround described above is accurate, I would like to move it to the Extension:Semantic_Forms/Semantic_Forms_and_templates page. Any objections? --Fungiblename 07:52, 21 September 2011 (UTC)

I was struggling with this the other week. Being unsuccessful, I was ready to rearrange my data model or just wait patiently for an update to SIO. I tried the workaround and found that it worked. It would be great to have that in the user manual of the extension. I would also suggest putting it on the SIO page I see that it is already on Extension:Semantic_Internal_Objects#Lists_of_values. Thanks for the tip!

Autocomplete on the main namespace

The documentation says: if you want to autocomplete on the main namespace, just add "values from namespace="

That does not work for me. Instead, I set "values from namespace=main" which works. I think that way is more intuitive as well.

--Tosfos 20:20, 22 September 2011 (UTC)

Thanks - I finally fixed the documentation just now. Yaron Koren 20:14, 6 October 2011 (UTC)

Remote autocompletion with #forminput function?

Am I correct in observing that remote autocompletion functionality is not implemented with the #forminput function? I'm using SF 2.2-alpha and see that autocomplete on category works ok, but I only get a subset of the many pages existing in that category. I can verify that remote autocompletion is working for the fields in the form, since I can watch network traffic being generated, but no such thing occurs for #forminput. --ChrisDavis 14:35, 28 September 2011 (UTC)

Yeah, indeed - that's not implemented. I actually was planning to add that feature in - the fact that you're asking about it will probably speed up that process. Yaron Koren 21:32, 28 September 2011 (UTC)

Flexible values for query form fields

Hi, I am currently switching from SemanticQueryFormTools to Semantic Forms/Creating query forms and wonder if semantic forms has an equivalent to "sask": the following does not work:

{{{field|Name|input type=dropdown|default=+|values from property=Staff|values={{#sask: ?Name|category=Talks | name = namevalue | any=+ | sort=asc }}}}}

I could use "values from property=Name" but

1. how to restrict this to properties inside category Talks
2. how to mix these values with the symbol "+" to match all names? it seems currently not possible to say:

|values from property=Name, values=+

so, maybe I need to learn about concepts? any help would be very much appreciated! Thomas 29 Sep 2011 (16:37)

That's a tough one. Here's a possibility - instead of having a special "+" character to indicate all values, why not just tell the user to leave the field blank if they want to search on all values? If necessary, the template could then turn the "" into a "+" when calling the query (I don't know if that's necessary or not). Yaron Koren 13:14, 3 October 2011 (UTC)