Extension talk:Page Forms/Archive March to May 2010

Forminput size

I'm having a problem with the size argument on #forminput. It does not seem to affect anything on the #forminput inputbox. Running 1.8.8. I'd like to make it 0. so I have just a button that calls the form with Page Forms/Archive March to May 2010 as the default. That way I can have buttons on the page for each infobox template to let the user just click and use the form to edit the properties without ever going into ugly edit mode.

You should use #formlink instead. Yaron Koren 16:19, 1 March 2010 (UTC)

MW Version error (Class HTMLTextField not defined)

In "includes/SF_GlobalFunctions.php" there is the following lines (83-90):

// different upload-window class for MW 1.16+
if (class_exists('HTMLForm')) { // added in MW 1.16
	$wgSpecialPages['UploadWindow'] = 'SFUploadWindow2';
	$wgAutoloadClasses['SFUploadWindow2'] = $sfgIP . '/specials/SF_UploadWindow2.php';
} else {
	$wgSpecialPages['UploadWindow'] = 'SFUploadWindow';
	$wgAutoloadClasses['SFUploadWindow'] = $sfgIP . '/specials/SF_UploadWindow.php';
}

I installed SemanticForms with MediaWiki version 1.15.1. The wiki uses several other extensions too, and it seems (yes, it was unlikely to happen, but it happened) that one of them defines an 'HTMLForm' class... So SemanticForms loaded the upload class designed for MW 1.16 — which leaded to a fatal error, since "HTMLTextField" was not defined.

I propose to rely on MW's "$wgVersion" variable instead of checking for a class definition:

if ( $wgVersion == '1.16' ) {
	$wgSpecialPages['UploadWindow'] = 'SFUploadWindow2';
	$wgAutoloadClasses['SFUploadWindow2'] = $sfgIP . '/specials/SF_UploadWindow2.php';
} else {
	$wgSpecialPages['UploadWindow'] = 'SFUploadWindow';
	$wgAutoloadClasses['SFUploadWindow'] = $sfgIP . '/specials/SF_UploadWindow.php';
}

This worked fine for me (I'll update this post if I find the extension which defines an "HTMLForm" class. Alvinos 13:01, 8 March 2010 (UTC)

I found it! The guilty one is "SpecialDeleteOldRevisions2". To make the old version "SpecialDeleteOldRevisions" compatible with MW > 1.12, they just bundled the old file "HTMLForm.php" with their extension... Pathetic.

Ah, good to know. Unfortunately, checking by MW version is perilous too, because different people use different SVN versions, so there's no direct correspondence between MW versions and whether that class is in there. I could change the code to check for 'HTMLTextField' instead, though... Yaron Koren 15:17, 8 March 2010 (UTC)

I changed it to check for 'HTMLTextField' in version 1.9; hopefully that works better... Yaron Koren 14:19, 11 March 2010 (UTC)

Sub-properties

Hi Yaron and all:

I have a question regarding the use of Sub-properties within SMW (http://semantic-mediawiki.org/wiki/Property:Subproperty_of). I have set up some sub-properties, and I have added them to my template that my form uses.

I dont see the sub properties show up on the form or on my Drill Down. Is this by design? is there anyway to get them to show up? Thanks,

Dave Manzolillo DManzolillo@gmail.com

formlink

I don't know if I am using #formlink the way it was meant to be used, but I had a hard time figuring out how to pass the page name using formlink. I tried default value=page_name, query string=title=page_name and query string=target=page_name. None of those worked.

I ended up using

form_name/page_name (ctrl-click)">{{#formlink:form=form_name/page_name|link text=Edit page_name|link type=button}}

which works, but I don't know if I am using it the way it was meant to be used or if I just tricked it. I'm using 1.9 which uses Special:FormEdit instead of Special:AddData or Special:EditData. Don't know if that makes a difference. I hope my approach will continue to work in future versions.

Specifically I was trying to use it to create a subpage

''form_name''/ (ctrl-click)">{{#formlink:form=''form_name''/{{FULLPAGENAME}}/''subpage_name''|link text=Edit ''subpage_name''|link type=button}}

Dmoorevtedu 14:05, 15 March 2010 (UTC)

Hi - if you know the page name ahead of time, then the best solution is not to use #formlink, but to use this approach. Its advantage (besides the fact that it's not a hack :) ) is that it'll show up as a regular link after the page is created. Yaron Koren 15:16, 15 March 2010 (UTC)

Yes but what if you want to preload data? I have preloading working with Dmoorevtedu's hack, but of course one would have to hide the button/link if the page has already been created. 217.151.109.252 22:41, 17 March 2010 (UTC) (Bob)

Floatbox Not Appearing?

I hope I am missing something obvious and silly here. I have the same behaviour on two different wikis, one at 1.14 and a brand new one at 1.15

Here is my form. If you add a new page, and attempt to upload a photo, you are brought to a new page instead of seeing the Floatbox.

I have no errors in PHP, or apache...not sure where to start here. Has anyone seen this? Thanks!
--John Thomson 01:38, 23 March 2010 (UTC)

I like the domain name. :) The issue is that all the references to CSS and JS files in the source code are incorrect - somehow, $wgScriptPath in LocalSettings.php is being set to "/wiki" instead of "/mw". Yaron Koren 03:56, 23 March 2010 (UTC)

Thanks on both counts, Yaron! I have two wikis on that server, one at "/" (of my Document Root), and the 1.15 instance in "/mw". Both LocalSettings *appear* to have the correct value ("", and "/mw", respectively). Changing the value of $wgScriptPath has catastrophic effects on the rest of the wiki and extensions, of course. My only recourse now is to hack through the code and hard-code the paths to the JS and CSS files, and while that has netted me some improvements, it is still not working properly...my skin "greys out" as though the floatbox is about to appear, then nothing. Unless you have another suggestion? How were you able to determine that $wgScriptPath was set to"/wiki"? Thanks again for the prompt assistance, it is much appreciated! ITM, I will keep futzing...
--John Thomson 12:34, 23 March 2010 (UTC)

Hi - you just have to check the HTML source; any instance of "/wiki" there is probably a mistake. Yaron Koren 14:12, 23 March 2010 (UTC)

I ended up symlinking my root to "wiki" just to get past this, and it worked. Thanks again for your help!
--John Thomson 15:37, 23 March 2010 (UTC)

Hi Yaron, I was just having the same issue and saw this post..it turned out that it somehow added the /wiki path also. All other extensions render the same. I just wanted you to know that it was not an isolated incident. I ended up going in and hard coding the path in SF_Utils --Demetelski 22:38, 3 April 2010 (UTC)

Perhaps you just don't have any other extensions that use $wgScriptPath? The problem definitely isn't coming from Semantic Forms. Yaron Koren 03:18, 4 April 2010 (UTC)

Using Wikilinks In Form Submission

Hi All,

I am having a hard time figuring out what my problem is here...when I add a wikilink like [[Main page]] in a form submission, it tends to hose the previous text in that text area...

--John Thomson 14:57, 27 March 2010 (UTC)

All is well, I eventually found out about this:

$smwgLinksInValues = true;

--John Thomson 15:36, 27 March 2010 (UTC)

Thank you for this tip - I'd the same problem - --Ulli 757 20:42, 28 April 2010 (UTC)

Modifying input type=categories?

Hi..I have placed the array of a category in my form in order for the user to check off which to include in the page. A couple of questions..1) I have the form results set to show as the right-hand box but it does not display the data from the checked off category boxes. I would have though that it would display the checked off categories and then have them as a link in the box? 2) If this is not the case is there another way for users to select multiple categories and have them display? Thanks..Deon

One other issue...I was testing out forms...I created a form Lessons and then deleted it..I then created a form Lesson and now when I click edit with form it keeps taking me back to the Lessons form with the message Error: no form page was found at Lessons even though I created it with the Lesson form. Ideas? Thanks.

Hi - for the first issue: do the category names show up correctly in the page source? If so, you probably just need to fix the #arraymap call in the template. For the second issue: you need to replace "Lessons" with "Lesson" in the category page. Yaron Koren 15:31, 30 March 2010 (UTC)

Hi Yaron, Yes, the category names show up in the source but do not show on the page..here is the code I used {{{field|Categories|input type=categories|top category=Bloom's_Taxonomy|height=200|manadatory}}}

Thanks, Deon

Yes, but what code did you use in the template? That's the issue. 16:58, 30 March 2010 (UTC)

I just added that code to the form under the template..I didn't do it through the create template page because I didn't see a way to set the property for this.

It sounds like you have some misunderstandings about how forms, templates and categories work together. I'd recommend playing around with it more, and reading more of the SF documentation. Yaron Koren 18:30, 30 March 2010 (UTC)'

Ok figured it out and now adds to the categories I want. One question which I am not sure if it can do it because I see that the example form doesn't display it either. Besides the categories being displayed on the bottom can the text of each category show next to the field? On the example page the commas are there but no text. Thanks to anyone. --Demetelski 15:45, 31 March 2010 (UTC)

That's great to hear. Yes, you can have both - in the #arraymap call, instead of just "[[Category::x]]", you should have "[[Category::x]] [[:Category::x]]". Yaron Koren 16:08, 31 March 2010 (UTC)

One question and one issue

Hi,

So first what I think is a bug..In my form if a user tries to create a bullet with the wiki (*) as the first input character it will not show the bullet but the asterisk, but the next line with a bullet will show.

The next question I have is I have 2 templates one is set as the right-side box and the other in the page. I was wondering if I can have the right-side box not automatically take the title of the page but if I can specify it or change code somewhere. I have looked but can't find anything..might have missed it. Thanks --Demetelski 14:40, 3 April 2010 (UTC)

Hi - the first one isn't really a bug; you just need to put that field on the line below whatever's right before it in the template; MediaWiki doesn't recognize an asterisk as a "bullet" unless it's the first thing on the line. For the second issue, look in the right-hand-side template for something that looks like "{{PAGENAME}}", and change that to whatever you want. Yaron Koren 03:16, 4 April 2010 (UTC)

Input type = checkbox, default=checked?

Is it possible to define a checkbox in a form where it defaults to being checked? I tried setting input type=checkbox (which works), but default=checked doesn't seem to work. --Gkullberg 15:20, 5 April 2010 (UTC)

You can do it - it just has to be "default=true" or "default=yes". Yaron Koren 04:43, 6 April 2010 (UTC)

Upgraded to SMW 1.5.0 and SF 1.9, but now setting the default to now on a date-type input literally puts in the word now. Wazzup with that?

No idea - can you reproduce it on a public wiki, like scratchpad.referata.com? Yaron Koren 04:43, 6 April 2010 (UTC)

Autocompletion on Main namespace post-upgrade

I recently upgraded to SF 1.9, and it seems autocompletion for the main namespace isn't working. When I view the source of the form page, I see this:

autocompletestrings['Main,list'] = '' (ctrl-click)">[['']];

I feel like this segment of code should have a list of all the possible values. Automcompletion is working for other namespaces. Is this a known issue? --Gkullberg 18:48, 5 April 2010 (UTC)

Ah, you've found a bug - thanks for the bug report. I just fixed it in SVN, but if you're not using SVN you can fix it on your own side by just looking for the string "main" (quotes included) in the file /includes/SF_FormInputs.inc and changing it to "Main". Yaron Koren

That worked, thanks Yaron. --Gkullberg 20:28, 6 April 2010 (UTC)

Uploadable Feature Fails

With the new SMW and Semantic Forms, using this code:

|-
! Mp3:
| {{{field|3|uploadable|default filename=<page name>.mp3}}}

results in a large text field and no "upload link". This used to work with the old versions...

I can't reproduce this problem - can you reproduce it on a public wiki, like scratchpad.referata.com? Yaron Koren 19:06, 6 April 2010 (UTC)

mandatory fields issue

Hello,

Every time I put "values from concept= or autocomplete on concept=" the mandatory input doesn't work. When saving the warning just flashes quickly and it goes on saving the page. Any idea what I could be doing wrong?

thanks Msevero 02:57, 7 April 2010 (UTC)

What versions of SF and SMW are you using? Yaron Koren 17:13, 7 April 2010 (UTC)

SF 1.9, SMW (Version 1.5.0.a-SVN), MW 1.16.0 beta 1 (monobook skin) Msevero 03:36, 16 April 2010 (UTC)

I can't reproduce this. Could you try to recreate it on a public wiki, like scratchpad.referata.com? Yaron Koren 17:08, 16 April 2010 (UTC)

Hi, I have a similar problem. As soon as I set a default value for a field like e. g. {{{field|Date|default=now|mandatory}}} the form ignores other fields in the same form labelled as mandatory and which are not getting pre-populated with a value. Thus it is possible to save the form without populating the other mandatory fields. In this case I am just getting the warning quickly flashing. As soon as I remove the label mandatory from the field to be the pre-populated all the other mandatory fields are not longer ignored. I am using SMW 1.5.0 and SF r63748 of March 14, 2010 on MW 1.16.0beta2. However I will try to get this reproduced on scratchpad... Cheers --kgh 00:27, 18 April 2010 (UTC)

Hi Yaron, I tried to recreate the problem at scratchpad.referata.com and failed. Since the configuration varies at refarata. Thus I presume that this issue arises with MW 1.16. since it seems to be the only difference between the three of us. Cheers --kgh 10:11, 18 April 2010 (UTC)

Thanks for trying it out on Scratchpad. I copied over your wiki pages to Discourse DB, which uses MW 1.16, but I couldn't replicate it there either - see here. Yaron Koren 03:02, 19 April 2010 (UTC)

Hi Yaron, I have to thank you for trying to recreate this. Hmm..., it was to easy to blame it on 1.16. I will try to track the reason. Stay tuned. Cheers --kgh 09:00, 19 April 2010 (UTC)

Adding Headings in the Form or Template to be posted to the page along with the data

I was wondering if there is a way to post a title/heading above the template form that will get posted to the page along with the data after the user submits the form?

For Example:

Say we have some form that has xyz number of templates associated with it. The user is filling out the forms where the form has titles for each template. The user submits the form and the data gets posted to a new page. On that page is now the data the user field out with the field names in a table form and the title of the template or heading gets appended above the data such as below:

After posting the form to a new page

HEADING

Data: Data: Data: Data:

The goal here is to either somehow post the title of each template above the data of that template on a new page or somehow declare a new title that will be posted in the same way. Does anyone know how to do this or if its even possible? I want to make a formatted professional page that has headings for the data the user posts.

--Neezy 16:19, 7 April 2010 (UTC)

Sorry, I don't think I understood this - can't you just have each template put whatever heading it wants? Yaron Koren 17:14, 7 April 2010 (UTC)

Hmmmm.... Basically, if you take a standard template... It asks for a Template Name, Category, Field Names, Display label, and property, and has the option for aggregation. Well if I fill out a name for the template, a category, and associated fields and save the page. When I add the template to the form it will show the template name when filling out the form, but how do you get it to post it to the article along with the data. This is basically what I am trying to do. --Neezy 16:20, 14 April 2010 (UTC)

Just edit the template to have it display whatever you want. Yaron Koren 18:14, 14 April 2010 (UTC)

Problem with "edit with form"

I get the following error with mediawiki 1.12.0, and SMW 1.4.2 when I click on "edit with form":

Fatal error: Call to private method Xml::expandattributes() from context 'SFFormUtils' in /home/jusylves/bromontpedia/extensions/SemanticForms/includes/SF_FormUtils.inc on line 458

Any advice?

Evidently Xml::expandAttributes(), which was added in the last version of SF, either didn't exist or was a private function in MW 1.12. It seemed a little silly to require MW 1.13 just for this one function, so I just checked in a change to Semantic Forms so that it's no longer required. If you re-get the code from SVN, it should work fine; or you can wait until the next version comes out. Yaron Koren 20:38, 8 April 2010 (UTC)

Thanks for the quick reply. Actually, your use of 'method_exists' doesn't work with php < 5.1! In php 5.0.x, method_exists will return True on private methods. I've tried the following, it seems to work:

SF_FormUtils.inc:457
if ( in_array('expandAttributes', get_class_methods(Xml) ) ) {

I don't know if this is also valid in php 5.1.x.

When using NSFileRepo

When using Semantic Forms 1.8.3 (not sure about other versions) and Extension:NSFileRepo I have noticed that a small modification is needed in the SF_UploadWindow.php file on/around line 422.

- $filtered = preg_replace ( "/[^".Title::legalChars()."]|:/", '-', $filtered );

+ $filtered = preg_replace ( "/[^".Title::legalChars()."]/", '-', $filtered );

If this is not done you will receive and warning message that says that the file was renamed when uploading a file via the upload window. I have found that this message could be confusing to users.

I hope that this helps someone.

--Dgennaro 17:27, 8 April 2010 (UTC)

Form with variable number of fields

I have a template which uses a variable number of arguments, e.g. a0, b0, a1, b1, ..., an, bn, where n can vary from page to page. I want to construct a form with input fields arranged in a table, with a0 and b0 on the first line, and so on. The number of lines will change from page to page. I do not wish to use the page creation feature; pages will be created by a script with a fixed value for the number of arguments, and the form will only be used to modify the values of the a's and b's. Therefore I do not need to consider the case where the form must be updated when n is changed.

I have two questions:

• First, is there a way to pass the number of arguments (n) to the form, so that it uses a loop to produce a table with the correct number of lines?
• Second, assuming that it is possible to pass n to the form, I have been playing with the following code:

 {{{for template|Test Template}}}
 {|
 ! a
 ! b {{
   #vardefine: i | 0
 }}{{
   #while:
  | {{ #ifexpr: {{ #var: i }} < 5 | true }}
  |<nowiki/>
 {{!d}}
 {{!}} {{{field|a{{ #var: i }}|input type=checkbox}}} {{!!}} {{{field|b{{ #var: i }}|input type=text}}} {{ #vardefine: i | {{ #expr: {{ #var: i }} + 1 }} }} }}
 |}
 {{{end template}}}

This doesn't work. Values of the template parameters in the page are not passed to the form. I assume that this is because the conversion a{{ #var: i }} --> a0 is not done before the "field" markup is parsed?

Yeah, there's no way to have a form with a variable number of fields. I'd recommend simplifying the whole setup by using a multiple-instance template instead. Yaron Koren 00:27, 10 April 2010 (UTC)

---

Form Looping

Hey guys just created my first form. Now it was outputting fine with all the info. Now all of a sudden when I hit save page it will go to a 'Start of form' page and states -

"Enter the name of a page here, to be edited with the form "formname". If this page already exists, you will be sent to the form for editing that page. Otherwise, you will be sent to the form for adding the page."

Then when I enter in the page name it will just take me back to my form..? Im not sure if its relationship issue with my properties but his my form

'<div style="margin-top:20px; padding:8px; border: 1px solid #b4d9c9; margin-bottom: 3px; background-color: #d7ede5;">
<font size="3" color="#346851"><b>Create Cemetery Page</b></font><br>
<table border=0 width=100%>
<tr><td width=50% style="text-align:left">
Enter in the name of the Cemetery then hit Create
{{#forminput:form=Cemetery}}

</td>

</tr>

</table>

</div>

</noinclude><includeonly>

<div id="wikiPreview" style="display: none; padding-bottom: 25px; margin-bottom: 25px; border-bottom: 1px solid #AAAAAA;"></div>
{{{for template|Cemetery}}}
{| class="formtable"
! Cemetery Title:
| {{{field|Cemetery Title}}}
|-
! Cemetery Image:
| {{{field|Cemetery Image|uploadable}}} 
|-
! Cemetery Established:
| {{{field|Cemetery Established}}}
|-
! Country:
| {{{field|Country}}}
|-
! Location:
| {{{field|Location}}}
|-
! Coordinates:
| {{{field|Coordinates}}}
|-
! Type:
| {{{field|Type}}}
|-
! Owner:
| {{{field|Owner}}}
|-
! Architect:
| {{{field|Architect}}}
|-
! Architectural style:
| {{{field|Architectural style}}}
|-
! Size:
| {{{field|Size}}}
|-
! Website:
| {{{field|Website}}}
|}
{{{end template}}}

{{{for template|Cemetery Main}}}
{| class="formtable"
! Cemetery History:
| {{{field|Cemetery History}}}
|-
! Cemetery Historical significance:
| {{{field|Cemetery Historical significance}}}
|-
! Cemetery Map:
| {{{field|Cemetery Map}}}
|-
! Cemetery References:
| {{{field|Cemetery References}}}
|-
! Cemetery External links:
| {{{field|Cemetery External links}}}
|}
{{{end template}}}

'''Free text:'''

{{{standard input|free text|rows=10}}}


{{{standard input|summary}}}

{{{standard input|minor edit}}} {{{standard input|watch}}}

{{{standard input|save}}} {{{standard input|preview}}} {{{standard input|changes}}} {{{standard input|cancel}}}

</includeonly>

Thanks guys

Hi, there might just be confusion here around the word "form". In SF terms, the page you copied over isn't a form (even though its name starts with "Form:") - it's a "form definition page". When you actually see the form fields in front of you, that's the "form". Does that clarify the situation, or are you actually having a looping problem? Yaron Koren 13:26, 22 April 2010 (UTC)

Question aout upgrade to 1.9

Hi there - I'm currently running SF 1.8.6, hoping to upgrade to 1.9. Reading the version history notes, I was concerned about the renaming of "AddData" to "FormStart". If my wiki had previously used "AddData" in various links / buttons / code snippets, will I need to find each one and rename change it to "FormStart"? Thanks! LittleKyle 16:37, 23 April 2010 (UTC)

Hi - "AddData" actually changed to "FormEdit" (it was "AddPage" that changed to "FormStart"), but in any case - yes, you'll have to change the string. If it's on your wiki in more than just a handful of places, the Replace Text extension could help. Yaron Koren 16:45, 23 April 2010 (UTC)

&returnto parameter

This is basically a question about a form in a form. I have a setup based on two types of pages, "characters" (e.g. [[免]]) and "glyphs" (e.g. [[免/1]], [[免/2]], ...), the former aggregates the latter glyph pages using #ask queries (real world example). Character pages are also the main entry point for contributers, and I'd like to offer easy access to the form editing of glyph pages. While I can link to the edit form on the "subpage", a submit, once done, will load the glyph page, disrupting the workflow.

I'd be open for suggestions how to do a different take, but currently I believe giving a "returnto" option with the "query_page" attribute of the form pointing back to the aggregating character page might be the easiest solution. I'd try a patch if this would be accepted into the source. Putting a form with "multiple" into the major form doesn't seem feasible as the glyph pages themselves have a fairly complex structure. --Christoph Burgmer 20:40, 27 April 2010 (UTC)

A "returnto" parameter would be great, if it worked... I doubt it could be made to work, without some modifications to MediaWiki itself, but if it could, then yes, I'd gladly add such a patch in to the code. Yaron Koren 21:49, 27 April 2010 (UTC)

I just talked to hhappel and he suggested to go into the hooks and redirect all "glyph" pages, without such a feature though. I'll check my options and report back --Christoph Burgmer 00:05, 28 April 2010 (UTC)

I read through the sources for an hour or so and decided I will go for the quick solution with redirects per hooks. Here's my solution, for it might help others.

* I use subpages for the "glyph" pages, i.e. pages aggregated by a main page.

* I use a hook to do a redirect to the main page:

  $wgHooks['OutputPageBeforeHTML'][] = 'cdbfRedirectMainSubpage';
  
  function cdbfRedirectMainSubpage(&$out, &$text) {
  	$title = $out->getTitle();
  	if ($title->getNamespace() != NS_MAIN) // limit to namespace
  		return true;
  	if (!MWNamespace::hasSubpages($title->getNamespace())) // only if subpages are configured for this namespace (main)
  		return true;
  
  	$parts = explode( '/', $title->getText() ); // fall back to super page
  	$target = $parts[0];
  
  	if ($target != '' and count($parts) > 1) {
  		$targetTitle=Title::newFromText($target);
  		$targetTitle->setFragment($title); // in redirect skip to #anchor with name of the subpage, e.g. 免/2 => 免#免/2
  		$out->redirect($targetTitle->getFullURL(""));
  		return false;
  	}
  	return true;
  }

I think this is clean enough. I would've liked to put a redirect into forms, but it seems I need to go way deeper into the code than I wanted for now. --Christoph Burgmer 09:09, 28 April 2010 (UTC)

Hi, can you explain this code in further detail? And does this have anything to do with forms? Yaron Koren 20:37, 28 April 2010 (UTC)

I just updated the code to use another hook (use diff in case you want to see the old version). Right now I let the redirect happen after the page has been rendered internally. This is to make sure Semantik MediaWiki has time to parse the page's properties. Using the old hook before the page is accessed will lead to properties disappearing from the database. I had to rebuild my index after removing my changes to get everything back.

This code might be special to my usecase, but I believe it is connected to Forms as it solves the problem of editing subpages that only exist due to structural considerations. In my case, from a user point of view, these subpages shouldn't be accessed, but from a design perspective my suppages have multiple relations and this dependencies are, it seems, impossible to code into one page. Long story short: 1 character can have n glyphs, 1 glyph can have m decompositions. These multiple relations are thus distributed over several pages.

With the code above you can effectivly hide subpages from the user as that each access will redirect to the "main" page for the dataset. This is a "returnto" taken to the whole wiki, not only for edit forms. Here any request for a subpage, be it 免/2 or 免/2/some/eaven/further/away will resolve to 免. For my case (and thus in this code here) I limit redirects to the main namespace and only to subpages in the form "page/subpage" if subpages are configured (not default).

If you want to limit the effect to form edits you would probably need to chose another hook (maybe 'ArticleUpdateBeforeRedirect'), but in this case you will have to make sure SemanticMediaWiki still parses changed properties or you loose them from the store as happend to me before. --Christoph Burgmer 21:43, 28 April 2010 (UTC)

I see. By the way, to store those kinds of compound relationships, another (I think easier) approach is to use multiple-instance templates on one page, in conjunction with the Semantic Internal Objects extension. Yaron Koren 05:54, 29 April 2010 (UTC)

Thanks. I'll look into it. I thought that most of the benefits of this extension are gone with records being introduced, but I might be wrong. I'll be happy to put everything in one place if data storage and queries are not affected. --Christoph Burgmer 16:25, 29 April 2010 (UTC)

From what I understand, it doesn't solve the issue of multiple properties in subobjects:

1. character
   1. glyph
      1. decomposition
   2. glyph
      1. decomposition
      2. decomposition

That is, I have subobjects in subobjects, subsubobjects--Christoph Burgmer 17:28, 29 April 2010 (UTC)

Hi - assuming "decomposition" is just a string, you can actually store that using SIO; you just need to specify decomposition as a "list" value. Yaron Koren 03:42, 2 May 2010 (UTC)

Interesting. But would Semantic Forms then allow me to add another glyph and for this add one or more decompositions? How are semantic internal objects processed in forms anyway? --Christoph Burgmer 09:44, 3 May 2010 (UTC)

Yes - you can do that via multiple-instance templates, with "decomposition" as a "list" input. Yaron Koren 12:53, 3 May 2010 (UTC)

Not sure if I understand your last entry. I have the following in Form:Character together with the form for Template:Character:

 {{{for template|Glyph|multiple}}}
 {| class="formtable"
 ! Decomposition: || {{{field|Decompositions}}}
 |}
 {{{end template}}}

The template in questions has the following code:

 {{#set_internal:Glyph3
 |Decompositions#list={{{Decompositions|}}}
 }}

I tried both list and input type=listbox for {{{field|Decompositions}}} but both don't seem to fit your notion above. Am I completely wrong? --Christoph Burgmer 22:05, 6 May 2010 (UTC)

Please be more specific about what's going wrong. Yaron Koren 02:59, 7 May 2010 (UTC)

I have two "classes", Character and Glyph. Both are defined in templates:

 {{Character
 |Radical=
 |CharacterDomain=
 }}

 {{Glyph
 |Decompositions=
 }}

The latter uses SIO (defined in the template instead of the default table placed by SF):

 {{#set_internal:Glyph
 |Decompositions#list={{{Decompositions|}}}
 }}

I want to edit Glyphs in Form:Character:

 {{{for template|Character}}}
 {| class="formtable"
 ! Radical:
 | {{{field|Radical}}}
 |-
 ! CharacterDomain:
 | {{{field|CharacterDomain}}}
 |}
 {{{end template}}}
 
 {{{for template|Glyph|multiple}}}
 {| class="formtable"
 ! Decomposition: || {{{field|Decompositions|list}}}
 |}
 {{{end template}}}

As you mentioned above, I'd like to have "decompositions" as "list" input. For now I only see a normal textinput field. Giving a comma separated list I can already specify several decompositions and query result properly show these in a table instead of a single field. I am missing a way though to provide a more user-friendly way to offer entering of several "decomposition" entries as a "list". I am not sure how this could look but from your words above I asumed there is a way offered by SF. I can post the complete templates on a subpage if needed, just want to keep things clean here. --Christoph Burgmer 07:31, 7 May 2010 (UTC)

I appreciate your efforts to not take up too much space here. :) Do you want autocompletion? Checkboxes? Whatever it is, you need to manually specify it in the form definition. Yaron Koren 14:09, 7 May 2010 (UTC)

Ok, so I believe the input type I prefer doesn't exist yet. I would prefer several text inputs, one for each decomposition and a similar button "add another decomposition" to add another text input, just like what is done for "multiple" on subforms. If this doesn't exist or no similarly appealing input can be used, would a new input type make sense? Autocompletion is not needed, the strings entered are unique (and hence of type "string"). Thanks for not giving up on me :) --Christoph Burgmer 15:56, 7 May 2010 (UTC)

I see - but how is that better than just telling people to separate values with commas? Yaron Koren 19:00, 7 May 2010 (UTC)

From a pure functional point of view I believe there is none, but from a usability pov I'd prefer the latter. --Christoph Burgmer 08:19, 8 May 2010 (UTC)

Your request has been noted - if you want to discuss it further, I'd suggest the mailing list. Yaron Koren 14:00, 9 May 2010 (UTC)

Problems with SVN version of FCKeditor

When using MW 1.16beta and the SVN version of FCKeditor loading a semantic form (with free text field) will produce javascript alerts like Unknown toolbar item "MW_Template" for all the special MW toolbar items which will then not appear. Any ideas what the reason for this behavior could be? Thanks, --Thai 19:39, 28 April 2010 (UTC)

Influence date format

If I have a property of type date and want to edit it with semantic forms (input type=date), in my german mediawiki the template parameter always has the format YYYY/mm/dd (after editing it with semantic forms). This is normally not a problem, since this format is parsed correctly and transformed into a valid date property, but I use the template parameter to display this on the page itself, since in Germany we use the format dd.mm.YYYY. The only workaround I found is using the property within an inline query

({{#ask: [[{{PAGENAME}}]] | ?date = }}

instead of the template parameter, but that workaround leads to problems with the preview (since at that state, the property is not yet overwritten) --92.229.17.49 14:50, 3 May 2010 (UTC)

Show on Select parameter

Hello,

Just upgraded to Semantic Forms 1.9 and having trouble getting 'show on select' to work. Followed the example on Discourse DB but nothing is working correctly. Here is my code that I used:

{|class="formtable"
! Contact:
| {{{field|type|show on select=Contact1=>contact1;Contact2=>contact2}}}
|}

<div id="contact1"> 
{| class="formtable"
! Contact1:
| {{{field|Contact1}}}
|}
</div>

<div id="contact2"> 
{| class="formtable"
! Contact2:
| {{{field|Contact2}}}
|}
</div>

In edit with form, all the fields are shown without having to select anything. There is no option/list to select from the main 'Contact' field. Can't figure out what I'm doing wrong....I'm running Semantic Mediawiki 1.15.1

Is that first input a text input and not, say, a dropdown? If so, that's the problem. Yaron Koren 22:17, 5 May 2010 (UTC)

Found my problem, the property I was using didn't contain any data which resulted with blank fields in my form. Thanks for this excellent extension.

Disabling Wikitext/html in certain fields

Is there a way to disable wikitext in certain fields? For example there are times where some fields will have text that will have an open and closing bracket, and it gets interpreted by wikitext. I just want plain old text with no interpretation of the characters I am using in some of the fields. Is there a way to do this with Semantic Forms? A certain property I should be using? Any help would be great.

--Neezy 12:23, 6 May 2010 (UTC)

Hi - you need to put <nowiki> tags around that field in the template. Although putting them directly in won't work - the parser will parse them too soon. The solution is to turn half of each <nowiki> tag into a template call - so you have something like <now{{2ndHalfOfNowikiTag}}, where the template "2ndHalfOfNowikiTag" holds "iki>". It's a hack, but it should work. Yaron Koren 18:41, 6 May 2010 (UTC)

SForms: Optional "Remove" button

Hi all.

I need to create a wiki page holding a data set with a variable number of lines which can be edited through a semantic form. For that purpose, I'm using the options "partial form" and "multiple" to create the form with some fields.

{{{info|partial form}}}
{{{for template|some_formatting_template|multiple}}}
{| class="formtable" border='1'
! Field1
! Field2
! Field3
|-
! {{{field|f1|input type=checkbox|default=Yes}}} !! {{{field|f2|size=15|mandatory}}} !! {{{field|f3|size=3|mandatory|no autocomplete}}} |}
{{{end template}}}

Then on the page, I need to pipe the whole data set to another template:

{{Aggregation_template|aggregation_input={{some_formatting_template
| f1 = ...
| f2 = ...
| f3 = ...
}}
{{some_formatting_template
| f1 = ...
| f2 = ...
| f3 = ...
}}
}}

For that to work, I need to manually put at least one first "some_formatting_template" in my aggregation template, or else the SF will add the first one and the followings elsewhere in the page.

I can live with that, as I can create my pages that way, but if the user removes all entries with the "Remove" button and saves the page, I'm going to be back with the problem and will have to fix it manually again.

So my questions are:

• Is there a better way to achieve what I want to do?
• or is there a way to simply disable the "Remove" button on a SF when using the option "multiple"?

Thanks! --Mlirette 18:58, 7 May 2010 (UTC)

I'm not that happy with partial forms, for just that reason. I should probably add this to the documentation, but I think most of the time a better solution than a partial form is a "quasi-partial" form - a form that contains all the same templates as the main form, but just leaves out the fields for most of them. Yaron Koren 14:02, 9 May 2010 (UTC)

The example doesn't seem to be working too well.

http://discoursedb.org/w/index.php?title=Picture_IDs_are_perfectly_sensible&action=formedit Tisane 01:41, 10 May 2010 (UTC)

Yikes! Thanks for letting me know about that. It was an SMW-related problem; fixed now. Yaron Koren 03:19, 10 May 2010 (UTC)

SMW Forms for User Pages

I see use of the SMW Forms extension being perfect for giving standardization to the user pages. In my instance I cannot benefit from the Semantic Signup Extension or the CustomUserCreate Extension because I have disabled signup through my wiki, and instead handle it via the parent Wordpress site. I cannot seem to wrap my head around how to apply a template to user pages given that I won't be able to call the hook at user creation, or user login (also primarily don via WP site). Redirect? Any suggestions?

I'd create a form for users, then make that the default form for the "User" namespace. Yaron Koren 16:43, 12 May 2010 (UTC)

positioning of free text

is there a way to modify the positioning of the free text in the final output? I have a use case where I am using multiple templates, some of which I'd like to always have at the end of the page (like category: in MediaWiki does it). But it seems the free text is always everything after the last template, right?

I think if you have the free text input between other templates in the form, that's where it'll show up in the resulting page, too... at least, that's how it's supposed to work. Yaron Koren 13:08, 26 May 2010 (UTC)

Cite and Textfields

I suppose it's not possible to use the cite-extension in a property-field of type text?? If I use it, the content of the text-field dissappears when displaying... :-( --Ulli 757 20:01, 29 May 2010 (UTC)

If that happens, you could always separate the display from the storage - something like "[[Has text::{{{The text}}}| ]] {{{The text}}}". Yaron Koren 00:20, 1 June 2010 (UTC)