Extension talk:Page Forms/Archive May to July 2009

Blank Page on Edit Save After Installation

I installed Semanatic MediaWiki with no extra configuration and waited until the database was finished updating until installing Semantic Forms. Upon my first save of a page edit, the system brought me to a blank page a with the URL:

  http://www.Example.com/index.php?title=TestPage&action=submit

I realized after the fact that certain install requirements regarding name spaces MAY not have been met. I have Extension:SocialProfile installed but didn't think it had any new names paces, but I added the following line to my LocalSettings.php anyway.

  $smwgNamespaceIndex = 150;

Also, I commented out the following line and saving worked for a while.

  include_once('extensions/SemanticForms/includes/SF_Settings.php');

I tried later and now I'm getting more errors like the following line on only some saves.

  Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 1966080 bytes) in /home/example/public_html/sitename/extensions/SemanticMediaWiki/languages/SMW_Messages.php on line 4843

At this point I'm figuring as a first time wiki admin that I might be doing something wrong. I can't find any uninstall features in order to reinstall Semantic Forms if I have to. Any ideas? Thanks ahead of time.

Jephrei 02:03, 3 May 2009 (UTC)

That last message just means that the system ran out of memory; see here for one way to fix it. Yaron Koren 03:55, 4 May 2009 (UTC)

Yeah. i figured that out after i posted. but nope....that fixes the mem but only with semantic forms disabled. I TRIED to disbable both or uninstall completely to reinstall but there's no uninstall documentation. if i comment out the settings in localsettings.php will it be "disabled" or do i have to rollback the database or undo the changes somehow? Also, if i didn't set the custom name space addition lines in localsettings.php before the install and instead added the lines AFTER the install, will SMW and SF work? Jephrei 20:41, 5 May 2009 (UTC)

I found that removing languages that I didn't need from SF_Messages.php solved all my problems.

Pointing red links to 'add data' form also for username in top-right-corner

Would it be possible to enable the feature with pointing red links to the add-data-form also for the userpage-link in the personal toolbar (the link with the small person icon next to it). We would like to see this feature so users who are new to our wiki can simply click on their (red) username and get the form.

I browsed around the code a bit and it seems to me that this link is generated in includes/SkinTemplate.php:buildPersonalUrls() from the data contained in the array userpageUrlDetails, which in turn is filled by a call of the form: makeUrlDetails( $this->userpage ). Further down the call tree the hook for this function seems to be GetLocalUrl, but I guess there will be some filtering necessary to track down this link (or class of links).

Or is there any other way to make the link point to the form?? - LosWochos 08:24, 20 May 2009 (UTC)

You seem to have uncovered a bug - when you click on a user page, if the "User" namespace has been assigned a form, next to the "create" tab there should be an "edit with form" tab (or even better, "create with form"); but it's not there. I've found a fix, that will go into the next version; let's see how it looks after then. Yaron Koren 03:54, 21 May 2009 (UTC)

Uh .. yeah .. right .. this bug seems familiar to me :) I discovered it a few days before, but it didn't seem that important since we have a category defined by the template that is filled with the form and assigning the form to the category works once the user page contains the template call. We're really looking forward to the next version ;) - LosWochos 07:42, 25 May 2009 (UTC)

Problem with the database

While saving the form I'm getting the error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "". MySQL returned error "1146: Table 'wikidb2.test_smw_ws_articles' doesn't exist (localhost)". Retrieved from "http://localhost/mediawiki-1.14.0/index.php/3"

I am using MediaWiki-1.14.0, SMW-1.4.2, Halo-1.4.3, SF-1.6

That's a Halo database table - you should talk to them about it. Yaron Koren 15:19, 22 May 2009 (UTC)

Dynamic dropdown lists

Hi Yaron!

Is there a plan about to extend possibilities of values parameter of {{{field|...}}} parsers? My problem is that I have got a page type based on the next template:

...
[[{{{property name}}}::{{{property value}}}]]
...

In the form I can't filter the values of property values field by allowed values of property:

 ...
 {{{for template|Template}}}
 {|
 ! Property name:
 | {{{field|property name}}}
 |-
 ! Property value:
 | {{{field|property value|values=??? list of allowed values of selected property ???}}}
 |}
 {{{end template}}}

 ... standard inputs ...

I think the solution needs Javascript, but because I'm not a JS magician I was looking for something else:

• values from category needs to create a category (Category:Allowed values of property name), but some properties have String type.
• values from concept needs a concept, but I can't create a concept that lists allowed values of a property (or can I?)
• I can cut create page operation described above in two steps:

1. When I create the new page (with a create page form) than I fill in the property name only and create a link to another form (add property value form).
2. I send the property name in query string of this link to add property value form, but I can't use this value in values parameter of {{{field|...}}} parser.

I think I need something like this:

 
{{{for template|...}}}
{{{field|property value|values={{#show: Property name | ?Allows value }} }}}
{{{end template}}}

Sorry about my bad english and long post, I hope it was understandable (I'm undestanding less and less). Pipi69e 23:19, 24 May 2009 (UTC)

Hi - there's no plan to have Semantic Forms handle the kind of free-form property-addition you're talking about. Yaron Koren 23:45, 24 May 2009 (UTC)

Thank You for your reply, Yaron! Now I'm trying to insert a dropdown to a form with {{#input: type=select|id=...|name=...}} parser function of Extension:Simple_Forms. It puts a select element in HTML source of form with suitable id and name values, but SF doesn't process the selected option. What I'm doing wrong?

Many thanks for your patience :) Pipi69e 10:31, 25 May 2009 (UTC)

Well, I'm not surprised that doesn't work; Semantic Forms only processes those inputs it knows about... I can't think of any solution to your problem, unfortunately. Yaron Koren 20:27, 25 May 2009 (UTC)

Hmmm... I think I must redesign my data model. Many thanks once more! Pipi69e 20:49, 25 May 2009 (UTC)

Feature request: Tool Tips on Form fields

It would be nice to have a possibility to define a tooltip text for form fields so I could give a description what the user should put into that field. F.trott 07:16, 27 May 2009 (UTC)

Hi, this is a very under-documented feature, but you can already do that using SMW's #info function: just add {{#info:My text here}}. Yaron Koren 13:06, 27 May 2009 (UTC)

Probably never meant to be used by anybody outside SMW, hence undocumented, but it blends in really nice with the Look&Feel of SMW and I would go for it. Alas, it does not work inside a form: The inclusion of SMW_tooltip.js is missing in the AddData special page. Could you give me a pointer where I should start hacking? F.trott 14:28, 27 May 2009 (UTC)

Ok, got something figured out for myself. I just changed addJavascriptAndCSS in SF_Utils.inc: Add $smwgScriptPath to the global statement and add
$wgOut->addScript('<script type="text/javascript" src="' . "$smwgScriptPath" . '/skins/SMW_tooltip.js"></script>' . "\n");
near the end. Works like a charm - as long as you don't use autocompletion. With autocompletion you get the info-icon on a new line. Hmm... F.trott 15:19, 27 May 2009 (UTC)

That's strange; I thought I fixed that problem in 1.6 (by making a change like the one you did). What version are you using? Yaron Koren 16:04, 27 May 2009 (UTC)

Still on 1.5.4, sorry. I'll try 1.6 then. Thanks. F.trott 18:17, 27 May 2009 (UTC)

Ok, I installed 1.7.1. The info-function ist available now. I still have the problem, that the info-icon appears on a new line if I use a text field with autocompletion. Do you have suggestions? F.trott 07:41, 3 June 2009 (UTC)

Hm, that's a CSS issue... how about putting the #info call after the the input "label", and before the input itself? Yaron Koren 16:40, 3 June 2009 (UTC)

CSS was a good hint. I just put the input fields in a <span style="float:left;">. Thx. F.trott 08:34, 4 June 2009 (UTC)

ERROR -- YAHOO is 'undefined'

I am receiving an error (YAHOO is 'undefined') when I navigate to any form that I have created within my wiki. I believe that the error has to do with autocomplete, but I do not have any properties that are typed as a 'Page' (in which autocomplete is the default). I do know that you are supposed to be able to add the "no autocomplete" parameter to the field's definition, but this effort was unsuccessful.

I am thinking that the error has something to do with the following piece of code: YAHOO.util.Event.addListener(window, "load", attachAutocompleteToAllDocumentFields); To me this looks like it is making autocomplete the default for all fields and overriding all other efforts.

Someone please give me a clue. I have searched everywhere for an answer.

The problem is coming from the YUI library. Did you modify your value of $sfgYUIBase, by any chance? Yaron Koren 23:47, 5 June 2009 (UTC)

No modifications have been made. Dgennaro 16:31, 8 June 2009 (UTC)

Are you using some special skin? If so, try switching to 'MonoBook' and see if the problem is still there. If not, what version of Semantic Forms are you using? Yaron Koren 17:53, 8 June 2009 (UTC)

Everything is working great now. We have been using the Ionic's Isapi Rewrite Filter and if I don't fully qualify the $sfgYUIBase (/wikiCode/extensions/YUI/build/" the re-write rules were building the url as 'wikiCode/Special:AddData/extensions/YUI/build/yahoo/yahoo-min.js'. If I don't define a fully qualified path for $sfgYUIBase I need to determine a re-write rule. Wolcott 18:06, 8 June 2009 (UTC)

Question/Problem...

MediaWiki 1.14.0 PHP 5.2.9-2 (cgi-fcgi) MySQL 5.1.34-community Semantic MediaWiki (Version 1.4.2) Semantic Forms (Version 1.7.1)

I am having a problem with form parsing. Basically I have a form that Uses the same templates over and over again. For example:

{{{for template|SubSubSection}}}
{| class="formtable" width="100%"
{{SubSubSection|Title={{Functional ui impacts}} }}
|-
| {{{field|Details|input type=textarea|rows=5|cols=100}}}
|}
{{{field|Title|default={{Functional ui impacts}}|hidden}}}
{{{end template}}}

{{{for template|SubSubSection}}}
{| class="formtable" width="100%"
{{SubSubSection|Title={{Functional ud impacts}} }}
|-
| {{{field|Details|input type=textarea|rows=5|cols=100}}}
|}
{{{field|Title|default={{Functional ud impacts}}|hidden}}}
{{{end template}}}

I use this template subsubsection to layout these sections on the final page and classify for TOC. What is happening is that all of my sections/subsections/subsubsections are accounted for on the final page, however only the values given to the final instance of those templates are loaded for all of them. So in this instance the final page will have, given i dont enter anything on for the details field:

{{SubSubSection
|Title={{Functional ud impacts}} 
}}

{{SubSubSection
|Title={{Functional ud impacts}} 
}}

any thoughts besides going back and only allowing a single instance of each template on this form?

67.97.209.36 18:23, 8 June 2009 (UTC)

You can't have a "for template" call more than once for the same template in a form; that seems to be the problem. Yaron Koren 19:09, 8 June 2009 (UTC)

Anyway to add this? or is my only option to create separate templates? 67.97.209.36 20:15, 8 June 2009 (UTC)

I think that's your only option. What's so bad about separate templates? Yaron Koren 23:19, 8 June 2009 (UTC)

The sheer number of them. I think I need to go a different route, this could become unmanagable. 67.97.209.36 13:05, 9 June 2009 (UTC)

My main issue is have this page with mutiples of these sections/subsection/subsubsections, but also scattered around it a few multiple instance templates that i use to build a table on the final page. I could move this all to a single template if i were able to embed mutliple instance templates inside the main template. is that possible? an example below.

{{{for template|UISection}}}
{| class="formtable" width="100%"
{{Section|Title={{Functional ui impacts}} }}
|-
| {{{field|UIDetails|input type=textarea|rows=5|cols=100}}}
|}
{{{field|UITitle|default={{Functional ui impacts}}|hidden}}}
{{{field|docreferencetable|default=
{{{for template|document reference row|multiple|}}}
{| class="formtable" width="100%"
!Name:
| {{{field|name|input type=text|size=100}}}
|-
!Date:
| {{{field|date|input type=date}}}
|-
!Author:
| {{{field|author}}}
|}
{{{end template}}}|hidden}}}
{{{end template}}}

lets say my section template looks like this

{{{UITitle}}}
*{{{UIDetails}}}
{{Docreference header}}
{{{docreferencetable}}}
{{Docreference footer}}

lets say the page created looks like this

{{Section
|UITitle={{Functional ui impacts}}
|UIDetails=Here are some details about the user interface
|docreferencetable=
{{documentreferencerow
|Name=something
|Date=somedate
|Author=someone}}
{{documentreferencerow
|Name=something1
|Date=somedate1
|Author=someone1}}
}}

is this possible?

I don't really understand the example - you want to embed form-definition code in actual pages? In any case, the SF mailing list might be a better venue for this discussion. Yaron Koren 14:25, 9 June 2009 (UTC)

I have added what the page would like created, i hope that helps. 67.97.209.36 14:40, 9 June 2009 (UTC)

I have also sent an email to the users list for assistance.

Apparently I am not the first to want this.

http://groups.google.com/group/semantic-forms/browse_thread/thread/131fbc09a3dd3c55/ccf9bd970c19a093?lnk=gst&q=embed#ccf9bd970c19a093

67.97.209.36 15:36, 9 June 2009 (UTC)

Don't know if this is any help, but you could create a dedicated page for each of your documentreferencerows (or whatever you want to include more than once) and then in the UISection template do an {{#ask}} for all documentreferencerows pertaining to that UISection. Of course for that every documentreferencerow would have to know its UISection ({{Has UISection::foo}}).

Or - if you want to push it a bit further - you could create pages for the documents (with name, date, author) and pages for the references (with "Has UISection", "Has document"). Thus you could reuse the documents for different UISections. Might save some effort on maintainance when a referenced document changes. F.trott 06:55, 10 June 2009 (UTC)

I am not sure i understand how i could create pages for these items separately. My understanding is a single form can only create a single page. these are items that are entered by a user, they are to be presented as table rows. The idea here is a single form, it is actually presented the same as our existing word doc that it used for documentation. I am actually figured out how using templates i could build this into a single template call in the resulting page, problem is with the new parser in media wiki you cannot build a template call from other templates, the result of the templates ends up being a literal string.97.100.99.167 11:45, 12 June 2009 (UTC)

Alas, you would not be able to do it all with one form. Instead you would have to first create the list of sections, then fill one form for each documentreferencerow. F.trott 22:47, 13 June 2009 (UTC)

Periods not used in automatic pagenames

I have a form, where the page name of the created page is derived from a text field. Alas, periods are not used and replaced by whitespaces instead. Is this a known problem? Or even a feature? :) Is there a known work around? F.trott 14:27, 19 May 2009 (UTC)

Any Suggestions on this? F.trott 15:02, 9 June 2009 (UTC)

Have you tried using the urlencode template? m:Help:Parser function#URLENCODE 67.97.209.36 15:09, 9 June 2009 (UTC)

Leads to closing curly braces appearing in the form and an infinite loop when I try to save the form. Since other characters are no problem (e.g. parantheses, ampersands, etc.) I do not think it's an encoding problem. I believe only the period gets replaced somewhere. F.trott 05:11, 10 June 2009 (UTC)

Ok, found the responsible str_replace in SF_FormPrinter.inc and just commented it out. Everything seems fine. Question is: The replace was put there explicitly. Why though? Did I just open a new problem? F.trott 06:07, 10 June 2009 (UTC)

Hi, sorry for not responding before. Yes, I've seen that same str_replace(), and the thing is, I can't remember in the least why it's there. I'll try to figure it out, although I might take out that line anyway. I'm glad it worked for you. Yaron Koren 19:10, 10 June 2009 (UTC)

No problem. I'll report if I encounter any problems. F.trott 11:41, 11 June 2009 (UTC)

Illegal mix of collations

We installed SMW and Sematic Forms on MediaWiki 1.11.1. Installation went fine but when we attempted to use Special:CreateTemplate we received the following error:

Database error

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "SMW::getUnusedPropertySubjects". MySQL returned error "1267: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_bin,IMPLICIT) for operation '=' (***.***.com)".

I found bug 14931 which sounded related.

Our database was latin1 so we locked down MediaWiki ( $wgReadOnly = "..."; in LocalSettings.php) and connected to mysql and submitted

alter database wikidb CHARACTER SET latin1 COLLATE latin1_bin;

then unlocked. This resolved the problem for us. --DavidBiesack 16:17, 12 June 2009 (UTC)

CAPTCHA

Is there anyway to get a CAPTCHA embedded in the form? I have recently been targeted by spammers and need to add a layer of prevention. I am using the ConfirmEdit extension, but it sends users from the form page to the normal edit page.

SMF run as previous process, ConfirmEdit is executed when you try to "save" the document, it is possible to modify some options but all they are after submitting the form. Neoshinji 11:12, 24 June 2009 (UTC)

includeonly free text has side effects

"includeonly free text" does what is advertised: It places all template calls generated by the form within a "<noinclude>" tag. Alas ist also places the remaining text within "<includeonly>" with the effect that that text is not displayed on the original page anymore. I think the "<includeonly>" is unnecessary and could be removed. (Alternatively it could be replaced by "<onlyinclude">, making the "<noinclude>" unnecessary.) F.trott 14:54, 15 June 2009 (UTC)

Very interesting - I wasn't even aware of the "onlyinclude" tag until you mentioned it just now. That seems like an ideal solution for this feature - though it might mean that the SF parameter's name will have to change. :) Yaron Koren 01:21, 16 June 2009 (UTC)

F.Trott it is possible to need in some strange cases to use the includeonly for this purposes, if you to want to see a real case, please check the Mediawiki Support Desk (concretly the links generated when you post a new question), then I am sure you will understand why it is important this feature. ;) Neoshinji 11:05, 24 June 2009 (UTC)

I'm not sure that I understand what you mean. Mediawiki.org does not use semantic forms. F.trott 14:06, 24 June 2009 (UTC)

Okay, "includeonly free text" is now "onlyinclude free text" (though the old name still works), and it uses the "onlyinclude" tag, which definitely works better. Thanks for the suggestion. Yaron Koren 16:06, 26 June 2009 (UTC)

"uploadable" does not work with forced uploads

The "uploadable"-Option does not work when I try to upload a file with a bad file type (e.g. MSWord).

My wiki is set to allow forced uploads (i.e. issue a warning about a bad file type and allow to upload anyway). When I try uploading a file the warning is issued, the file uploaded, but I have to explicitly close the javascript window and the filename is not copied into the text field. F.trott 13:56, 24 June 2009 (UTC)

Yeah, that's a tough one... I don't know if there's a way around the problem, but thanks for the reminder. Yaron Koren 16:41, 24 June 2009 (UTC)

Have fun. ;-) I just switched off the file extension check. It's a risk, but a minor one - my wiki is in an intranet with a fairly small (hopefully not malicious) user group. Btw, is there a way to change the appearance of the upload page? F.trott 18:50, 24 June 2009 (UTC)

There hasn't been one recently, no... Yaron Koren 19:27, 24 June 2009 (UTC)

Ok, doesn't matter. Thx. F.trott

Oh, oops, I misread your question. The real answer is that you can make various CSS changes, through the MediaWiki:Common.css file. You could try adding "form#upload {background: gray}", for example. Yaron Koren 13:36, 28 June 2009 (UTC)

I'll try that. Thanks. F.trott 05:12, 29 June 2009 (UTC)

Hiding "view form"

I'd really like to be able to disable "view form" but I'm not quite sure where to do this. Any direction on this? Thanks! --Bsmithme 21:52, 27 June 2009 (UTC)

There's no way to do that. Why do you want to? Yaron Koren 13:24, 28 June 2009 (UTC)

In our setting we have no need to display "view form" to users who don't have access to the article. We are trying to trim down and clean up the pages so that it contains as few un-needed distractions as possible. --Bsmithme 17:55, 28 June 2009 (UTC)

Well, do you have, say, the "View source" or "History" tabs removed? If so, how? Yaron Koren 20:58, 28 June 2009 (UTC)

I have those removed using the CSS option and using the extension Dynamic Tabs. None of them apply to Semantic Forms, however, since it is independent. --Bsmithme 00:04, 1 July 2009 (UTC)

So Dynamic Tabs doesn't work on "formedit" when you try it? It seems like it might, but I wouldn't know. Yaron Koren 03:29, 1 July 2009 (UTC)

That's correct, DynamicTabs isn't setup to handle semantic forms tab (to my knowledge, there is no documentation). I am not that great with PHP code, but I think that if I modify (maybe comment-out) content on line 66+ of SF_FormEditTab.php I think it should be possible to eliminate "View Form"... But I am just not sure. --Bsmithme 21:05, 1 July 2009 (UTC)

Not to belabor the point, but just to clarify - did you try DynamicTabs with a "formedit" setting? Yaron Koren 21:21, 1 July 2009 (UTC)

Indeed I just rechecked and I do have "formedit" and also have "viewform" "viewsource" and even "edit" just to see if it would work, but "view form" still appears. --Bsmithme 23:08, 1 July 2009 (UTC)

Category Input Type: No tree displayed

Problem I created a template and a form based on DiscourseDB When I create a page using the form, I get a text box rather than the category tree selection displayed on DiscourseDB. Does Input type=category need to be enabled, or have I gone wrong somewhere?

My Versions The versions installed on my wiki are:

• MediaWiki (1.13.2)
• PHP (5.2.6)
• MySQL (5.0.24)
• Special pages
  • CategoryTree (Version r37574)
  • Replace Text (Version 0.3)
  • Semantic Forms (Version 1.3.8)
  • SphinxSearch (Version 0.6.1) Not working properly
• Parser Hooks
  • CategoryTree (Version r37574)
  • ParserFunctions (Version 1.1.1)
  • Semantic MediaWiki (Version 1.4.0)

Template:CategorySelect

<noinclude>
This is the 'CategorySelect' template.
It should be called in the following format:
<pre>
{{CategorySelect
|Category=
}}
</pre>
Edit the page to see the template text.
</noinclude><includeonly>
{| class="wikitable"
! 
| [[Category:{{{Category|}}}]]
|}
</includeonly>

Form:CategorySelect

<noinclude>
This is the 'CategorySelect' form.
To add a page with this form, enter the page name below;
if a page with that name already exists, you will be sent to a form to edit that page.

{{#forminput:CategorySelect}}

</noinclude><includeonly>
{{{for template|CategorySelect}}}
'''Category:'''

{{{field|Category|input type=category|top category=Systems|height=200}}}
{{{end template}}}

</includeonly>

This feature would be very helpful for what I am trying to accomplish.

Thanks!

Well, I certainly can't fault you for not giving enough information. :) You have an old version of Semantic Forms - if you upgrade, it should work. Yaron Koren 22:15, 30 June 2009 (UTC)

That was it. Thanks so much for the tip. The semantic extensions are powerful & elegant.

Forms terminate template calls with newlines

Form-created pages contain one template call per "for template". These template calls are terminates by newline characters. While this leads to good readability of the resulting page the newlines introduce unintended vertical space.

Example: I have a template that only sets an attribute ("document reference") without any resulting text. I use that with "multiple". This results in vertical spaces that get larger the more times I use the template, i.e. the more references I attach. F.trott 08:36, 2 July 2009 (UTC)

Hi, sorry, I can't reproduce that problem - would it be possible for you to try to reproduce it on scratchpad.referata.com? Yaron Koren 03:10, 9 July 2009 (UTC)

Done. You now have the following pages: Form:FtItem, Template:FtItem/Head, Template:FtItem/Head/Personnel, Template:FtItem/Head/Reference, Template:FtItem/Body, FtTestItem. The more personnel or references you add, the larger the space in the resulting page between the Head and the free text (the lorem ipsum in the example) becomes. (Sorry for keeping you waiting, was on holiday.) F.trott 13:11, 20 July 2009 (UTC)

Just found a workaround: Including a <nowiki/> at the very end of the template "hides" the newline from the wiki parser so it does not insert empty paragraphs. I implemented the workaround on the scratchpad in Template:FtItem/Head/Personnel, left Template:FtItem/Head/Reference alone, so you can compare. F.trott 09:24, 22 July 2009 (UTC)

Okay, I see the issue, thanks: the problem comes when you have a template containing only "silent" property settings. It's good that you found a workaround; that would be a good "tip" to add in the SMW Community Wiki... Yaron Koren 16:22, 23 July 2009 (UTC)

Done: [1] Maybe check and edit as necessary. Thanks. F.trott 15:25, 24 July 2009 (UTC)

Case sensitivity for: field|autocomplete on category=category name

Whether this is a bug or just an omission in the documentation, users should be aware that for the various parameters of the field tag following the format:

• autocomplete on category = Category name
• values from category = Category name

The Category name must be capitalized. i.e. category = boats does not work but category = Boats does work

I can only assume the same applies to property = Property name and namespace = Namespace name

• sane "sensitivity" noted for filters used in SMW queries.

Najevi 23:11, 7 July 2009 (UTC)

I suppose that's a bug - there's no reason why lowercasing the first letter should fail. Yaron Koren 15:03, 8 July 2009 (UTC)

#arraymap: parser function does not translate \n to a newline character

Section Multiple values for the same field states that #arraymap will treat \n in either delimiter field as a newline character. Test the following at a wiki with the Semantic Forms extension installed.

The markup

{{#arraymap:abc,def,123,xyz|,|x|x|\n}}

Renders as

{{#arraymap:abc,def,123,xyz|,|x|x|\n}}

Although not able to be demonstrated at this talk page, clearly, the newline substitution is not taking place. For a suitable solution see: Delimiting and #arraymap: with a newline Najevi 12:27, 8 July 2009 (UTC)

It works for me - what does it look like for you? Yaron Koren 15:03, 8 July 2009 (UTC)

It renders \n as a literal string. viz.

abc\ndef\n123\nxyz

You can see this demonstrated at http://vsk.wikia.com/wiki/User:Najevi/arraymap Najevi 06:00, 19 July 2009 (UTC)

Ah, I see - you're using an old version of Semantic Forms (see here). Try to get them to upgrade, if possible. Yaron Koren 14:10, 19 July 2009 (UTC)

I came across that version history while searching the SF mailing list yesterday and realized that support \n first appeared in v1.7 while my wiki host is at v1.5.1 ... Mystery solved! By the way I don't think I'd have been able to find that information at the SourceForge mailing list archives. Najevi 00:02, 20 July 2009 (UTC)

You can see the version history here. Yaron Koren 00:39, 20 July 2009 (UTC)

Custom output format for date/time inputs

It would be nice if the format in which the value from a date/time input field is entered into the template call could be customized. The current YYYY/MM/DD is for example very confusing when mixed with DD.MM.YYYY dates. I guess it should be no big problem since Semantic Mediawiki seems to understand many different input formats. Maybe the best would be to somehow use the Locale. - LosWochos 08:22, 14 July 2009 (UTC)

Well, you can already customize it by adding "$wgAmericanDates = true" to your LocalSettings.php... Yaron Koren 13:09, 14 July 2009 (UTC)

Using SF for Talk Pages

Any thoughts on this? Seems like a bad idea, but the idea has its merits, I think. --Bsmithme 01:21, 15 July 2009 (UTC)

I wouldn't recommend it - if the aim is just to provide more structure for discussions, there are already extensions, like LiquidThreads, that do that. Yaron Koren 19:59, 15 July 2009 (UTC)

Saves taking too long

I have a bit of a problem with Semantic Forms. When I edit and then save a page using a form, the save hangs for about 4-5 seconds while showing the little circular status thing (i.e. the circular thing that goes round and round -- I don't know what to call it). The circular stautus thing hangs (i.e. stops spinning) for 4-5 seconds, on a white background, and then the save completes. When I switch SF off, the page can be edited and saved really quickly. Any ideas? MW 1.13.5, PHP 5.2.10, MySQL 5.0.41, SMW 1.4.2, SF 1.7.3, HeaderTabs 0.6.4. - Borofkin 06:27, 22 July 2009 (UTC)

I understand what you're saying, although the comparison you're providing is somewhat odd - saving a form with SF, versus saving a regular page without it. :) Are regular page saves slower too when SF is installed? In any case - try removing all the language values from the SF_Messages.php file, other than English (assuming you're using English). That's obviously not a good general solution, but I have a hunch that that enormous file causes a big slowdown for some people. Yaron Koren 19:46, 22 July 2009 (UTC)

Hi Yaron... The "hang" occurs on pages with forms, but not pages without forms. I've removed all other languages and there is no change in the behaviour. - Borofkin 01:31, 23 July 2009 (UTC)

Confusing concepts

• Please accept the following in the same spirit of constructive criticism with which it was thoughtfully prepared.

I first started reading about SMW and SF around May 2008. It was dry reading then, it was confusing then. I had an urgent task in mind and despite well-meaning advocates of SMW/SF urging me to use those "better" tools I chose not to because it seemed so gratuitously complex and different than the well understood and well documented templates that MediaWiki provides. So I shelved the idea of using SMW/SF back in May, 2008 and completed the task using (albeit) complex template calls instead.

So when I comment that the article in it's present form is confusing please understand that this reaction is coming from the perspective of a reader who was tardy to migrate to SMW/SF specifically because the documentation of various concepts did not successfully communicate certain key messages in a time efficient manner. I imagine that one of the goals of this wiki article is to enable a more rapid uptake of SMW and especially the SF extension than this one reader suffered.

It may be that Yaron is still in the process of reviewing a number of edits I recently made. I fully expected some degree of editorial veto - after all that is a developer's prerogative. Having just now reviewed the comparison of the two versions here I am prompted to mention below those major points of confusion that the article in it's present form has caused for me.

Terminology consistent with MediaWiki help pages

• A form has fields. A template has parameters. Those template parameters are either numbered parameters or named parameters. By it's very section title, Extension:Semantic_Forms#Defining_forms purports to explain how to define a semantic form which happens to have one or more elements that are described as fields. It is needlessly confusing to read about "template fields" in this section or anywhere else in the article. (Maybe "field" was a term that was once associated with MediaWiki templates but it is not consistent with contemporary help pages on the subject of templates.)
• Data can be added to a page. A page can be added to a wiki. However within the existing MediaWiki documentation that second action is more commonly (and I think more clearly) described as:

  A page can be created at a wiki.

• Pages at a wiki can be edited. Data on a page can be edited. It is unfortunate that the same verb suits both purposes and sometimes the english language does that to us. The reader is left to read, play, reread, experiment some more, etc. to eventually come to an understanding of any subtle difference. The editing of data on a page via a form sometimes involves adding data to empty form fields and sometimes involves changing data found in already populated form fields. Therefore to clarify the subtle difference I would suggest that:

  Data on page can be changed. ... and to effect that change ... A page at a wiki can be edited.

• A user presently interfacing with a form is the current user. A user that is creating a page for the first time (albeit using a form) is the page creator.

These four bullets may come across like some petty disagreement over semantics (sic!) however I will simply say that use of the following terminology lead to sufficient confusion on behalf of this one reader that I turned my back on the tool for nearly 12 months before resolving to persevere.

1. "field" for both templates and forms
   • try "template parameter" instead of "template field"
2. "edit" for both data and pages
   • with respect to data, try "change" instead of "edit"
3. "add" for both pages and data
   • with respect to pages, try "create" instead of "add"
4. "current user" when "page creator" was intended

I wonder how many others before me reacted in a similar way but did not bother to provide feedback?

That moment of revelation

My final piece of major feedback has to do with that revelation or "a-ha!" moment that each of us inevitably must experience when studying something new or different. Of course this is different for each individual. I imagine that one goal of user review of an article such as this is to reduce the median time to revelation for newcomers to the subject.

The verbose introduction suggested for Extension:Semantic_Forms#Defining_forms (and reproduced below) was the "a-ha!" moment for me in my coming to understand how SF actually works. I concede that this fundamental concept is subtly alluded to in the Description section. If a user has the time and patience to read, experiment and then reread (and the tenacity to maybe repeat this for several days as I needed to) then eventually that moment of revelation will come. Within this introduction to SF, if some degree of repetition for the sake of emphasis can save newcomers undue delay in getting to that moment of revelation then I think it is worthwhile repetition. viz.

An important concept mentioned in the Description and re-emphasized here is that the Semantic Forms extension enforces the use of templates for creating and editing semantic data. It is not compatible with direct semantic markup in data pages. Nor does it support any manipulation of semantic data within a template that is called from a data page. Each template is expected to perform straight forward semantic annotations and indeed, if the Create a template form provided for that task gets used then that is exactly what will be produced.

• Each user-defined form should be thought of as a graphical user interface designed to allow any user (even one having no knowledge of wiki markup code) to efficiently populate a pre-defined set of template calls with required (and optional) values corresponding to named parameters expected by each template.

Therefore, when this section mentions preserve values or edit values that concept is really referring to data stored on the page as values assigned to named parameters in one (or more) template call(s) and does not refer to values stored as semantic data per se. If the stored semantic data is directly manipulated by some other template on the same data page or by direct semantic markup within the same data page or by any other method; then the user-defined form will disregard those changes.

When a form's Save page button is clicked those one (or more) template call(s) are evaluated just as they would be if the user had been editing the page source markup code and clicked save page. If mandatory data is missing or if the expected data type or value is other than what is is expected then the form does not allow the page to be saved and will direct the user to any form field(s) requiring user attention.

Finer points

I hope the various minor clarifying points suggested within those subsections describing the "form markup language" will be reviewed once again at that time when either a table view or maybe a traditional Bachus-Naur form description of syntax is adopted.

Finally, thank you Yaron for a great tool and also for your patient responses to my questions both in the IRC channel #semanticmediawiki as well as on the semediawiki-user mailing list.

-Najevi 19:01, 22 July 2009 (UTC)

Well, thanks for the feedback, but no need for the dramatics - maybe there are people using SF now who wouldn't have used it had the documentation been another way? There's no way to know. Anyway, I reverted your changes because I agreed with some of them and disagreed with others, and it seemed like there were too many to try to sort them all out. As to your suggestions: changing template "fields" to template "parameters" sounds like a good idea, as does talking about creating pages instead of adding pages; maybe even the 'AddPage' special page should be renamed at some point. For "current user" vs. "page creator" - they mean the same thing, given that the default only applies when creating a page; and I think "current user" sounds a little more obvious. Also, I prefer "edit data" over "change data" because I think it makes it clearer that it's being done manually, through a form. Yaron Koren 20:33, 22 July 2009 (UTC)

I don't think this is too dramatic. I can honestly relate to the problems described here to my own experience coming to SMW. Now that I am comfortable with the concepts, I don't really see why it took me so long - there isn't really that much to learn, but I do remember battling with the docs on more than one occasion. --Dmb 23:20, 24 July 2009 (UTC)

Any way to include forms inside forms ?

Hello. I have a wiki that has a lot of character sheets (about 300). All these sheets are managed with a "character" template that could be simplified as somthing like that

 {{Character
  |name=
  |voice_actor1=
  |voice_actor_age1=
  |voice_actor2=
  |voice_actor_age2=
  |voice_actor3=
  |voice_actor_age3=
  |history title1=
  |history desc1=
  |history title2=
  |history desc2=
  |history title3=
  |history desc3=
  |various details=
  |features list name1=
  |features list description1=
  |features list name2=
  |features list description2=
  |features list name3=
  |features list description3=
  |other_stuff=
  }}

That single template is useful to order the elemnts in the page and if switching elements is needed because of a design change, it is very quick to update all the 300 pages.

In SF I was using a set number or fields to handle parameters that should have multiple values, like the voice actor part. The voice_actor1 and voice_actor_age1 bacome actually be 2 parameters of a template so the Character template actually has a number of fields like

 {{VoiceActor|voice_actor1|voice_actor_age1}}
  {{VoiceActor|voice_actor2|voice_actor_age2}}

Obviously, that method is not clean because you have to define beforehand enough 'false multiple fields' in your template and your form. Also, things like that can't be handled by the current 'allow multiple values' option of SF since it only takes values one by one, not as couples.

I tried to include a multiple instance form template inside an another form template like in the example behind, but such a thing completely fails. I was kinda hoping that the nested form would generate the template elements tags ({{VoiceActor|voice_actor1|voice_actor_age1}} {{VoiceActor|voice_actor2|voice_actor_age2}} )and then assign that string to the voiceAct field that would replace the set of predfinied isntances in the Character template.

 {{{for template|Character}}}
  '''ActorField:''' {{{field|voiceAct|
  
  {{{for template|VoiceActor|multiple}}}
  '''actor:''' {{{field|1}}}
  
  '''age''' {{{field|2}}}
  
  {{{end template}}}
  
  }}}

  {{{end template}}}

Right now the only possibility seems to split the Character template in 5 parts, actually evertime there is a multiple instance emplate to include. That solution is not good at all, because first it would be painful to migrate all the pages to a new "split" version, and then the positioning of elemnts in a page would be decided by the form. If we need to change the sections order later it would mean editing every page, and possibly rework again all the split template parts.

Nested tempaltes would probably require a lot of changes in the parsing algorithm so at least a way to decide the positioning of multiple instance forms would be nice. for example we could have something like this:

 {{{for template|Character}}}
'''ActorField:''' {{{field|voiceAct|value_from_form=voiceActorForm}}}

{{{end template}}}


{{{for template|VoiceActor|multiple|nameForInclusion=voiceActorForm}}}
'''actor:''' {{{field|1}}}

'''age''' {{{field|2}}}

{{{end template}}}

The multiple templates generated result would be put as a string in the ActorField according to the relation created with the value_from_form and nameForInclusion parameters.

I'm not sure, if I understood your problem correctly, so apologies if not. Anyway, you seem to have two problems.

• multiple values in one attribute: Maybe this helps you sorting out the problem: Help:Many-valued properties on semantic-mediawiki.org

• Separation of data and view: I solve that problem by using separate templates for setting the attributes and for displaying the data. The templates for setting attributes do just that and nothing else. (But see Extension_talk:Semantic_Forms#Forms_terminate_template_calls_with_newlines above for problems and workaround with that approach.) The templates for the displaying of the data take no further parameters from the form but gets all the necessary data by queries ({{#ask:...}}). Only thing to consider: You need two templates for displaying: One for content displayed above the free text (e.g. Headerdata), one for below (e.g. the articles body).

For an example including both approaches see scratchpad.referata.com. The Form Form:FtItem generates the articles. The templates Template:FtItem/Head/HeadData, Template:FtItem/Head/Personnel, Template:FtItem/Head/Reference are used to set the attributes, and finally Template:FtItem/Head and Template:FtItem/Body display the article. An example page generated with the Form is FtTestItem. It is all not very nice but really only a cooked up demo to demonstrate my problem above.

As for the transfer from the one-template-solution to the multiple-template-solution: The one template could call the multiple templates, so you would not have to transfer all articles at once, but only when you make changes to them.

(Edit: Improved the example to reflect the data-view-approach better. 15:07)

HTH. If not, elaborate or just tell me to shut up.  ;-) -- F.trott 14:45, 24 July 2009 (UTC)

Hi,

While I understand your approach, I don't think that matter could be handled only by semantic properties. For example, the "history" part has to hold a lot of text with any wiki markup, such as pictures, and that doesn't work very well when included in the Text type of Sementic Mediawiki. Furthermore, isn't it a waste of cpu, ram and cache to have a lot of requests asking for data that is on the same page ?

Looking into SF_FormPrinter.inc, it seems that a string replacement around the line 1008 would do the trick for Form submission, but extracting these multiple fields from the template and putting them outside of the general template at form edition would be a bit trickier.

Ok, as you might have guessed, I use the wiki for project management and information. So for me it is mostly text, nothing fancy. I never tried SMW with a lot of markup. If I had to, I would maybe try to wrap it somehow and unwrap it for display. Even more cpu-load. :-/

Cpu and ram: I have some concerns there, too, but so far it seems to work for me (Running the wiki on a 1.3-GHz-Laptop, 1GB ram, Win XP). Pages do not load instantaneously, but within 3 to 5 seconds, and they are a Lot more complex than the example.

If you wanted to minimize database queries you could maybe do something with the variables extension. But I never tried that, so I don't know, if it would work, especially as the variables would have to work across template borders. Also, in the end simple queries would probably be faster than all the string-manipulations necessary with variables.

Last Idea: I never tried it, but maybe defining your own input type could do the trick. Admittedly, that would be quite some effort.

Or Yaron could just include form nesting. :-)

F.trott 09:36, 25 July 2009 (UTC)

Well, I finished making some additions to the code and could get something that solves my problem, though it is not a nested template. A simplified version of my form looks like that:

  {{{for template|Sheet}}}
 {{{field|voice|hidden|replace=voiceActor}}}
  {{{field|history|hidden|replace=historyRelation}}}
{{{end template}}}


{{{for template|VoiceActorTemplate|multiple|replace=voiceActor}}}
'''Name:''' {{{field|name}}}
'''Role:''' {{{field|role|size=55}}}
{{{end template}}}


{{{for template|historySection|multiple|replace=historyRelation}}}
'''Text:''' {{{field|description}}}
{{{end template}}}

Basically, all the text generated by the multiple template declaration on VoiceActorTemplate (so a succsession of {{VoiceActorTemplate|name1|role1}}... ) is taken and agregated into the "voice" field of the Sheet template on form submission, according to the replace=voiceActor parameter that helps to identify what should go where.

On edit, the list of templates in the "voice" field are taken out, put at the end of the string used at the form creation and so they get parsed correctly by the {{{for template|VoiceActorTemplate|multiple|replace=voiceActor}}} tag.

Synchronize the data pre-populated into form input fields with up to date semantic data

The default use of SF results in a form's template(s) providing nothing more than straight-forward annotation of semantic properties to data values entered into form input fields by a user interacting with the form based edit view of a page.

One of the problems I came across while testing partial forms was the realization that whenever a form view of a page is displayed each input field is pre-populated with the values that were last assigned to a named parameter used by one of the form's templates and corresponding to that specific form input field.

• If there is more than one way for the semantic data associated with a page to be changed (and this can easily the case when partial forms are put to use) then a fundamental problem arises because this pre-populated data may not always be synchronized with up to date semantic data associated with a page.

There is a way to force the form to synchronize to current semantic data however it requires the use of a javascript function to auto-populate contemporary semantic data into form fields. Of course the user of the form may then change that data any way that they see fit before saving the form and committing the data changes to the underlying page.

• This explicit synchronization enables a form's template to do more complex data manipulation than just straight forward semantic annotation. (see Possible applications)

This is something that I had intuitively expected of a form's template but soon came to realize this was being hampered by the fundamental limitation of SF. i.e. the form does not remember up to date semantic data values, instead it remembers the last values assigned to named parameter values.

Delivering contemporary semantic data to the form

This can most easily be done as part of the form's markup code (not the form's template but the form itself).

• An HTML element uses a #show: inline query to extract up-to-date semantic data from the underlying SQL database.
• That HTML element is given a unique ID. (An obvious choice is to reuse name of the template named parameter that the semantic form is designed to populate. e.g. param-property-name The semantic property name itself tends to include space characters which aren't suitable for an ID attribute.)
• That HTML element might typically be hidden however, that is optional. Use a classname based style to override the default hidden style. viz.

<div id="param-property-name" style="display:none;" class="SyncSemanticData">
{{#show: {{FULLPAGENAME}} |?property-name }}
</div>

With these hidden DIVs within a form's HTML the javascript function to auto-populate a form's input fields becomes relatively straight forward. viz.

    var str = $("#param-property-name p").text(); /* accesses the contemporary semantic data */
    $("#bodyContent form.createbox fieldset")
     .find("input.createboxInput[type='text'][name$='[param-property-name]']")
     .val(str);  /* populates the form's (input type = text) field */

Where param-property-name is whatever named parameter the form's template uses since that can be uniquely matched to the name attribute of an input field. The different input types (text, textarea, radiobutton, checkboxes, listbox, etc.) each require subtly different

• selector based on the name attribute
• formatting of the output from #show: however that can easily be achieved using a combination of #arraymap: and wiki markup within the template. The ArrayExtension parser functions arrayUnion, arrayDiff, arrayInterection would be powerful tools in this process.

Possible applications

At least two applications come to mind immediately but the possibilities are boundless. The key enabler is allowing the wiki developer to perform complex data manipulation within a form's template before making the final annotation of semantic properties to individual data values. This was a definite "no-no" so long as a form's memory is tied to the last used values for named parameters.

Add to favorites / Remove from favorites

This has been my primary driver the past two weeks. It is an essential part of most online communities and a perfect "killer app" because it is a piece of functionality that just about any web user can easily relate to. The property, Is a favorite of, is annotated to the username for each person who wishes to mark a page as one of their favorites. In this case the username is the data and rightfully belongs on the page .. albeit hidden from regular page rendering but still visible via the semantic browser or the FactBox if that happens to be enabled.

A challenge with implementing this was to prevent clumsy users from directly accessing the list of fans who have already "subscribed" to the Is a favorite of property for the page. This is less out of concern for user privacy and more out of concern that an accidental deletion or addition of another user's name might occur. The current list of "fans" can remain hidden and so the user currently interacting with the semantic form is only presented with an Add/Remove radiobutton pair along with the buttons: Confirm (i.e save page) and Cancel.

Batch loading of semantic data

This is next on my list for a specific game wiki. I suspect the scenario will resonate for developers of other wiki communities.

Using the standard output from a program (e.g. a game client, office application, measuring instrument, file scanner or whatever else you can imagine) an XML or CSV style plain ASCII file can be prepared which basically associates values (or delimited lists of values) to various property names. There might be dozens of property/value pairs in such a file. It is simply unreasonable to expect your average wiki contributor to laboriously enter each value into a form field and then click save.

• The data might be the results of a multi-player game, the vital statistics from a day or weeks worth of security monitoring or cargo/asset movement, log files from regular antivirus scans or firewall reports, environmental data or patient data from a routine set of monitors logging data to disk, and so on and so forth. The common characteristic of this type of data is that it is not information that requires a user to be prompted by form field titles or button labels. Indeed the user does not need to think carefully about this information as it is being entered.

So instead the user copies and pastes the contents of one entire file into a single textarea field (yes there are character count limitations imposed on those fields) and then saves the form. The task of fragmenting this highly regular data into #set:property=value pairs is delegated to the form's template. (Not possible without synchronization.) Finally, a null string is annotated with a property corresponding to the textarea input field.

The next time that page is edited using the form view the user is presented with all form fields correctly populated with data that was previously entered by them using the single "cut and paste" operation followed by a Save page. Also, the textarea input field is completely blank once again - no memory of the last parameter value used because that entered data was only a transitory/interchange format.

Now that gives me goose bumps just writing about it.

Are you familiar with the Data Transfer extension? It allows for CSV import. Yaron Koren 15:12, 27 July 2009 (UTC)

No I am not familiar with it. I did research Extension:Data Transfer but quickly learned that it requires a user to have admin/sysop privileges to upload data in batch mode. (In this sense it is the same as mediawiki's Special:Import tool for uploading one or more entire wiki page(s) from a single XML file.) For the application I have in mind I need a method that any regular user can use to upload such batch data.

• I hope to find a way to do this for multiple pages in the same batch operation but I doubt I'll get to look into that possibility until the end of August or early September. I imagine AutoWikiBrowser will be involved in some way.

-Najevi 05:01, 28 July 2009 (UTC)

Ah, there was definitely a gap in the Data Transfer documentation - it didn't explain how to change the permissions. I just updated it. Yaron Koren 19:21, 28 July 2009 (UTC)

So why write about this here?

I think that data pre-populated into form input fields should (by default) be synchronized to the semantic data associated with a page and not merely retrieving last used template parameter values. I (finally!) understand why the form's memory is tied to named parameters in constituent templates but I think that a more robust strategy has been described above.

The good news is that whether this synchronization gets integrated into the SF extension or not, it is something that a motivated wiki developer can do for themself. In time I will set up a demo wiki based around the already described Getting started example of books in a library to illustrate at least the above two applications of this strategy. i.e. 1) allow users to add a book or author to their list of favorites and have that list automatically appear at their user page and 2) batch upload of data about a book or an author (not a great demo since it is only a short list

Perhaps some discussion will follow and an even better solution emerge. -Najevi 19:14, 25 July 2009 (UTC)

Name of the article based on the class

Hello. Is it possible to automatically add suffix to the article basing on article class and parametres? For example, I have a class "Person" and property "Date of birth". So, I create an article using form input and enter <name> to this input. After the semantic forms wizard ends, the article is under address <name> (<person>, b. <date of birth>). Visor 11:44, 26 July 2009 (UTC)

Instead of "<person>", why not just have the text "person"? Yaron Koren 18:36, 26 July 2009 (UTC)

Yes, my bad. It should look like that: <name> (person, b. <date of birth>). Visor 21:31, 26 July 2009 (UTC)

Okay. Did you read this section? Yaron Koren 22:43, 26 July 2009 (UTC)

Input type radiobutton: "mandatory" does not work with default value

If you use a field of input type radiobutton the javascript function validate_mandatory_radiobutton fails, if no none-button is generated, i.e. if a default value is given.

Workaround: Leave out the "mandatory". It's pointless anyway with a default value, as you can't unselect radiobuttons. That does not help, because a "None" option is automatically added if a field is not mandatory, i.e. you can unselect it.

--F.trott 13:54, 27 July 2009 (UTC)

Solution: Only add the call to validate_mandatory_radiobutton if there is no default value given. In SF_FormPrinter.inc change line 109 from

$sfgJSValidationCalls[] = "validate_mandatory_radiobutton('$input_id', '$info_id')";

to

if ($default_value == "") {
  $sfgJSValidationCalls[] = "validate_mandatory_radiobutton('$input_id', '$info_id')";
}

--F.trott 14:35, 28 July 2009 (UTC)

Ah, great. Thanks for the patch. Yaron Koren 18:32, 28 July 2009 (UTC)

Feature request: Regular expressions for validation of text fields

It would be really nice if I could set a regular expression in a field declaration for the validation of text fields.

Usage: e.g. custom date fields, custom number formats (social security number, postcode, telephone...), all kinds of ids

Problem: I'm not sure if and how it would integrate with other wiki markup, e.g. what about square brackets.

--F.trott 14:05, 27 July 2009 (UTC)

Well, you can always define a new input, with its own Javascript validation, by creating a new extension that hooks into Semantic Forms - there was just a discussion on the mailing list about this. But I'm not a big fan of validation for things like phone numbers, since there are so many valid ways to express it. I think just having instructions in the form on the right format to use is enough, in general. Yaron Koren 14:53, 27 July 2009 (UTC)

add optional Ending Date link

I am not sure if the following is possible, but it seems to me that this might be acheivable by using chooser, but I have been unable to actually find a place that further explains what the chooser option is capable of.

I have created a form that enables users to add upcoming events to a bulleted list. What I would like to do is add a link under (for example) the Date field that says Add Ending Date. This would add an additional date field to the form that was previously hidden and the link text would dissapear or switch to something like Single Day Event.

I am currently using Semantic Forms v1.6

Thank you!
Dgennaro 16:00, 27 July 2009 (UTC)

Warning message with 1.8.1

I get the following message with 1.8.1 installed:

Warning: Call-time pass-by-reference has been deprecated; If you would like to pass it by reference, modify the declaration of [runtime function name](). If you would like to enable call-time pass-by-reference, you can set allow_call_time_pass_reference to true in your INI file in .../SF_FormEditTab.php on line 109

It goes away when I remove the '&' symbol from line 109. --KarenK 02:55, 31 July 2009 (UTC)

Oh yeah, I forgot the rules for passing-by-reference (it didn't give an error message for me when I tested it out). Thanks for the bug report; it'll be fixed in the next version (though you've already found a fix, which will work fine if you're not using the "Vector" skin). Yaron Koren 03:19, 31 July 2009 (UTC)